For teams navigating the messy world of innovation, Opportunity Solution Trees are a neat visual tool for visualizing how you’re thinking, and spotting where to work next.
By laying out your work in a tree structure, you are forced to be clear about how work ladders up to your objectives, and make conscious choices between the alternatives.
This article will outline what Opportunity Solution Trees (OSTs) are, and how to use them.
Whether or not you decide to create your own Opportunity Solution Tree, thinking about discovery in this way can provide you with a mental model that allows you to make more efficient decisions about what discovery to do and how.
In this guide we’ll take you through the concept of opportunity solution trees, when to use one and how to construct a great one.
Opportunity Solution Tree Template: Miro
What are Opportunity Solution Trees?
Opportunity Solution Trees (OSTs) map out:
- The business objectives you’re aiming for
- The opportunities you can exploit to reach these objectives
- The solutions you might use to realize each opportunity
- The assumption tests you can run to increase confidence in those solutions
They are another way to visualize your progress through discovery, from a slightly different perspective to the classic double diamond of design thinking, and a great way to articulate your strategic pillars.
Whilst design thinking shows you a detailed approach to developing a single idea, Opportunity Solution Trees help you visualize multiple approaches all at once, mirroring the fact that most product teams will (and should) be working on several things at the same time.
Opportunities vs. problems
An obvious difference between design thinking and opportunity solution trees is that design thinking talks about the “problem” space, whilst opportunity solution trees talk about “opportunities”. This is a purely semantic difference, with both terms referring to the same thing. Using “opportunities” instead of “problems” recognises that we don’t always need to solve user problems to create business value. Sometimes we could be working on something that has pure business value (e.g. pricing or growth).
Opportunity Solution Trees were developed by Teresa Torres in 2016, and have quickly grown into one of the most popular frameworks used by PMs and designers for navigating discovery.
What are the benefits of Opportunity Solution Trees?
Opportunity Solution Trees help you think through discovery and communicate your strategy with your team and other stakeholders.
They do this through two main benefits:
- Linking delivery and discovery to business outcomes – When read up and down, opportunity solution trees draw a direct line between work the product team is doing (discovery and delivery) to the business outcome it supports. This helps everyone understand why a piece of work is important.
- Prioritizing between alternatives – When read side-to-side, opportunity solution trees help you prioritize between alternatives at the same level. E.g. which opportunities should we pursue first? Which solutions are most promising?
Together these lead to better decision making, and more confidence in what to do next.
Build confidence in your roadmap with our 6 week course:
Product Discovery
When to use an Opportunity Solution Tree
Opportunity Solution Trees are a great tool to use when the following conditions are met:
- You’re working on an established product – you need to have some opportunities and solutions to map out. If instead you’re working on a 0 -> 1 build, then you’re trying to figure out what your value prop is, and what a sensible MVP might look like. In this case, you’re better off doing some deep user interviews and using design thinking to get going.
- You’re in a “blue phase” – you should be working on an empowered, outcome-driven team. If on the other hand you’re in a “red phase” being asked to deliver part of a larger project, then likely someone else will have decided the solution you’re building. Your primary concerns will be managing timelines and dependencies, rather than additional discovery.
How to build an Opportunity Solution Tree
Opportunity Solution Trees are constructed top-down to start with, and there are four key steps to building one, accounting for the four different levels that they have:
- Outcome
- Opportunities
- Solutions
- Assumption Tests
Let’s run through each of these in more detail:
Outcome
Most product teams are given objectives by product leaders or CEOs, but you might need to refine this into something more concrete to prevent any misalignment.
We like to use a combination of mission + metrics to define an outcome:
- Mission – an inspiring statement about what you’re trying to achieve. You can often interpret this as your purpose.
- Metrics – how you’ll know whether you’ve achieved your mission. The metrics should be the measurement of the mission, not the definition of it. A good format is: Move [metric] from [baseline] to [target] by [date]
For example:
Mission: deliver a smooth onboarding experience.
Metric: increase onboarding flow completion from 85% to 92% by May 31st.
Outcome for an OST It’s worth noting that most product teams aren’t (and shouldn’t) be given a really high level business outcome such as “increase revenue” or “maximize growth”. Vague goals like this tend to define such a big opportunity space that unless the team is very senior, it can find it difficult to know where to start. “Creativity loves constraints” as the saying goes – if you’re a CEO or product leader, you’ll get better results from your teams by giving them a narrower outcome to focus on.
Opportunities
Opportunities branch off outcome in OST Once you have a clear outcome in mind, then you are ready to start mapping out the opportunity space, and prioritizing 1-2 opportunities to focus on.
Mapping opportunities
To understand what opportunities exist, you’ll want to conduct a mixture of generative research:
- User interviews – speaking directly to users to understand their world view and experience.
- Behavioral analysis – exploring the data you have on users to find patterns.
- Process mapping – visualizing processes and user flows to understand all the touchpoints and interactions.
- Subject matter experts – getting input from stakeholders and others who know the space really well.
This is very similar to how you would research the problem space in design thinking.
As you discover opportunities, you can add them to your Opportunity Solution Tree, filtering out any user problems or opportunities that don’t actually relate to your desired outcome. Just because a user complains about something, or a stakeholder mentions it, doesn’t make it an opportunity.
Example:
You’re a PM at an e-commerce company, and your desired outcome is to improve activation – i.e.the number of users making their first purchase. You’ve been speaking to existing users, and discovered that the main frustrations they have are:
a) finding the right items
b) the returns process if they buy the wrong thing
a) is an opportunity. Making it easier to find the right items could increase the number of users making a first purchase.
b) is not an opportunity. This problem only appears after a customer has made their first purchase. Solving this problem might be a good thing to do in general, but won’t help you reach your objective.
Prioritizing opportunities
As you map out the opportunities that you could address to reach your objective, you want to continually prioritize them in order to focus on only a few at a time. You should have a hypothesis of which opportunities would result in the biggest impact if addressed.
Often this is obvious. One opportunity is continually talked about by users, or has a much stronger mechanism to help you reach your outcome.
If not, then remember that this is a political process – ultimately you want consensus and buy-in to the opportunities you choose, as well as to be objectively right.
Four broad classes of activities can help you prioritize opportunities:
- Opportunity sizing – Creating an impact model to understand how much this opportunity could contribute to the outcome you are aiming for.
- Customer factors – Understanding how many users would be affected by addressing this opportunity (i.e. reach / incidence) and how important it is to them (i.e. severity).
- Company factors – Understanding the wider business implications and alignment with your overall company mission, vision and strategy.
- Market factors – Assessing how addressing this opportunity would affect your product’s position in the marketplace.
Effort is not a part of this prioritization, because we’re not assessing solutions yet. We don’t want to pre-judge the difficulty of tackling an opportunity before we’ve had a chance to generate a variety of options. Whilst the opportunities we start with might require lots of effort, a simple and effective solution might appear quite readily if we know this is the key opportunity to work on.
If there is a clear right answer, then build a case for it and persuade others. If several opportunities appear roughly equal then don’t sweat it too much – it doesn’t matter which one you choose! Start with whichever is politically easiest or you personally prefer.
As we said, you should treat this prioritization as a hypothesis and accumulate evidence for or against it as your work continues.
Whatever you do, don’t focus on too many opportunities at the same time, and ideally focus on just 1-2. Splitting your time between multiple opportunities means that you split your learning and effort, and will make less progress against any given opportunity. Once you factor in switching costs, you’ll tend to go slower overall.
Solutions
Solutions branch off opportunities in OST You can’t create value without shipping solutions, and often the best learning comes from exposing potential solutions to real users. Having decided on an opportunity to focus on, you can start thinking about what solutions make sense, and how to prioritize them.
Generating solutions
Again, this mirrors design thinking – this time the ideation phase. You might want to run an ideation session with a diverse group of stakeholders, or you might prefer to let your designer own this.
The key here is to focus on quantity before committing to anything. If you don’t have any alternatives to choose between, then you have nothing to compare options against. There is no strategy without options.
Prioritizing solutions
Unlike opportunities, where it generally makes sense to focus on one at a time, in the solution space, it often makes sense to consider multiple options at once.
The best product teams work on a small set of solutions (perhaps 4-8) in parallel. Whilst there’s always a hypothesis about the sequence these should be built in, doing more discovery or shipping any one of these solutions will likely tell us more about the others.
At the same time, it’s very common for discovery to decrease our confidence in a solution, and in this case it’s helpful to have other solutions in the backlog that we can pull forward. This will give us time to iterate on or discard the initial idea we were working on.
How much discovery is enough? Well this depends on a number of factors such as:
- Cost of development – time and money to build the solution
- Downside scenario – how bad a worst case scenario is
- Company maturity and culture – what’s at stake (e.g. revenues) and our decision-making culture
- Opportunity cost – what else we could build instead
But it’s also a question of time. In an ideal world you’ve increased our confidence beyond the risks you see in a feature by the time it reaches the top of the backlog. If you haven’t, then you need to take a call on whether to ship it anyway or somehow fill time (e.g. working on bugs or tech debt).
Planning which assumptions you should test helps make sure that you make the most of your time, and increases the chances that you have sufficient confidence in every solution you build.
Assumption Tests
Assumption tests mapped off potential solutions in an OST Whenever you launch a new solution, you’re making a bet that you hope will create business or user value. There are four types of risk that contribute to the overall odds of a solution working:
- Value risk – Do customers really want this? Do they value it?
- Usability risk – Can users understand this? Do they know how it works?
- Technical risk – Can we build this? Is it scalable, secure and reliable?
- Business risk – Can the business deliver this? Does it create operational complexity? Is this legal?
You want to reduce this risk to a manageable level before you commit to shipping a given solution. The best PMs tackle the biggest risks upfront, and build confidence in a solution by running successive assumption tests that push the solution up the confidence scale.
There are two frameworks to help you think this through:
- Assumption mapping – identifying and prioritizing the components of risk for a solution
- Iterative testing – systematically increasing confidence in the solution overall
Assumption mapping
Assumption mapping matrix You can identify assumptions by running through your proposed solution and noting down the assumptions across the four types of risk (value, usability, technical, business).
A great way to do this is to pull together a cross functional group, and get different people to assess the idea for different classes of risk. E.g. an engineer looks for technical assumptions, a designer looks for usability assumptions and so on.
You can then plot your assumptions on a 2×2 matrix of risk vs. certainty.
Risk (high – low) is how critical this assumption is to the effectiveness of the solution. If an assumption being false would mean the whole solution was useless, it’s high risk (e.g. everyone will be happy to pay in bitcoin).
Certainty (known to unknown) is how much supporting evidence you have for your assumptions right now. So if you have some evidence supporting an assumption, but would like more, that’s in the middle. If the assumption is a wild guess that’s unknown (far right).
You can then prioritize the high risk, low certainty assumptions as the key ones to test first. This allows you to address component risks one at a time, rather than testing the whole solution, which is a much more efficient way to build confidence in a solution to begin with.
Think of each assumption as a hypothesis, and then think about tests that you can run which would help you gather evidence to support or reject this hypothesis.
A test might be:
- Building a prototype and showing it to users
- A technical spike to understand how you’d build a feature
- Speaking to stakeholders to understand the business implications of a feature
- Behavioral analysis to understand real user behavior in more detail
- And so on
Ideally you’ll want to run quick, cheap tests first to gain some confidence, before you run more expensive, elaborate tests to minimize really important risks. This is the basis of iterative testing.
Iterative testing
Confidence in a solution does not come all at once, and it’s rare to have complete certainty on a given assumption. In most cases, you build confidence in a solution over time, by running successive tests, each of which increase your confidence, but require more time and money to do.
For example, if you’re trying to reduce technical risk:
- A conversation with your tech lead about whether it’s theoretically possible might take a few minutes.
- The tech lead digging into the code to check a few things might take an hour.
- A technical spike might be timeboxed for a day or two.
And if you’re trying to reduce usability risk:
- Getting feedback from your team on a mockup might take minutes.
- Getting feedback from a handful of real users on a high-level prototype might take hours.
- Getting feedback from lots of real users will likely require a detailed prototype or MVP, which could take days or weeks to build.
You don’t want to commit to the MVP before you’ve got feedback from your team. But your team’s feedback alone isn’t sufficient to justify building the feature.
Instead think of different types of evidence as lying in a hierarchy:
You work your way up this scale in steps, running tests on major assumptions at all or most levels:
As you go, you map the main assumptions you have, and your overall level of confidence in each one on your Opportunity Solution Tree. For each assumption in your opportunity solution tree, you’re not trying to run any test, or to jump straight to the highest level of confidence possible. Both of these approaches would lead you to running time-consuming, expensive tests when you could have uncovered problems far quicker and cheaper.
Instead, you’re trying to understand the overall risk profile of a feature across the four classes of risk (value, usability, technical and business) and plot the next move that makes sense because it increases your confidence for the least amount of effort.
Responding to assumption tests
Every time you run a test you’re gathering evidence about the assumptions you have. What you do next depends on whether that evidence supports your assumption or not:
- Supports assumption – invest in testing higher up confidence scale, or build live product
- Evidence inconclusive – roll in learnings and run test again
- Rejects assumption – deprioritize this solution against others in your OST to give you time to rethink it.
Common problems
One of the main benefits of using Opportunity Solution Trees is that they visualize some common missteps in discovery, making them easier to spot and avoid.
Let’s run through a few of these now, as well as the tactics you can use if you find yourself facing any of these problems.
Solutions not linked to outcomes
The opportunities you’re addressing and the solutions you’re building won’t make a significant impact on the outcome you want. Or you haven’t even defined what outcome you’re looking for.
Solution
Before you do anything else, have a go at defining the outcome yourself from whatever business context you have. Then share this with your key stakeholders to get their opinion and align with them. If you get different directions back from different stakeholders, don’t fight with them directly. Get everyone into the same room and facilitate a conversation about what’s actually the most important thing to do.
You can’t win if everyone is expecting you to do different things, and if you don’t have a clearly stated outcome, this is just about guaranteed.
Multiple competing outcomes
You’re being spread across multiple outcomes, and as a result your work is very unfocused. This can happen very easily if you’re using OKRs and have defined multiple Key Results that take you in different directions (rather than being different ways to express a single Objective).
Solution
If you’re setting your own outcomes, then decide which is most important, and park the rest. Progress is inversely proportional to the number of priorities you have, so you want to keep the number of outcomes you have to one if at all possible.
That said, it’s not always possible to get stakeholders to realize the downside of having too many competing outcomes. If you can, get them to stack rank the outcomes so you know what to focus on, as well as a steer on what proportion of your time they are expecting you to spend on a given outcome. This works better when you convert it from a theoretical percentage into days / weeks.
“Ok, so you want us to spend 50% of our time improving search, and then another 25% of our time looking at check out and onboarding.
So that means we’ll do 6 weeks work on search, and 3 weeks on each of check out and onboarding.”
You can emphasize the value of focusing on fewer things by reminding them how long it’s taken to ship features in the past (which is almost always longer than people expect).
Lack of alternatives
You don’t have any alternatives, either at the opportunity level, solution level or both. This happens when you haven’t done enough generative research to uncover more user problems, or enough ideation to create more potential solutions. Without alternatives, you can’t know that you’re focusing on the highest value work because you have nothing to compare to.
Solution
Get out there and start speaking to users to understand what other problems they have. Run an ideation session to come up with some more potential solutions. You can do this as you continue to work on the single opportunity / solution that you know about right now – it doesn’t need to slow you down.
As you gain more knowledge about the alternatives you can then switch over to higher impact work if you find it, or you’ll gain confidence that you’re already working on the highest impact things.
Too many solutions / assumption tests
You’ve got far too many solutions or assumption tests to manage. You’re getting lost in the weeds. This can happen when you’ve got lots of incoming requests from other teams and customers. The root cause is generally that your strategy isn’t strong enough – you don’t have a good high level filter to keep bad ideas out.
Solution
Stop looking at your backlog and Opportunity Solution Tree for a moment and pull out a blank sheet of paper. What would really move the needle in your opinion? And why do you think this?
Product work is hypothesis-driven. I.e. you don’t come up with loads of ideas and then decide what to do, you need to have an idea of what to do, and then evolve that as you gain more evidence. If you don’t have a hypothesis to start with then you’ll end up paralyzed by a never ending list of discovery to do to figure out what to work on.
If you need more help getting started with a strategy hypothesis then check out our snap strategy template.
Mixing solutions and opportunities
You’re confusing a solution for an opportunity. You don’t know if customers will value your solution, and you haven’t considered alternatives. This can happen when you (or a stakeholder) is so convinced by a solution that they try to frame it as an opportunity to make sure it’s addressed. And it’s quite easy to do this subconsciously, without even realizing the mistake you’re making.
Solution
The test here is to ask yourself: “What are the different ways I could address this opportunity?”. If there is only one way to tackle it, then it’s a solution. Opportunities will be susceptible to multiple solutions.
Consider the two following examples:
- “I want to filter my search by color” -> the only approach here is to build a color filter, so this is a solution
- “I want better search results” -> you could build a color filter, personalized results, change the sorting algorithm…. There are loads of potential solutions to this statement, so it’s an opportunity.
If you find that you’re working on a solution and don’t know what the opportunity is, then ask yourself: “Why is this important?” The answer will likely be the opportunity you’re looking for.
Recap
Opportunity Solution Tree Template: Miro
Opportunity Solution Trees (OSTs) are a powerful, visual technique for mapping out the discovery you are doing. They help connect experiments and features to larger business outcomes, as well as help you prioritize the most important work to do.
Opportunity Solution Trees have four main layers:
- Outcome – the result you are aiming for
- Opportunities – the challenges you can tackle to deliver your outcome
- Solutions – potential answers to the opportunities you’ve identified
- Assumption tests – ways of increasing your confidence that you solution will work
You can create an Opportunity Solution Tree once you’ve done a few user interviews to help you map out the space. After that, you want to be hypothesis-driven, mapping out your current thinking as soon as possible, and then continually updating your tree as you gather more information.
Build confidence in your roadmap with our 6 week course:
Product Discovery
Hustle Badger Resources
Templates:
- Opportunity Solution Tree Template: Miro
Articles:
Further Reading
