Back to resources

Outcome vs. Output-Driven Organizations

Goal Setting
Team Processes

22 August, 2021

Sven Coppens
Sven Coppens

Sr Product Development Director at Aprimo

Sven Coppens, Sr Product Development Director at Aprimo, contrasts an outcome- and output-driven approach while explaining how choosing one over another can impact the organization itself.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Assessing the Performance of Your Team

20 August

Parallels between Work and Sport.

Goal Setting
Different Skillsets
Coaching / Training / Mentorship
Performance
Ron Pragides

Ron Pragides

SVP Engineering at Trustly Group AB

Team Development Framework for new managers

26 June

Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.

Building A Team
Team Processes
New Manager
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

How Product Marketing Can (and Should) Help Product Development

20 June

Pavel Safarik, Head of Product at ROI Hunter, discusses the frequently overlooked role of product marketing in getting high user adoption rates for your product.

Goal Setting
Product Team
Product
Different Skillsets
Cross-Functional Collaboration
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

Dealing with Uncertainties and Adapting as You Go

14 June

Muhammad Hamada, Engineering Manager at HelloFresh, addresses the uncertainties brought on by the pandemic, how these have affected our work environments, and how we can adapt.

Goal Setting
Internal Communication
Collaboration
Roadmap
Stakeholders
Prioritization
Muhammad Hamada

Muhammad Hamada

Engineering Manager at HelloFresh

Promoting Interdepartmental Teamwork for More Efficient Problem-Solving

13 June

Roland Fiala, Senior Vice President of Engineering at Productsup, raises an interesting issue about autonomy in teams: does it hinder collaboration opportunities that lead to better problem-solving? He shares his system for promoting teamwork in engineering departments.

Internal Communication
Collaboration
Roadmap
Team Processes
Cross-Functional Collaboration
Roland Fiala

Roland Fiala

Senior Vice President of Engineering at Usergems