The idea of using outcomes (instead of outputs) is now commonplace in the product world. A lot of theory exists on this subject, but not many teams or organizations manage to execute this well. Most product organizations are on a journey from switching from being output-focused to outcome-focused, and that journey isn’t always easy in practice.
Common reasons that businesses find this switch difficult are related to mindset and trust. They need to transition their mindset and thinking to focus on outcomes and build the confidence that teams will achieve their goals — without needing to specify or be told exactly what to build.
Therefore, to successfully focus on outcomes, product teams need to find ways to adapt their own mindset to think outcome-first, adapt other people’s mindsets to buy into this, and deliver effectively on these outcomes over time.
This article will dig into how to gain an outcome-first mindset and show you techniques to keep outcomes at the forefront of the product team.
An outcome is the measurable, tangible impact that you can see on a metric by making a change to your product.
An outcome is not about the feature, but it is about the impact that the feature has.
Outcomes are most commonly seen at the OKR level — where the objective and key results are the impacts that you’re expecting to deliver. Many different hypotheses and tactics could deliver that impact.
Due to the nature of how we’ve worked over several years, the language that we use across organizations, and our human desire for certainty, teams often tend to:
This highlights the two main issues that teams face. The first is that it’s often easier to go into idea and solution mode than focus on outcomes. The second is that organizations are used to gaining a false sense of security through a clear, feature-based plan.
These are the problems that we need to unpick.
When focussing on outputs, the ideas generated don’t necessarily solve a problem or opportunity. You’re also less likely to be solving the biggest problem or opportunity, and therefore not delivering maximum value.
Further, it’s a lot harder to craft a hypothesis and really judge the success of something, as you’re incorporating bias by backtracking to assign metrics and prove value.
The overall issue is that you’re far less likely to add value and have the impact that you want.
Ironically, product is supposed to maximize the value that we can deliver. This means that we need to:
The solution to the problems above is to focus on outcomes first. Being outcome-focused allows you to:
There has already been a ton written on this and why it is important, so you’re not already thinking “Yes Evie, I’m brought in to why I should make the effort to do that. feel free to check some of these out:
If you’re keen to focus on outcomes. Here’s what you need to get started:
Then you can then craft:
This way, you are thinking about what it is you’re trying to achieve, how that delivers business value, and different ways to achieve it. This will allow you to generate the most successful ideas.
As I mentioned at the start of this article, the main problems with teams moving to think about outcomes are:
I believe the same principles can be applied to points #1 and #2 — the only difference is that #2 requires some level of influence.
So, how can we change our mindsets to be outcome-first?
Often, it can be hard to change our mindset itself — a mindset is something that has been programmed over a long period. Yes, we can use mindset-changing techniques and always ask ourselves if we are thinking outcome-first, but beyond that, a mindset is something that needs to evolve.
So what can we do to help us on our journey and stay focused on outcomes?
We can use different tools that help through our product thinking process to allow us to stay focused on the outcome.
Some examples of these are:
This helps your whole org to move in the same direction and focus on outcomes. If OKRs are set at the company level, these can be broken down for different departments and teams to know what they need to do to contribute towards this.
This means that each area ends up with its own outcomes to focus on and ways that they can measure this — you can then focus on different ways to achieve that goal.
You can use the opportunity solution tree to focus on the outcome you’re trying to achieve, the opportunities that exist within this, and then prioritize and define how you could solve each one of these.
“How might we” statements allow you to reframe the way that you look at insight and focus on the problem itself and how you can then solve this — keeping this chain of thought and preventing you from jumping straight to the solution.
You can use the value proposition canvas to think about your customer needs and pain points first, and then you can think about how to deliver products and features that actually support these.
The JTBD framework is great if you’re looking to think broader and more holistically across the whole customer journey. This allows you to think a lot broader about what the customer really wants to achieve, and then generate new solutions to achieve this.
If you start to use some of these methodologies, I guarantee it will have an impact on how you and your team think in an outcome-first way.
Even when you’ve achieved an outcome-focused mindset shift, it can be difficult to know how best to spread this and get the whole business on board. This can stop the questions like “When will you deliver X feature,” and from stakeholders coming to you with a bunch of new ideas.
To do this, you really need to shift the conversation away from outputs and focus it on outcomes. The main way to do this is to take stakeholders back up the process.
If a stakeholder comes to you with an idea, you can ask about their hypothesis, the problem they think it’ll solve, and the outcome. If that outcome fits with your objectives, you might already be exploring it or see value in exploring later. You can then tackle the outcome by focusing on that and on your insight first, which should still provide the result that the stakeholder wants to see. This is ultimately what you’re trying to achieve!
When it comes to tackling the question of “When will you deliver X feature,” the best way to approach this is through adapting roadmap conversations. Teams often struggle to explain their outcome-focused plan to the business, as they’ve traditionally focused on building roadmaps around clear deliverables.
You can start to shift this conversation by using different roadmap techniques.
Different roadmap techniques allow you to really shape conversations in the business around outcomes, whilst still providing certainty that you have focus and a plan.
My three favorite roadmap formats to achieve this, all use variations of the Now, Next, Later roadmap format —this really helps to move the business away from fixed deliverables and timelines.
Let’s start with the easiest one…
Use this roadmap if you have clarity on the tactics you’re building and testing and strong ideas of which hypotheses you’ll test next. This is likely if you already have a lot of data and clear direction on where you’re going as a team. This is also a great format if you’ve broken down your outcome into different objectives and might be working on more than one stream concurrently:
This format provides stakeholders with the most certainty of what you’ll work through, without the need to know exactly which tactics you’ll test for your future hypotheses.
This roadmap format makes objectives and features super clear. It also allows you to become more vague with the information you put into the roadmap when the time horizons are further out.
If your tactics, hypotheses, and opportunities are going to take longer to deliver, or are a little more vague, your outcome-focused roadmap will look more like this:
This format allows you to be crystal clear on the outcome you’re working through, but a bit more vague on hypotheses and opportunities that you are currently identifying.
The format for this roadmap is almost identical but highlights different ways that you can present your roadmap to demonstrate that what you might do next is a little less concrete. This is crucial if you’re a newly-formed team that doesn’t yet have the answers, if you’re doing a lot of discovery, or if you’re less certain about your bets.
If you’re working in an organization where stakeholders really do feel like they want more certainty of your plans, then instead of leaving the Next column open and vague on tactics/hypotheses, you can demonstrate your testing plan. This allows you to present the options that you might take (this is still subject to change based on what you learn) if an experiment is positive or negative for example:
I would say this roadmap comes with a word of caution. It takes more effort to put together and ties you more to a specific route. However, it can be helpful if your organization needs this level of detail.
My preference would usually steer away from having this detail at a roadmap level. Instead, know your options and be able to discuss them in workable tools like a Figma file.
However, I have found this roadmap an extremely useful format in scenarios where delivery is more of a project — ie. if working on a particular contract or in scenarios where organizations are transitioning and need more of a plan to begin with to aid buy-in.
All of these roadmap formats give different ways that you can present your thinking, bring outcomes to the forefront of the plan, and bake in hypotheses and opportunities. This really helps to change people’s mindsets, steer the conversation, and allow you flexibility so you really can focus on outcomes.
Focussing on outcomes is not always easy in a product organization, as teams have traditionally focused on outputs. As humans, we tend to be happier with certainty.
However, your team can add so much more value to the organization by ensuring that you are focussing on the right outcomes and the best ways to solve these.
Hopefully, by now you have some amazing techniques and communication methods to help change your teams and organization to be more outcome-focused. This will build trust that you can succeed in this space and drive that value for the business.
I hope you enjoy trying some of these out — and I would love to hear your feedback on how you get on!
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.