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

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

The Optimization and Organization of Large Scale Demand

4 May

Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.

Managing Expectations
Delegate
Team Processes
Prioritization
Kamal Qadri

Kamal Qadri

Head of Software Quality Assurance at FICO

Leading Your Team in Stressful Situations

27 April

David Kormushoff, Director at Koho, recalls how he galvanized his team to tackle a time-sensitive problem, sharing his tips on how to shift chaos into calm.

Goal Setting
Leadership
Conflict Solving
Deadlines
Collaboration
Motivation
Strategy
Health / Stress / Burn-Out
David Kormushoff

David Kormushoff

Director at Koho

The Necessary Structures of Time Management

14 April

Suryakant Mutnal, Engineering Manager at PayPal, discusses the importance of time management and the necessary structures in order to create internal consistency.

Productivity
Remote
Deadlines
Goal Setting
Roadmap
Performance
Prioritization
Managing Expectations
Suryakant Mutnal

Suryakant Mutnal

Engineering manager at PayPal

Why Documentation Is the Key to Success

6 April

Henning Muszynski, Head of Frontend at Doist, promotes his ideas on how documentation ensures consistency, efficiency, and standardization.

Alignment
Collaboration
Productivity
Hiring
Team Processes
Henning Muszynski

Henning Muszynski

Head of Frontend at Doist

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.