ArticleOctober 19, 2023 · 8 min read time
Being able to tune your thinking and seeing the world from the customer's perspective is needed to get to outcome orientation. Once you see the world in an outcome-orientated way, our experience tells us you will never go back. Our five-part articles series introduces simple and easy ways to adapt this mindset. This is the fourth article in the series, exploring how to strengthen outcome orientation through habits and the PDCA cycle.
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.
However, thinking in an outcome-oriented way is not easy nor actionable for many practitioners. In this article series, I explain five proven and easy-to-teach mind tricks that consistently get your brain and team thinking outcomes.
Each article in this series discusses one mind trick:
Measure change in customer behaviour and perception
Insist that customer value happens before business value
I define the customer outcome as the customer's progress, change, gain, or benefit, which the customer perceives as valuable. I appreciate that this definition is long, but I want to give the impression that the customer outcome can be many things. The common denominators are that the outcomes are for the customer and that the customer decides what is of value.
It's time to move from awareness to convincing – to convincing that outcome-orientation is the right thing to do. To believe is a step. To experience is stronger. I picked up this small trick from Melissa Perri, and I'm loving it.
Applying the PDCA cycle to add feedback
The Plan-Do-Check-Act (PDCA) cycle is a framework for continuous improvement – also known as the Deming cycle. It is a universal cycle that can be used to make processes iterative and adaptive. It provides a systematic way for measuring change in customer perception by setting clear objectives, tracking progress, and continuously optimising work based on feedback.
The PDCA cycle can be found in the Scrum sprint cycle, and the general scientific method that creates new knowledge follows the same pattern. We can apply the PDCA cycle directly to outcomes as well.
The steps of a PDCA cycle are:
PLAN: Define objectives, plan and specify customer outcomes, set metrics, and develop a detailed plan with specific actions and strategies to meet your objectives
DO: make the change - implement strategies and collect data
CHECK: analyse data and check the actual results
ACT: adjust strategies, beliefs, and methods based on learnings
It can be said that rigor and perseverance in checking the results drive learning and "acting" (the fourth step).
When we want to keep outcomes at the center of the work, we need to write down expected outcomes on paper to enable checking.
How do we record outcomes in the planning stage of PDCA?
Many organisations are not outcome-first, but rather plan-first. Teams routinely work on solutions and breakdowns of the planned steps. That's what is the default, and that's what gets the most attention.
We can gradually shift the meaning of what the P in PDCA means. There's no need to stop the line and change everything into fully outcome-based. Instead of a full revamp, we can use the feedback and adaptation cycle to reinforce outcome-based target setting. The minimum viable way starts with recording the expected outcomes in the P-stage.
PLAN: Define objectives, plan and specify customer outcomes, set metrics, and develop a detailed plan with specific actions and strategies to meet your objectives.
Write down the outcomes right next to the plan of actions. The P of PDCA becomes both the technical solution and the customer outcome we seek. It is likely that the solution and the technical plan have prominence, but having written down the customer outcome in a measurable way prepares for the crucial step: the checking.
As a promoter of outcome orientation, you will have to use a bit of persuasion to get your team to write down the hypothesis of the outcome. People often need the practice or the habit of doing that. Your task is usually straightforward. I've not heard anybody objecting to writing down the outcome as part of the plan.
Then, it's time to do the work: create the solution, iterate, and make what is in the plan. Once we think we've gotten where we planned, it is time to check the results in the C-stage of PDCA.
The check-stage: management participation and the four scenarios
The trick is simple. Recording outcomes at the planning stage allows us to review and discuss outcomes explicitly once the work is done. The usual format is having the check discussion in the team. This time, we add a few people into the mix. Having a broader participation reinforces the use of outcomes as a starting point.
Invite participants from higher management into result-sharing and result-checking discussions. I don't mean that you should invite all the management. Neither do I suggest inviting the CEO. The most helpful participants from management are the team stakeholders: People whose opinion weighs. Their level optimally is where they no longer have time for detailed problems or solutions but have time for and keen interest in discussing customer outcomes and business impact. I'll simply refer to these people as executives.
In my experience, executives are constantly bright and focused people. They are keen on strategy and impact. And they are interested in differentiation and the customers. Discussing and creating outcomes is often the core of their job. The executives are the sounding board and the credible source who rally us to be more outcome-driven.
The joint result-checking session can be fit into an hour with plentiful discussion. Thirty minutes is pushing it a bit and starts to limit the amount of deeper discussion.
I can create four main scenarios for how the discussion flows. All of the scenarios either reinforce outcomes or give you valuable next steps. I'll expand on the scenarios.
1. The outcome is reached, and executives view the outcome as good progress
This is a clear WIN-WIN scenario. We've done the work and noticed that we've created an outcome for the customers. The larger organisation around the team has seen the same. The executives have likely complemented the team. We've both experienced how to create an outcome and gotten a verbal reward for the good work.
2. Miss outcome – Win with execs
The second scenario is where the planned outcome is not reached. Either the outcome is not measured, or the solution created does not create the desired outcome. In either case, the executives will likely discuss the outcome, and we can leverage their wish for impact. Again, the team hears the importance of outcomes.
While we did not get praise in this scenario, the message repeats: we ultimately work to deliver outcomes.
Preparing for this scenario involves a bit of work with the executives. Make sure in advance that missing the outcome will be handled constructively. The best way to prepare for this is to keep the iterations short and bets small. Then, the inevitable misses are not a crisis.
3. Reach outcome – Executives don't care
In the third scenario, the team reaches an outcome, but the executives don't care. The team discusses and checks results, observing clear outcomes. There is, however, a lack of engagement or opinion from the executives.
This kind of situation, where there are outcomes but the larger organisation does not care, has never happened to me. Let's, however, keep this as a plausible scenario. This would imply that we are simply working with the wrong outcomes, which nobody else in the company cares for. If this happens, you know you have strategy and stakeholder engagement work ahead of you.
4. Miss outcome – Executives don't care
The fourth dismal scenario is that you miss getting to an outcome, and nobody cares about it. This implies you have deeper issues.
Forming habits to get from problem-solving to delivering outcomes
Charles Duhigg has popularised the concept of a habit loop. His excellent book "Power of Habit" explains how our habits and routines form. The science around habit loops tells a compelling story of how repeated cycles change behaviors into fully automatic habits. The steps of the habit loop are trigger, action, and reward. The trick outlined in this article is really about habit enforcement and how it helps us move from solving problems to delivering outcomes.
The habit that we usually see in organisations is the problem-solution loop. The three steps of that habit are:
1) Problem (trigger)
2) Solution, plan, implementation, release (action)
3) Problem solved and happy feeling (reward)
It is almost like automation. We routinely solve many problems. Often, the customers are happy. That, however, is not the same as outcome orientation.
What you want is reframing the loop into:
1) Notice possible outcome (trigger)
2) Create an outcome hypothesis and iterate to a solution (behavior)
3) Observe the outcome and feel good (reward).
Existing habit loops can be altered by experimenting with the trigger and the reward. The trick of this article does both. The explicit reinforcement of the outcome-checking creates a new social reward. To sustain something, go for the positive habit.
An article series on outcomes
This blog is the fourth 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 in the last one we will discuss the importance of customer value happening before business value.
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.