Opportunity Solution Trees

Starting with solutions is a trap. An Opportunity Solution Tree starts with the outcome and works backward through opportunities to find solutions worth testing.

Overview

Teresa Torres’ Opportunity Solution Tree is a map of your thinking, drawn top to bottom in four levels. At the root sits a single outcome — a measurable change in customer or business behavior, not a feature you have already decided to ship. Beneath it branch the opportunities: the needs, pains, and desires that, if addressed, would move that outcome. Under each opportunity hang the solutions you might build. And under each solution sit the experiments that tell you whether it works before you commit to building it.

The order matters, because it forces you to earn your way down. The outcome comes from framing — without a clear frame at the top, the tree collapses into a backlog of features in search of a problem. If all you hold is committed scope, reverse-engineer the root instead: the So What Stack climbs from a feature to the outcome it was standing in for, and From Feature to Outcome to Bets chains the two tools end to end. Opportunities are mined from customer interviews and phrased as the customer’s problem (“I can’t tell which plan fits me”), not your fix (“add a pricing comparison”). Only once an opportunity is on the tree do you generate solutions — several per opportunity, so you compare options instead of marrying the first idea. Experiments come last, one or more per solution, each sized to produce a signal cheaply. This is the outcomes over outputs mindset made visible.

A worked tree

Say the outcome is lift trial-to-paid conversion from 12% to 20%. Talk to enough trial users and three opportunities surface: they never discover the features that would hook them, the 14-day window is too short for an enterprise buying cycle, and the pricing page confuses more than it clarifies. Each earns its own branch. Under “users don’t discover key features” you might list a guided onboarding checklist and in-app prompts triggered by usage — two solutions, not one. The checklist gets an experiment: A/B it against the current blank-slate onboarding and watch feature-activation rate in the first three days. The prompts get a five-user prototype to test timing before you build any trigger logic. Now the path from outcome to experiment is legible on a single page, and anyone can argue with it.

That legibility is why we reach for the tree constantly. It separates the problem space from the solution space, so a team debates where to play before how — and it turns prioritization into an argument about evidence instead of volume. Generate broadly at the solution level, prune ruthlessly at the experiment level, and the tree becomes a record of what you chose not to build and why.

Here is that trial-to-paid tree drawn out. Read it top to bottom: one outcome, the three opportunities that surfaced from talking to users, the solutions hanging off each, and the experiment that would test each solution before you build it. Collapse a branch to focus; the whole thing fits on one page precisely because it earns its way down. Hit Explore to open the same scenario in the full builder and start editing — rename nodes, add branches, cut dead weight.

Traps

• Solution-first trees. If the branches are features you already agreed to ship, you have drawn an org chart of your backlog, not an opportunity tree. Start from the outcome or don’t start.
• Opportunities that are solutions in disguise. “We need a tutorial” is a solution wearing an opportunity’s coat. The opportunity is “users can’t find key features.” Keep the problem-space language honest, or you smuggle the answer in before you have asked the question.
• Orphan branches. A solution with no line back to an opportunity, or an experiment that would not change a decision, is dead weight. Every node should trace to the outcome; cut the ones that don’t.

Finish the tree

The Faster Developer Onboarding preset is deliberately unfinished — it has solutions but no experiments yet. Load it and design the missing experiments: for “one-command dev environment setup,” what is the cheapest test that would tell you it actually cuts setup time? A tree without experiments is just a wishlist with branches.

Once a solution survives its experiments, it stops being a hypothesis and becomes work to sequence — and that is where User Story Mapping takes over, turning a validated solution into a delivery plan sliced into releases. The developer-onboarding scenario lives in both tools on purpose: the same problem you explore here becomes a story map you can walk end to end.

Resources

• Teresa Torres, “Continuous Discovery Habits” (Product Talk LLC, 2021)
• Continuous Discovery Habits — the operating manual behind the tree
• Customer Interviews — where opportunities come from
• So What Stack — reverse-engineer a root outcome from scope you already own
• From Feature to Outcome to Bets — the pattern that chains the stack into this tree
• User Story Mapping — turn a validated solution into a sliced delivery plan