How to build an Opportunity Solution Tree
Last reviewed
Build an Opportunity Solution Tree in seven steps: pick one measurable outcome, gather existing customer input, write opportunities in the customer's words, structure the opportunity space, choose one opportunity to target, generate at least three competing solutions, then test the riskiest assumption behind the strongest one. A first version takes a few hours with the product trio.
The steps below assume you know what an Opportunity Solution Tree is. If the four layers are new to you, start there and come back.
The seven steps
- 01
Pick one outcome
Choose a single measurable change in customer behaviour that your team can plausibly influence. If you have three candidates, pick the one your next quarter actually depends on. Multiple outcomes at the root means multiple trees and no way to prioritise between them.
If what you have is a business target like revenue, translate it first. Ask which customer behaviour would move that number, and make the behaviour your outcome. The translation is real work and it is worth doing before anything gets drawn.
- 02
Gather what customers have already told you
Before adding a single node, collect your raw material: recent interview notes, support tickets, churn reasons, sales objections and usage data. The quality of the tree is bounded by the quality of this input.
Resist the urge to synthesise yet. At this stage you want quotes and observations, not themes. Themes invented too early smuggle in assumptions that nobody can trace back to a customer.
- 03
Write opportunities in the customer's words
Turn each observation into an opportunity phrased as a need, pain or desire from the customer's point of view. Keep features out of this layer entirely. If a statement names something you would build, it belongs one level down.
A practical test: read the node aloud and ask whether a customer could have said it. "Bulk import" fails. "I have to re-type data I already have in another system" passes.
- 04
Structure the opportunity space
Group related opportunities and break broad ones into narrower ones, until each leaf is specific enough that you could imagine a concrete solution. Make sure siblings are genuinely comparable, so a real choice exists between them.
This step is where most of the thinking happens. Expect to rearrange several times. A tree where every branch sits at a different level of abstraction cannot be prioritised.
- 05
Choose one opportunity to target
Compare the leaves against the outcome and pick the one worth attacking first. Consider how many customers it affects, how badly, and how plausibly solving it moves your outcome.
Committing to one target opportunity is what keeps the next steps finite. Trying to solve the whole space at once produces a long list of shallow ideas.
- 06
Generate at least three solutions
For the target opportunity, come up with several distinct ways to address it. Three is the usual minimum, because with fewer there is no comparison and the team ends up justifying whatever it already planned.
Deliberately include one option that is cheaper than your favourite and one that is more ambitious. The spread is what makes the comparison informative.
- 07
Find the riskiest assumption and test it
List the assumptions each solution depends on across desirability, viability, feasibility, usability and ethics. Find the one that would sink the solution fastest and has the least evidence behind it, then design the cheapest experiment that would tell you.
Decide the pass threshold before running the test. An experiment without a pre-agreed bar tends to confirm whatever the team was hoping for.
When you get stuck
Three situations account for most stalled trees, and each has a fairly mechanical way out.
- Everything looks equally important. You are probably comparing opportunities at different levels of abstraction. Break the broad ones down until the siblings are the same size.
- The opportunity layer keeps filling with features. For each entry, ask what problem it solves, and replace it with the answer. You will usually find two or three of your features collapse into one opportunity.
- Nobody can agree which solution is best. That is a signal to stop arguing and test. Identify the assumption the disagreement actually rests on and find evidence for it.
Keeping it alive afterwards
The build is the easy part. What separates a working tree from a poster is what happens in the following weeks: new interview evidence gets attached to the opportunity it supports, experiments record their results, and dropped branches stay visible with the reason they were dropped.
Frequently asked questions
How long does it take to build an Opportunity Solution Tree?
A first usable version typically takes a few hours with the product trio in a room, assuming you already have customer input to work from. The tree is never finished though: it gets updated as new evidence arrives, which is the point of the format.
What if we have no customer research yet?
Build the tree anyway, mark every opportunity as unevidenced, and use the gaps as your interview agenda. A tree full of assumptions is honest and useful as long as everyone knows that is what it is. The danger is a tree that looks evidenced but is not.
Who should be in the room?
The product trio: a product manager, a designer and an engineer. Each surfaces a different class of risk, and building the tree together means feasibility and usability concerns appear while ideas are still cheap to change.
How often should the tree be updated?
Whenever new evidence arrives, which in a team practising continuous discovery means roughly weekly. Treat it like code rather than a document: small, frequent changes rather than a quarterly rewrite.
Build yours in TreeFlow
The free plan covers a full first tree. Layout is automatic, so you can spend the session thinking instead of arranging boxes.