Opportunity Solution Tree
An opportunity solution tree (OST) is a visual map that connects a desired outcome to the customer opportunities that could drive it, the solutions that might address each opportunity, and the assumption tests used to evaluate those solutions. Created by product discovery coach Teresa Torres, it helps product teams make their reasoning visible and decide what to work on next.
How an Opportunity Solution Tree Works
The tree has four levels, read from top to bottom:
-
Outcome. The root is one measurable outcome the team is responsible for, ideally a product outcome that reflects customer behavior, such as "increase the share of new accounts that finish setup in their first week." Torres recommends one outcome per team at a time.
-
Opportunities. Below the outcome sit opportunities: unmet customer needs, pain points, or desires that, if addressed, would move the outcome. They should come from research, especially story-based customer interviews, not from brainstorming. Large opportunities break down into smaller, more specific child opportunities.
-
Solutions. Under a chosen target opportunity, the team lists several possible solutions: features, services, or changes that could address it. Torres offers a simple check for telling the two apart: if there is more than one way to address something, it is an opportunity, not a solution.
A common mistake is recording a solution in disguise as an opportunity. "I wish the app had a calendar view" is a request for a specific solution. The opportunity behind it might be "I can't see when my deadlines clash," which a calendar, an alert, or a weekly summary could each address.
-
Assumption tests. Under each solution, the team identifies the assumptions it depends on and designs small tests to check them before building.
The tree is a living artifact. Teams update it as interviews reveal new opportunities and tests rule out solutions. It is a core tool in Torres's approach to continuous product discovery, in which the team building the product talks to customers at least weekly.
Why an Opportunity Solution Tree Matters
Product teams are often asked to deliver outcomes but receive requests framed as features. The tree sits between the two. It forces the question: which customer need does this feature address, and how would addressing it move our outcome?
It brings several practical benefits:
- Compare and contrast. Weighing several solutions for one opportunity, instead of judging a single idea on its own, leads to better decisions.
- Visible reasoning. Stakeholders can see why the team picked a target opportunity and what it set aside, which makes alignment conversations easier.
- Smaller bets. Breaking big opportunities into specific ones produces problems small enough to solve and test quickly.
- Learning before building. Assumption tests catch weak ideas before they consume engineering time.
The tree pairs naturally with an outcome-based roadmap and with OKRs, since the outcome at its root is often the same metric the team has committed to. For how discovery findings become testable hypotheses, small experiments, and requirements, see SaaS idea validation loops from customer discovery to PRDs.
Opportunity Solution Tree Example
A team at a meal-kit subscription service owns the outcome "increase the percentage of subscribers who stay past week eight."
Interviews reveal several opportunities. Some subscribers say they lack time to cook on weeknights. Others are bored of the recipes. Others miss deliveries because nobody is home. The team breaks the time problem into smaller needs, such as "prep takes longer than the recipe card says" and "I don't know which kit to cook first before ingredients spoil."
They choose the time problem as their target and generate three solutions: a "15-minute meals" filter, a suggested cooking order based on ingredient freshness, and partly prepared ingredients. The cooking-order idea depends on a key assumption: subscribers look at the app before they cook. A quick test, an in-app message sent to a small group, shows whether people open the guide at all before the team builds anything more.
Opportunity Solution Tree vs. Feature Backlog
A backlog lists work to be delivered. An opportunity solution tree explains why that work might matter. Items on a backlog should trace back to a branch of the tree. Features that cannot be traced to any opportunity or outcome are worth questioning before they are built.