Artikel
25 september 2023 · 7 min lästidOutcome 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. In this article, we dive into making outcomes measurable.
Focusing on outcomes is not easy nor actionable for many practitioners. In this article series, I explain five mind tricks that consistently get your brain and team thinking about outcomes. The mind tricks are both proven and easy to teach.
The first articles introduced a simple backward-working method and explored how to use storytelling to frame outcome orientation.
Tony Ulwick (creator of the jobs-to-be-done method) has urged us to "Be the student of the job and the outcome of the customer". The milkshake story started to imply that multiple jobs are intermixed and that the context of the job matters. Ulwick has said that he became fascinated by the opportunity of applying science to understanding the job of the customer, to "scientifically" research the job.
This article is for the scrum masters, agile coaches, and systems thinkers out there and dives deep into how we can quantify outcomes and measure whether we succeeded in reaching them.
All begins with seeing the system
The world is a complex reality. The detail of our life is infinite. There are millions of phenomena happening and intertwining around us all the time. Somehow, we still make sense of it all. Our brains are constantly perceiving and interpreting things. But the most interesting thing is that we have wants, and we make decisions.
To make sense of the world and understand the customers' thoughts, we need to talk to and observe them. We collect information about our customers. As creators of customer outcomes, we perceive parts, and our viewpoints sometimes overlap. Often, we, as innovators, see differing parts of the same reality compared to our customers. We look at the same facts and see different things.
Systems thinking is a way of making sense of the complexity of the world by looking at the world in terms of wholes and relationships rather than splitting everything down into small parts. Causal loop mapping is my go-to method for getting groups started with seeing systems and wholes instead of individual events and parts of the whole.
How do we make a customer happy?
Take for instance "customer satisfaction". That broad concept often gets tossed around as something we want as an outcome: "Make the customer happy". It immediately raises the question, "How could we do that?"
We can apply systems thinking and causal loop mapping, decomposing abstract and composite customer outcomes. Systems thinking helps to break them down.
At this point, I need to briefly introduce causal loop mapping and the visual language around it. Feel free to skip this if you are a seasoned systems thinker. Then, we return to mapping out how to make a customer happy.
Causal loop mapping helps to understand abstract outcomes
Causal loop mapping has nodes and connections depicted. You can use a paper or a whiteboard. You can do this yourself or in a group.
The nodes represent events and things we can observe in the world. These are called the variables. As an example, we can observe and subjectively measure "hunger".
The connections between nodes (the things we can observe - variables) represent causal connections between the variables. As an example, the time since the last meal causes hunger. It can be said that "as one variable grows -> the other variable grows as well".
With systems thinking and causal loop mapping, you build a shared view of "how the world works". You create common understanding in a visual way. You choose the pertinent variables that you can observe and study. And you hypothesise how and why good customer outcomes are created.
Back to the fluffy concept of customer satisfaction.
I deliberately chose the variable hunger in the example above as that is part of the famous milkshake story, which we used to introduce Jobs-To-Be-Done thinking, which I consider the best way to get started with outcomes.
There were two jobs that the customers "hired" a milkshake to do:
1) Keep the hunger away until lunch
2) Keep the customer satisfied during a long morning drive to work
It turned out the milkshake did both jobs very nicely and much better than the alternatives.
We can now map the connections of that story together visually. The consumption of the milkshake keeps the hunger away.
The consumption of the milkshake also gives the customer one more thing to do while driving. Thus, it keeps the boredom away. Both work towards general happiness in life – at least as much as we can observe this in the short term.
We create a shared understanding by making a causal model of "how the world works” for the customer. The visual format of the diagram helps us see how the system works. You can do this "as-is" or for the future. When you create it for the future, you have a clear set of hypotheses to test.
You should now notice how consistently peoples' brains create new options to affect the world. People are also very good at offering additional factors that affect phenomena such as "hunger" or "boredom". That is: you can use causal loop diagramming for divergence.
Mapping to understand the context of the job
Causal loop mapping can be used to discover and discuss the context of the job. My quick sketch of the milkshake story quickly starts to discover things that create a richer setting where people begin to have a "want" for a milkshake. This starts to create a richer picture of the circumstances and even the "sweetspot" of the service.
Mapping helps to understand the journey ahead from the start to business modelling
The examples have shown how to create a scenario where the customers' outcome happens. You can also use systems thinking to project things forward. In the best case, you stumble upon the very foundations of your business model.
The classic customer journey goes through stages of being aware of a need or want, seeking solutions, choosing between options, purchasing, using, and buying more.
There's variation in the labels and phases used, but the ultimate goal is to have a happy customer, who, in the best case, becomes a repeat customer and tells friends about the great service. We can map it all.
A few useful questions:
1) What causes the customer to remember the good outcomes of the service – especially when it's time for a repurchase?
2) How good does the outcome need to be for the customer to tell his friend about the service?
The challenge is defining these variables well enough to observe and measure them.
Notice how these forward-working variables make the system a loop:
A trigger or a need causes customers to pull the service into their lives.
The service creates an outcome.
The outcome directly or indirectly validates and enforces the trigger.
This has now become a system that is self-enforcing and growing. Sometimes, some advertising is needed to get the "flywheel" going.
Now that you've come this far with mapping "how the world works," you have arrived at business modelling. Next, you can enrich the model with quantities such as the number of customers and prices of services. Then, you have a quantitative model of your business.
An article series on outcomes
This blog is the third in 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 next one will focus on measuring change in customer behaviour and perception.
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.