Opportunity Solution Tree
Map a desired outcome to the customer opportunities that could drive it, the solutions that might address each opportunity, and the assumption tests that check each solution.
“An opportunity solution tree is a simple way of visually representing the paths you might take to reach a desired outcome.”
To an executive
A simple tree links each piece of work to a customer need and a business outcome, so you can see why it is being built and what else was considered.
To an engineer
Before designing a solution, trace it to an opportunity and an outcome, compare at least three options, and test the riskiest assumption before committing architecture to it.
The idea
Teresa Torres, a product discovery coach who writes at Product Talk, introduced the opportunity solution tree as a way for product teams to make their thinking visible. It has four levels:
- Outcome, at the root: the result the team has been asked to drive. Torres recommends a product outcome, a change in customer behaviour or sentiment the team can influence, rather than a broad business metric.
- Opportunities, beneath it: the customer needs, pain points and desires that, if addressed, would move the outcome. They come from talking to customers, not from the team's feature ideas, and are grouped into parent and child opportunities.
- Solutions, under a chosen target opportunity: candidate ways to address it. Torres recommends comparing at least three.
- Assumption tests, under each solution: small experiments that check its riskiest assumptions and decide whether to drop, refine or pursue it.
The tree is a living picture, updated as interviews and tests teach the team more.
Why it works
It separates the problem space from the solution space. Teams tend to jump from an outcome straight to a favourite feature. Forcing opportunities in between keeps the customer's problem in view.
Comparing options beats evaluating one. A single idea gets a yes or no; three ideas side by side get a real trade-off discussion, which is where architects add most value.
It makes reasoning reviewable. Stakeholders can see why a solution was chosen and what else was considered, and argue with the reasoning rather than the conclusion.
Where it applies
- Discovery work before architecture commitments, so expensive design choices follow a tested opportunity.
- Design reviews, checking that a proposed system traces to an outcome and an opportunity.
- Stakeholder alignment, where many requests compete and the tree shows which opportunity each one serves.
- Platform roadmaps, mapping internal teams' needs as opportunities before committing to platform features.
How to apply
- Agree one outcome. Make it a behaviour the team can influence, such as "more sellers list a second item within a week".
- Map opportunities from research. Use recent customer interviews, phrase opportunities in the customer's words, and group them.
- Pick a target opportunity, judged by size, fit with strategy and the team's ability to act.
- Generate at least three solutions, including cheap and non-technical ones.
- Test assumptions before building. For each solution, list what must be true, about desirability, usability, feasibility and viability, and test the riskiest first.
Example scenario
A marketplace team was asked to increase repeat sales by sellers and arrived at the architecture review with a design for a new pricing-recommendation service, built on a machine-learning platform the company did not yet have.
The architect asked to see the tree. Seller interviews showed the main opportunity was "I don't know whether my item will sell before I pay listing fees", with pricing as only one branch. The team added two more solutions: showing recent sales of similar items, and a free relisting window. Assumption tests showed the recent-sales view, built on existing search data, moved second listings almost as much as the pricing service was expected to, at a fraction of the cost. The machine-learning platform went back on the long-term roadmap.
Questions to ask
- Which outcome is this solution meant to move, and through which customer opportunity?
- What other solutions did we consider for this opportunity before choosing this one?
- What is the riskiest assumption behind this solution, and how could we test it this week?
When not to use it
- Pure technical work, such as an upgrade or a compliance change, with no customer outcome to discover.
- Teams without access to customers, where the opportunities would be invented and the tree would only decorate a plan.
How it misleads you
A tree drawn once to justify a decision already made is theatre. So is one filled with feature ideas dressed as opportunities. Keep opportunities in the customer's words, keep the tree current, and be suspicious when every branch leads to the solution someone wanted at the start.
In the wild
Further reading
Last reviewed · Suggest an improvement