paint-brush
From Outputs to Outcomesby@viktordidenchuk
161 reads

From Outputs to Outcomes

by Viktor DidenchukJuly 24th, 2024
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Shifting from output to outcome can be stressful but rewarding. Empower your Scrum teams with guidance, embrace gradual progress, and prioritize moving in the right direction over rushing against time. It's a marathon, not a sprint.
featured image - From Outputs to Outcomes
Viktor Didenchuk HackerNoon profile picture


Empowerment is widely endorsed. There is consensus that top management should trust teams to solve problems and provide them with the autonomy to achieve goals and milestones. This trust is not just a formality but a recognition of the value and expertise that teams bring to the table. However, the challenge lies in transitioning teams from a feature-factory mentality to a value-driven approach.


Development teams often need to prepare for such a shift to gain experience in taking on this level of responsibility. Let's face it: being accountable for outcomes is much more complex than simply delivering fixed tasks with specific features. Despite the increased risk associated with focusing on outcomes, it is far more interesting and exciting for everyone involved. Remember when time used to go much slower when we were kids? Scientists say that is because we explore the world and learn something new daily.


Here are some strategies to effectively transition from focusing solely on output to achieving meaningful outcomes. Overcome the feature-centric mindset once and for all.

Mindset Difference.

Mindset. A brain surrounded by lighting bulbs.


For a long time, success was delivering features within deadlines and scope. I excelled at meeting stakeholders’ wants. They were happy with the results, and we were comfortable with how we worked.


There was no room for confusion. Everyone understood their tasks and deadlines without problem.


Every Sprint followed a similar pattern: features, features, features, a bug fix here and a refactor there, but nothing more. Our primary responsibility was to deliver outputs on time, a task we were adept at fulfilling. However, with the restructuring of the leadership team, expectations shifted. They emphasised achieving goals rather than dictating specific tasks.


When they stopped telling us what to do, we panicked.


We needed guidance as to where even to start. The questions running through our minds were:

  • Where should we start?
  • What if we make a wrong decision? Will we be held accountable?
  • How do we define success now?


It was embarrassing. We wanted responsibility and autonomy, and that’s exactly what we got. The real challenge, however, lay in figuring out how to deal with it. We were empowered to achieve goals but needed to prepare for the task.

Output vs Outcome.

Output vs Outcome. A petite chick sitting in a basket with eggs.


Until then, we had solely concentrated on outputs, completely unaware of the true essence of outcomes. Let’s try to summarise the difference.


An output is created for customers to use, such as product recommendations in the e-commerce industry. These recommendations are designed to deliver value. Their outcomes assess the effectiveness of outputs. For instance, when customers add recommended products to their carts, increasing sales represents an outcome.


Now, here's the exciting part: Various outputs can achieve outcomes. It's like solving a problem where multiple alternatives exist.


When you begin with the outcome in mind, you unlock diverse possibilities and increase your chances of creating significant value.

Start small.

Start small. Small plant growing between pavement tiles.


Getting someone who is already an expert on the topic will make your life much easier. To get where you’ve never been, seek guidance from someone already there!


I froze when I first faced true empowerment, and so did everyone else. Despite our attempts to shift focus towards outcomes, our lack of experience inevitably led to failure, as anticipated.


  • We struggled with conducting discovery experiments;
  • Developers expected precise requirements from me as usual, and;
  • Stakeholders prioritised feature predictability;


The dynamics began to shift when an experienced person joined our team. Instead of overhauling everything at once, we transitioned gradually from focusing on outputs to emphasising outcomes.


Our Sprints primarily focused on delivering outputs, with some items oriented towards achieving outcomes. This mixed approach allowed us to change to a new working method gradually. For instance, in one Sprint, we allocated approximately 70% of our capacity to completing a pre-defined integration with partners and 20% to exploring methods to reduce our churn rate.


Through this process, we discovered the barriers preventing us from fully embracing the unknown:

  • We hesitated to provide estimates for ambiguous requirements due to past blame for unmet deadlines;
  • We avoided exploring alternative solutions, fearing the prospect of failure and criticism;
  • The uncertainty of the unknown made us uneasy as it challenged our accustomed security;


Gradually, however, clarity emerged, and we began transforming our work approach.

Mindset transformation is required.

Mindset transformation is required. Red and yellow transformers in the desert.


Transitioning from focusing on output to prioritising outcome is challenging and demanding, as it upends everything you thought you knew about your work methods. With an output mindset, decisions typically revolve around how to deliver predefined features.


When a value-driven mindset with a focus on outcomes is an adapter, you need to make decisions frequently—some say even 10 times as many. You must choose problems to solve, find solutions, test them, inspect them, and adapt. It’s more demanding, without a doubt.


It also means that you are still working when customers receive the functionality. It is crucial to understand how it works, what they like, how to improve, and how to measure the outcome.


So what can help:

  • Coaching: Ask your team questions; do not provide answers. The brains of an entire team have much more computing power than those of a Product Owner or manager;
  • Problems over solutions: Focus on understanding the problem's context, relevance, and impact before discussing solutions;
  • Learning over predictability: Prioritizing learning over predictability involves embracing the unknown through frequent small experiments and rapid end-user learning. Understanding what not to build is as crucial as identifying what to make, aiming to create value while minimising waste;
  • Evidence over opinions: Moreover, decisions should be guided by objective evidence from experiments rather than opinions. This is about having a data-driven mindset;


Once you've shifted your mindset to focus on outcomes, the orientation towards achieving meaningful results becomes motivating and inspiring. Every Sprint becomes a different story.

So What?

So what? Paper advertisement on the wall.


Moving from output to outcome is stressful. The burden on your shoulders will be heavy, but you’ll never learn so many new things.


Scrum teams yearn for empowerment but can feel overwhelmed when it arrives. Navigate this shift with guidance from experienced mentors and embrace gradual progress.


Remember, it's a marathon, not a sprint. Prioritise moving in the right direction over rushing against time.