It looks like you are using Internet Explorer, which unfortunately is not supported. Please use a modern browser like Chrome, Firefox, Safari or Edge.

Teach outcome orientation to yourself and others - a hypothesis statement connects outputs to outcomes

Published in Agile

Written by

Antti Tevanlinna
Senior Enterprise Coach

Tevis is an agile coach who mixes strategy, outcome-thinking, and agile. He writes weekly on all matters related #productleadership.


August 29, 2023 · 5 min read time

Outcome orientation is a significant trend in product leadership, and we are constantly encouraged to focus on outcomes. The approach is gaining popularity because it allows organisations to create valuable products by ensuring that the development process is genuinely guided by customer needs. This article focuses on shifting our thinking from outputs to outcomes using the hypothesis statement.

Outcome orientation is the fastest way to create high-value products for your customers, and it means seeing the world through the customer's eyes: customer needs and desires are at the heart of product development, and new features and functionalities align with the core needs of the chosen customer segment. The product can solve customers' problems and help them reach their goals more efficiently, creating meaningful user value. 

Simple, low-cost tools can help us enlarge our thinking and jump into our customer's shoes to ensure that our products create genuine value for them. This article series discusses five mind tricks that are proven, easy to teach, and help bring the customer to the heart of everything. 

Outputs have been hard-wired into our brains

Thinking in outputs comes naturally to us. We have been hard-wired into thinking about problems and solutions all our life. Starting from our early school years, we have solved problems in the form of "Solve problem X" or "1 + 1 = X". All we needed to do was solve the problem. The discussion about the solution's impact was nowhere to be found. 

The same has been happening in work life. Projects start from a backlog of problems (sometimes) and solution ideas (most of the time). Our brains have a habit of solving problems; by default, the usual starting point is outputs. 

When the organisational default is to talk about solutions, designs, and outputs, the shift to starting the work from the customer outcome is neither spontaneous nor does it feel natural. If we started from the customer perspective, we could ask ourselves the following questions:

  1. What do my customers want and need, and what are their pain points?

  2. What do we want to achieve regarding user needs and business goals?

When we are used to thinking and working in terms of outputs our whole life, it's best to introduce outcome thinking in small steps. Insisting that we must stop doing things the old way and only talk about customer outcomes is not the optimal method. 

There is a way to introduce outcome thinking in the middle of the work, too. 

Introduce outcome thinking with a three-step hypothesis template

A moving horse is easier to steer. That's why sometimes it is quite ok to let the discussion flow with solutions and designs thrown in the air. Let things be and wait patiently for the solution idea to form. Then it is time to rewind.  

Given an agreed solution idea, you can lead people and discussion backward with the 3-part hypothesis statement:

  1. We believe that <this capability>

  2. Will result in <this outcome>

  3. We will know that we have succeeded when we see <this measurable signal>

The magic of this formula is that it starts from the familiar. 

Step 1 is about the capability, which is the technical solution, process, or project we are working on. Most likely, we share an idea of what the solution will solve. Then we need to connect the idea back to the real world and the customer, and steps 2 and 3 will do just that. 

Step 2 is the "outcome". I appreciate that the vocabulary around outcomes, value, and impacts is far from a shared language in companies and teams. However, in the case of the hypothesis statement, people consistently offer suggestions of "outcome" of implementing the capability. You can always help by prompting "say out loud the customer's outcome".

See how step 2 is a tiny addition and tie to the world. Often people say out loud quite broad outcomes. Sometimes abstract outcomes are offered. Be ready to hear "happy customers", for instance. No worries. Write all of these so that everyone sees them. Often there's a clear winner in the bunch. Often there's a multitude of outcomes that we expect and need.

In the case of the hypothesis statement, people might consistently suggest that implementation of the capability is the outcome. You can guide the discussion further by asking what the outcome would be for the customer. This question brings the customer and the real world a bit closer to the development work. 

It's also common that people can answer this question with quite broad and sometimes abstract outcomes, like "happy customers". No worries. Write all of them down so that everyone can see them and move on to step 3. 

Step 3 brings what I might call observability. The step is again a small step in the process but a big step in connecting the output to the measurable outcome. 

The prompt 3 is:  

We will know that we have succeeded when we see <this measurable signal> 

This prompt is again making people enrich the picture of the (customer) outcome. It does it in two ways: 

1) It invites people to try to imagine what the "signal" would be 

2) It also invites making the observation "countable" or measurable.  

The beauty of the hypothesis template is that it introduces the customer mindset through open-ended questions and helps to understand what the customer will achieve by purchasing the product. Through being more and more outcome-oriented, we grow our capability to create impactful and high-value products, which, in turn, impact larger business outcomes. 

This article begins a series of five articles investigating how to adopt an outcome-oriented mindset and apply it to our daily work. Each piece will discuss one mind trick that helps us change our thinking, and the second article will focus on customers’ Jobs To Be Done.

Want to know more about practical outcome orientation and how to use it to create valuable and successful products? The methods discussed in this five-part article series form the backbone of the Nitor Product Ownership training, which we have built to help you take on and thrive in the Product Owner role. This practical training gives you the skills and confidence to work as a product owner, which is the hardest and the most crucial role for the success of an agile organisation. 

Read more about the training here

(Outcome statement originally from Barry O’Reilly.)

Written by

Antti Tevanlinna
Senior Enterprise Coach

Tevis is an agile coach who mixes strategy, outcome-thinking, and agile. He writes weekly on all matters related #productleadership.

Identify new opportunities with sustainable digital development

We digital engineers are here to meet your challenges. Let's harness the potential of your business together.

Agile transformation starts with you

With us you will learn agile methods that help your organization react to change faster. Learn to build a business culture that can overcome its current and future challenges.