By Simon Sovič, Senior Product Manager
You have a list of feature requests, a backlog full of ideas, and a team waiting for direction. The opportunity solution tree is the tool that turns that chaos into a structured decision-making process. This guide explains what it is, how product managers use it day to day, and where most teams get it wrong.
What the Opportunity Solution Tree Actually Is
The opportunity solution tree (OST) is a visual framework created by product discovery coach Teresa Torres. It connects four layers: a desired outcome at the top, opportunities beneath it, solutions under those opportunities, and experiments at the bottom.
Think of it as a map from "what result does the business need" down to "what small test can we run this week." Each layer informs the one below it. You do not jump from outcome to solution. You first find the opportunity, meaning a specific customer problem or unmet need.
The key insight is that solutions are cheap. Opportunities are what matter. If you pick the wrong opportunity, even the best-built solution will not move your outcome metric.
The Four Layers Explained
Layer 1: Desired Outcome
This is a business metric you want to move. It should be specific and measurable, for example "increase weekly active users by 15%" or "reduce churn from 8% to 5% within two quarters." Vague outcomes like "improve user experience" make the whole tree impossible to build correctly.
One common mistake is treating the outcome as a product goal ("ship a new onboarding flow") rather than a business or customer result. The outcome sits at the top because everything else serves it.
Layer 2: Opportunities
Opportunities come from customer research. They are not assumptions your team makes in a meeting room. They are problems, pain points, or unmet needs that real users have expressed. You surface them through interviews, usability sessions, support tickets, and behavioral data.
Each opportunity should be framed from the customer's point of view. "Users struggle to find their saved items on mobile" is an opportunity. "We should improve search" is already a solution in disguise.
The tree branches here. One outcome may connect to dozens of opportunities. That branching is intentional. It forces you to compare opportunities before committing to one.
Layer 3: Solutions
Only after you have chosen an opportunity do you brainstorm solutions. Solutions are the specific product changes or features you might build. Because you are now solving a defined problem, your solutions become sharper and easier to evaluate.
Multiple solutions can address the same opportunity. The tree structure makes that visible. You are not just picking a feature from a backlog. You are choosing which solution best addresses the opportunity you have already validated as worth pursuing.
Layer 4: Experiments
Experiments test the assumptions underneath each solution. Before you build anything significant, you run small, fast tests to check whether your solution actually addresses the opportunity and whether it moves the outcome.
An experiment might be a prototype test, an A/B test on a copy change, or a five-minute task test with three users. The goal is to reduce the risk of building the wrong thing.
How Product Managers Build the Tree in Practice
In practice, building the tree is an iterative process, not a one-time workshop activity. Here is how a typical product manager works through it.
- Align on the outcome.Work with stakeholders to agree on one measurable outcome for the current quarter. One outcome keeps the tree focused.
- Run continuous discovery.Interview customers weekly, even briefly. Document the problems and frustrations they mention. These become your raw material for opportunities.
- Map opportunities to the outcome.Review your research notes and identify which customer problems, if solved, would move the outcome metric. Add these as opportunity nodes on your tree.
- Prioritize one opportunity.Use criteria like frequency (how often does this problem occur), impact (how much does it affect the outcome), and addressability (can you realistically solve it) to pick where to focus.
- Brainstorm solutions for that opportunity.Generate at least three to five distinct solutions. Avoid anchoring on the first idea.
- Identify assumptions.For each solution, list the key assumptions that must be true for it to work. Then design the smallest possible experiment to test each assumption.
- Run experiments, update the tree.As you learn, update your tree. An experiment result might invalidate a solution or even reframe the opportunity itself.
This cycle repeats continuously. The tree is a living document, not a finished diagram you present once and archive.
How to Size a Market Opportunity as a Product Manager
The opportunity solution tree tells you which opportunities are worth solving for your existing users. But before you commit resources, you also need to understand the scale of the opportunity. This is where market sizing comes in.
Sizing a market opportunity as a product manager does not require a full analyst report. A basic framework is enough to make a confident prioritization decision.
| Sizing Method | What It Measures | Best Used For |
|---|---|---|
| TAM (Total Addressable Market) | The full revenue if you captured every potential customer | Investor conversations, long-range strategy |
| SAM (Serviceable Addressable Market) | The portion of TAM you can realistically reach with your product | Roadmap scoping, resource allocation |
| SOM (Serviceable Obtainable Market) | The share you can capture in the near term given your current go-to-market | Quarterly goal-setting, team prioritization |
| Customer segment sizing | How many of your existing users experience a specific problem | Opportunity prioritization within the OST |
For day-to-day opportunity prioritization, the most useful number is the last one. How many of your actual users have this problem, and how often? You can estimate this from support ticket volume, survey data, or a quick cohort analysis in your analytics tool.
If you are evaluating a new market entirely, a bottom-up estimate is more reliable than top-down. Count the number of target customers you can identify, multiply by the value each one would represent, and you have a grounded estimate rather than a number pulled from a market research PDF.
Pairing market sizing with the opportunity solution tree gives you two things: a reason to pursue an opportunity (it is large enough to matter) and a method for pursuing it (a structured path from problem to experiment).
Where Teams Go Wrong With the Opportunity Solution Tree
From experience, the most common failure is treating the tree as a documentation exercise rather than a thinking tool. Teams fill it in after decisions are already made. That defeats the purpose.
Here are the other mistakes that come up most often.
- Skipping the discovery step.Adding opportunities based on stakeholder opinions rather than actual customer research. The tree is only as good as the evidence behind each opportunity node.
- Listing solutions as opportunities."Add a dashboard" is a solution. "Users cannot track their progress over time" is an opportunity. The distinction matters because it keeps your options open.
- Branching too wide, too fast.A tree with 40 opportunities and 80 solutions feels thorough but becomes unmanageable. Keep the tree focused on your current outcome and prune aggressively.
- Ignoring the experiment layer.Many teams stop at the solution layer and go straight to building. Experiments exist to prevent that. A one-day prototype test can save six weeks of engineering time.
- Treating the tree as final.New research should update the tree regularly. If you built the tree in January and it is now April with no changes, it has already stopped reflecting reality.
Building better products requires the same discipline that building a business does. Staying focused on the right problems, avoiding distraction, and following through on your decisions. If you are a founder who also plays the product role, that discipline becomes even harder to maintain. Tools like an AI mentor for entrepreneurs Can help you stay accountable to the frameworks you commit to using.
Related: if you find yourself procrastinating on the discovery work, the structured frameworks, or the hard conversations with stakeholders, you are not alone. Founders and PMs both struggle with this. Accountability tools for solopreneurs Are designed for exactly this kind of consistent, repeated work that does not have an immediate deadline forcing it.
For those also thinking about the customer journey that connects to each opportunity, our guide on Customer journey mapping for product managers Covers how to document and use journey data in a way that feeds directly into the OST.
FAQ
What is the difference between an opportunity and a solution in the opportunity solution tree?
An opportunity is a customer problem, pain point, or unmet need. A solution is a specific thing you might build or change to address that problem. The distinction matters because if you jump straight to solutions, you narrow your thinking before you have fully understood the problem. In the tree structure, one opportunity can have many possible solutions. Keeping them separate forces you to fully explore the problem space before committing to a specific approach.
How often should a product manager update the opportunity solution tree?
The tree should be updated continuously as new research comes in. Many product teams review it weekly during their discovery check-ins and update it whenever a customer interview, experiment result, or data analysis changes their understanding. The tree is a working document, not a static artifact. If it has not changed in a month, that usually means discovery has stalled, not that you have fully mapped the space.
Can a solo founder or solopreneur use the opportunity solution tree?
Yes. The tree scales down well. As a solo founder, you are both the product manager and the decision-maker, which means you have full authority to act on what you learn. The discipline of separating outcomes, opportunities, solutions, and experiments is valuable even for a one-person team because it prevents you from building features based on your own assumptions rather than real customer evidence. The main challenge for solo founders is keeping up with the discovery work. That requires consistent habits and, often, external accountability.
How do you choose which opportunity to prioritize on the tree?
There is no single formula, but a practical approach combines three criteria. First, frequency: how often do customers experience this problem. Second, impact: if you solved it, how much would it move your outcome metric. Third, addressability: given your current team and resources, can you actually build a solution. Some teams add a fourth factor, reach, which is how many customers are affected. Score each opportunity on these criteria, compare the scores, and pick the one with the strongest case. Then validate your choice with a quick round of interviews before committing significant resources.
Is the opportunity solution tree the same as a product roadmap?
No. A roadmap shows what you plan to build and when. The opportunity solution tree shows the reasoning behind those decisions. The tree is the discovery and prioritization tool. The roadmap is the communication and planning output. Many teams build their roadmap from the tree, which makes it easier to explain to stakeholders why specific features are or are not included. A roadmap without a tree behind it is a list of bets without documented evidence for why they were made.
Published with SuperDuperSEO