What is an Opportunity Solution Tree?

An opportunity solution tree (OST) is a branching diagram with four layers. At the root sits the outcome: a measurable change in customer behavior the team is responsible for (increase weekly active use of a feature, reduce time to first value). Beneath it hang the opportunities: the customer needs, pains, and desires, discovered in research, that if addressed might move the outcome, organized in a hierarchy from broad to specific. Under chosen opportunities hang solutions: the ideas, several per opportunity, that might address it. And under solutions hang assumption tests: the small experiments that check whether a solution's riskiest assumptions hold. The structure was developed by Teresa Torres as the organizing artifact of continuous discovery, and its purpose is to make the team's reasoning visible: this is what we're trying to achieve, this is what we've learned customers need, this is why we're testing this idea.

Why the Structure Matters

It separates problems from solutions. Most product debates are solution debates ("should we build X?"); the tree forces the prior question ("which customer need is X for, and is that the need that matters most?"). Solutions compete within an opportunity; opportunities compete for the outcome.

It makes the opportunity space visible. A team that sees twelve opportunities under its outcome makes a different decision from one that sees only the one a stakeholder brought to the meeting. The tree is a defense against the loudest idea.

It grounds decisions in research. Opportunities enter the tree from customer interviews and observation, phrased in customers' words; a tree without research beneath it is an org chart of opinions.

It shows the reasoning to stakeholders. The path from outcome to opportunity to solution to test is an argument anyone can inspect, which changes roadmap conversations from "why this?" to "which branch?".

Building One

1. Start with one outcome.
A behavioral metric the team can influence, not a business result three steps removed; the outcome frames every branch below it.

2. Harvest opportunities from interview stories.
Story-based interviews ("tell me about the last time you...") produce needs and frustrations in context; each becomes a node, stated as the customer would state it ("I can't tell whether my export finished"), never as a solution in disguise ("users want a progress bar").

3. Structure the opportunities.
Group specific pains under broader needs, prune duplicates, and keep the tree to the opportunities that plausibly move the outcome. The structure emerges over weeks of interviews, not from one workshop.

4. Pick a target opportunity by comparison.
Size (how many customers, how often), impact on the outcome, ease of addressing, and strategic fit, assessed with evidence where it exists: usage data for size, a MaxDiff or survey for importance across the audience.

5. Generate several solutions, then test assumptions.
Three or more ideas per target opportunity, compared rather than defended; for each, name the riskiest assumptions and run the cheapest test that could falsify them (a prototype test, a concept check with a handful of screened users, a data query). The tree records what was tested and what was learned.

Common Mistakes

Solutions written as opportunities. Trees built from stakeholder requests rather than customer stories. Committing to one solution per opportunity, which skips the comparison that makes the structure valuable. Trees drawn once and never revisited, when the whole point is a living map that grows with each week's discovery. And outcomes set as outputs ("ship the new dashboard"), which turn the tree into a project plan.

In Short

An opportunity solution tree maps outcome to opportunities to solutions to assumption tests, so that a team sees the space of customer needs before choosing which to serve and compares solutions before building any. Root it in one behavioral outcome, grow the opportunities from interview stories in customers' words, choose by comparison and evidence, generate several solutions, and test the assumptions. It turns "what should we build?" into "which need, why, and how do we know?"