Outcome vs. Output-Driven Organizations

Problem

There is a prevailing tendency across software development organizations to focus primarily on solutions. In most cases, the CEO or founders who started the organization will already have some solution in mind which will be socialized across the organization. Over time, as new people start to join, the focus will shift more toward the solution, while the original problem will be somewhat overlooked.

In large organizations, the business part of the organization is often quick to come up with solutions, which are then handed over to product managers who need to develop a roadmap for building those solutions. When the R&D team steps in to cement the requirements, the engineers will be left with nothing but to nod their heads. As it turns out, this is neither the right nor the most affordable approach because solutions are imposed on people who should be proposing them. Solutions should be proposed only after thorough research and a profound understanding of the problem. Knowing what is the outcome one wants to achieve is a cornerstone of any solid problem analysis.

Actions taken

Let me illustrate the difference between an outcome- and output-driven approach by showing what happens when the focus is put on outputs instead of outcomes. Let’s say we want to go for a specific persona or market segment and want to have a chat feature in the application. This solution will be pushed to a team in the form of well-defined requirements. Requirements are, in most cases, outputs that are handed off to the engineering team.

On the other hand, there is an outcome: we should build something that should allow a group of people to collaborate. Instead of exploring possible solutions, it is assumed without much deliberation that the chat capability is the solution. The half-baked solution is communicated to the team.

Instead of communicating the outcome, the team will be working to produce certain outputs. If they followed an outcome-based approach, they would start observing and measuring user interaction, trying to understand user needs behind that interaction. Rather than building a chat feature, the team starts to analyze the problem. The team could find out that users don’t want to chat but rather give comments within the application and need integration with Slack, Teams, etc. for the collaboration. As a result, if the team would focus on solving user problems, we would see adoption increases. Those personas would start to interact more extensively using our application. This is the outcome that we wanted to get: increase our user base.

Three methods that, in my opinion, are helpful to shift the focus toward an outcome-driven approach:

• OKRs: OKRs are a great example of a goal-setting system that helps people stay focused by connecting their work on the ground with the business objectives. Often developers are handed over requirements without understanding why they are building something. OKRs create that understanding by providing more context and laser-sharp focus on objectives.
• Five Whys: A method that not only shifts the focus on outcomes but encourages people to dig deeper and identify the root causes. While identifying the problem is the first step, it’s often insufficient to provide a solution that will solve the user’s needs. Five Whys is there to help identify a reason that caused a given problem and create a long-term solution.
• Measuring. Before building something, one should define what success looks like and how it could be measured. By asking those questions, one can also arrive at the essence of the problem.
  

All of those methods have beneficial side effects too. Asking the questions will stir up a debate that can have a positive impact on the team dynamic. People on the team will be more critical, willing to challenge the imposed solutions, and encouraged to come up with alternatives.

Lessons learned

• Being focused on outcomes, you will be able to make the right decisions. It also helps set priorities straight as it will make evident what is important and what is not. Moreover, an outcome-driven approach has a positive impact on development teams. When solutions are imposed, engineers feel like robots that should produce software without much thinking. When encouraged to think about problems, they are brought closer to the business, and their opinions become more relevant.
• Changing teams from output-driven to outcome-driven is not easy. It’s not only a question of routine; you will need to coach the team to change their behavior as well as their way of thinking. Don’t be surprised if the prescriptive approach already took the toll. If an engineer asks for requirements only and prefers not to engage in any other deliberative activity, then it is a sign that you need to change the culture.
• By focusing on outcomes, the playfield suddenly becomes much broader, and it takes not much more mental effort, which includes an increased responsibility. For many, that shift will be hard, if not impossible to achieve.