What is an Opportunity Solution Tree?
An Opportunity Solution Tree (OST) is a visual map of how a product team plans to reach a measurable outcome. Teresa Torres introduced it in her book Continuous Discovery Habits, and it has become one of the most widely used frameworks in product discovery.
The tree has four layers, read from top to bottom:
- Outcome: the measurable change in customer behavior your team is trying to drive
- Opportunities: customer needs, pain points and desires that, if addressed, would move the outcome
- Solutions: ideas for addressing a specific opportunity
- Assumption tests: small experiments that check whether a solution will actually work
The power of the tree is that every idea has to justify its place. A solution sits under an opportunity, an opportunity sits under the outcome, and anything that doesn't connect simply doesn't belong on the tree.
Why product teams use an OST
Most product backlogs are a list of features with no visible reason for existing. Someone asked for it, a competitor has it, or it came up in a planning meeting. An Opportunity Solution Tree fixes that by making the reasoning explicit.
- It keeps the team focused on one outcome instead of a long list of requests
- It separates problems from solutions, so you don't fall in love with the first idea
- It makes trade-offs visible: stakeholders can see which opportunities you chose and why
- It turns discovery into a habit: the tree grows every week as you learn from customers
- It gives the team a shared language: "which opportunity does this serve?" becomes a normal question in every meeting
The tree also changes the conversation with stakeholders. Instead of debating whether feature A or feature B is more important, you discuss which customer need matters most for the outcome, which is a far more productive discussion.
Step 1: Start with one product outcome
Everything starts with a single, measurable product outcome: a change in customer behavior that your team can directly influence. "Increase the share of new users who plan a full week of meals in their first seven days from 20% to 35%" is a product outcome. "Launch the meal planner" is an output.
If you are unsure what makes an outcome good, read our guide on how to write product outcomes. The short version: it should describe behavior, be measurable, and sit within your team's influence.
Resist the temptation to put several outcomes at the root. One outcome per tree keeps the team's attention in one place. If you are responsible for more than one outcome, build a separate tree for each and work on them one at a time.
Step 2: Discover opportunities through customer interviews
Opportunities don't come from brainstorming sessions. They come from talking to customers about what they actually did, not what they say they would do.
The most useful interviews ask for specific stories. "Tell me about the last time you planned dinner for the week" gets you a real account of what happened, including the workarounds and frustrations the customer may not even notice anymore. "Would you use a meal planner?" gets you a polite guess.
After each interview, capture what you learned in a short interview snapshot: who you spoke to, a memorable quote, the key moments in their story, and the opportunities you heard. Write opportunities from the customer's perspective:
- "I don't know what to cook when I get home from work"
- "I waste food because I buy ingredients I never use"
- "I want my kids to eat the same dinner as the rest of us"
Notice that none of these mention a feature. If an opportunity sounds like a solution ("I want a shopping list button"), dig for the need behind it. Ask yourself what the customer is trying to achieve, and write that down instead.
Torres recommends interviewing customers every week, even when you aren't working on a specific project. A steady stream of small conversations keeps the tree grounded in what customers actually experience, instead of what the team remembers from research done months ago.
Step 3: Structure the opportunity space
As interviews pile up, you will have dozens of opportunities. Group related ones and arrange them as parent and child opportunities. Big, abstract needs sit near the top; specific, solvable ones sit lower down.
A useful way to find the top-level structure is to map the customer's experience as a sequence of moments, for example: deciding what to eat, planning, shopping, cooking and eating together. Each moment becomes a branch, and the opportunities you heard fall naturally under one of them.
This structure helps you choose. Instead of picking from a flat list, you compare sibling opportunities and ask: which one, if we solved it, would move the outcome most?
Step 4: Choose a target opportunity
Picking the right opportunity is one of the most important decisions in discovery. Compare sibling opportunities against a few questions:
- How many customers are affected, and how often do they run into it?
- How much does it matter to them: is it a mild annoyance or a real blocker?
- Does it fit your strategy and what your company is good at?
- Will solving it move the outcome, or does it matter for some other reason?
Then work your way down the tree until you reach a target opportunity that is specific enough to solve in the next few weeks. "I don't know what to cook" is broad; "I forget to plan before the week starts" is something a team can act on.
You don't need to be certain. The point is to make a good decision with the information you have, and to make the reasoning visible so others can challenge it.
Step 5: Generate several solutions
Under your target opportunity, generate at least three solutions before committing to one. The first idea is rarely the best, and comparing options forces you to think about what really matters.
For "I don't know what to cook when I get home from work", solutions might include:
- A weekly plan generated from the user's favorite recipes
- A "cook from what you have" suggestion based on the fridge
- A Sunday reminder to plan the week together with the family
Involve the whole team in ideation: product, design and engineering each see different possibilities. Engineers often know about technical shortcuts that make a cheap solution possible, and designers spot interaction patterns that make an idea feel effortless.
Step 6: Identify and test assumptions
Every solution rests on assumptions. Before you build anything, list what must be true for each solution to work: will people want it (desirability), can we build it (feasibility), will they figure out how to use it (usability), and does it make sense for the business (viability)?
Then test the riskiest ones with small, fast experiments. Testing assumptions across several solutions at once is what makes the tree efficient: you quickly learn which ideas hold up and which don't, without building any of them. Our guide to assumption testing goes through how to choose and design those experiments.
A worked example
Here is what a small Opportunity Solution Tree for a meal-planning app could look like:
- Product outcome: increase weekly active planners from 30% to 45% of users
- Opportunity: "I don't know what to cook when I get home from work"
- Child opportunity: "I forget to plan before the week starts"
- Solutions: a Sunday planning reminder, a one-tap "repeat last week" plan, a shared family plan
- Assumption: users will plan within an hour of getting the Sunday reminder
- Experiment: send the reminder to 10% of users for two weeks and compare their planning rate with everyone else
The tree is small on purpose. You work on one target opportunity at a time and keep the rest of the tree as context. When the experiment shows that the reminder alone isn't enough, the team doesn't start over: they move on to the next solution under the same opportunity, or reconsider whether it was the right opportunity.
Keeping the tree alive
An Opportunity Solution Tree is not a deliverable you produce once. It is a living document that reflects what the team currently knows. A simple weekly rhythm keeps it current:
- Interview at least one customer and add the opportunities you heard
- Review the target opportunity: is it still the right one, given what you learned?
- Update assumptions and experiments: record results and decide what to test next
- Prune: remove branches that turned out not to matter, so the tree stays readable
Share the tree in stakeholder updates. It shows progress in a way a list of shipped features can't: what you learned, what you ruled out, and why you are working on what you are working on.
Common mistakes to avoid
- Starting with solutions: if your first level is a list of features, you have a feature tree, not an opportunity tree
- Setting a business outcome as the root: revenue and churn matter, but your team can't move them directly; pick the product outcome that drives them
- Opportunities written as solutions: rewrite them as customer needs
- Only one solution per opportunity: you lose the comparison that makes the tree valuable
- Opportunities from the team's imagination: if an opportunity didn't come from a customer story, mark it as a guess and go find evidence
- Treating the tree as a one-off workshop: an OST is a living document that changes every week
Going beyond the classic tree
A classic Opportunity Solution Tree starts at the product outcome. Many teams also want to see how that outcome connects to the bigger picture. In Product Planner you can optionally add your vision, business outcomes and strategy above the product outcome, so every opportunity and solution traces back to why it matters. Leave them out and you have a classic tree.
Frequently asked questions
Who should own the Opportunity Solution Tree?
The product trio (a product manager, a designer and an engineer) owns it together. Discovery works best when the people who decide what to build are also the people who talk to customers and design the experiments.
How big should the tree be?
As big as your evidence. A tree with a handful of well-supported opportunities is more useful than one with fifty guesses. Most of the detail should sit under the opportunity you are currently working on.
Can you build an OST without customer interviews?
You can start one from existing research, support tickets or analytics, but treat those opportunities as hypotheses. Interviews are what turn a tree from the team's opinion into a map of real customer needs.
How does an OST relate to a roadmap or backlog?
The tree decides what is worth building; the backlog organizes how it gets built. Once a solution has survived its assumption tests, it moves into delivery, often through a user story map that breaks it into releasable slices.
Build your first tree
You can sketch an Opportunity Solution Tree on a whiteboard, but keeping it alive week after week is easier in a tool built for it. Product Planner gives you an interactive tree, an AI product coach that guides you step by step, and a direct path from validated solutions to a user story map. Start free and build your first tree today.