The Opportunity Solution Tree Explained
An opportunity solution tree is a visual diagram, created by product discovery expert Teresa Torres, that connects a desired business outcome to the customer opportunities (unmet needs or pain points) that could drive it, the possible solutions for each opportunity, and the experiments used to test those solutions. It exists to make a team's discovery reasoning visible and structured, instead of jumping straight from "we have an outcome to hit" to "let's build this one feature," skipping the deeper thinking about what problem is actually worth solving.
Quick facts
- The tree has four levels: Outcome (the top goal), Opportunities (customer needs/pain points), Solutions (possible ways to address an opportunity), and Experiments (ways to test a solution before fully building it).
- Created by Teresa Torres as part of her "continuous discovery" approach to product work.
- It deliberately shows multiple opportunities and multiple possible solutions per opportunity, rather than jumping straight to one predetermined solution.
- The structure keeps a team's reasoning visible — you can see exactly why a given solution was chosen, tracing back to a specific opportunity and outcome.
The four levels, explained
| Level | What it represents | Example |
|---|---|---|
| Outcome | The business goal you're trying to achieve | "Increase 30-day retention for new users" |
| Opportunities | Customer needs or pain points that, if addressed, could drive the outcome | "New users don't understand how to set up their first project" |
| Solutions | Possible ways to address a specific opportunity | "Add a guided setup wizard," "add contextual tooltips," "add a sample project template" |
| Experiments | Small, fast ways to test whether a solution idea actually works before fully building it | "A/B test the guided wizard with a subset of new users" |
A worked example
Outcome: Increase 30-day retention for new users from 25% to 35%.
Opportunity 1: New users don't understand how to set up their first project.
- Solution A: Add a guided setup wizard.
- Experiment: A/B test the wizard with a subset of new signups.
- Solution B: Add a pre-built sample project template.
- Experiment: Offer the template to a subset of new users and measure setup completion.
Opportunity 2: New users don't see value until they invite a teammate, but rarely do so proactively.
- Solution A: Prompt users to invite a teammate right after their first successful action.
- Experiment: Test the prompt's timing and copy with a small user segment.
This structure makes the team's reasoning fully visible: two distinct opportunities were identified as plausible drivers of the retention outcome, and multiple solution ideas were generated for each — rather than a team simply deciding "let's build a setup wizard" without showing the underlying reasoning connecting it back to a real customer opportunity and the outcome it's meant to serve.
Why showing multiple opportunities and solutions matters
A common failure mode in product work is jumping straight from a business outcome to a single predetermined solution — "we need better retention, let's build gamification" — without genuinely exploring what customer problem is actually driving poor retention, or considering more than one possible way to address it. The opportunity solution tree structure forces this broader exploration to happen visibly, making it much easier for a team (and stakeholders) to see whether a chosen solution is genuinely grounded in a real, well-understood customer opportunity, or is really just an assumption dressed up as a plan.
How the tree connects to continuous discovery
The opportunity solution tree is a core tool in Teresa Torres's broader "continuous discovery" approach, which emphasizes ongoing, regular customer contact (rather than occasional, large research pushes) to keep the tree's opportunities grounded in real, current customer understanding. As new customer conversations surface new opportunities, or existing ones get validated or invalidated, the tree gets updated — it's meant to be a living artifact that evolves with ongoing discovery, not a one-time planning exercise.
Common mistakes when building an opportunity solution tree
- Jumping straight to solutions without genuinely exploring opportunities first. This defeats the core purpose of the tool — the value comes specifically from surfacing multiple real customer opportunities before committing to any one solution.
- Only listing one solution per opportunity. Generating multiple solution options for the same opportunity often reveals a better, cheaper, or faster approach than the first idea that comes to mind.
- Skipping the experiment level and building the full solution directly. The tree is meant to encourage testing a solution cheaply before fully committing resources to build it.
- Building the tree once and never updating it. As continuous discovery surfaces new understanding, the tree should evolve — a static, one-time tree loses much of its value over time.
FAQ
Who created the opportunity solution tree? Teresa Torres, a product discovery coach and author, developed it as part of her broader continuous discovery framework, widely taught and adopted across the product management field.
How is this different from a standard product roadmap? A roadmap communicates planned initiatives and rough timing to stakeholders. An opportunity solution tree is more of an internal discovery and reasoning tool, showing the thinking that connects outcomes to opportunities to solutions — the roadmap often reflects decisions made using insight from a tree like this, rather than replacing it.
Does every opportunity need its own experiment before building a solution? Not strictly required for every case, especially for lower-risk, well-understood solutions, but testing cheaply before fully committing resources is generally recommended, especially for larger or more uncertain solution ideas.
Can an opportunity solution tree be used by teams without a dedicated user researcher? Yes — while formal research support helps validate opportunities more rigorously, the core practice of mapping outcomes to opportunities to solutions can be done by any product team willing to engage in structured, ongoing customer conversations themselves.