Opportunity Solution Trees

---

Origins

Opportunity Solution Trees were developed by Teresa Torres and detailed in Continuous Discovery Habits¹. Torres built the framework to address a specific gap in how product teams talked about their work: most teams could explain what they were building, some could explain what outcome they were after, but very few could trace the path from outcome to feature in a way that made the alternatives visible.

The Opportunity Solution Tree (OST) makes the path explicit. Outcomes branch into opportunities, opportunities branch into solutions, solutions branch into experiments. At every branching point, the team's choice is visible — what was picked, and what was set aside. The tree becomes a working artifact for product strategy at the team level.

The Four Layers

1. The Outcome (root)

A single measurable outcome the team is responsible for over some horizon — activation rate, retention, conversion, customer satisfaction. Outcomes are business-relevant and measurable. The whole tree is in service of moving this number.

2. Opportunities (branches from the outcome)

Customer needs, pain points, or desires that, if addressed, could move the outcome. Opportunities are customer-side, not solution-side. "New users abandon during onboarding" is an opportunity; "build a better tutorial" is not.

Opportunities come from research — customer interviews, support tickets, usage data, observation. A team that fills its opportunity layer purely from internal opinion is producing a wishlist, not a tree.

3. Solutions (branches from opportunities)

Specific things the team could build or change to address an opportunity. Each opportunity typically branches into multiple solution candidates. "Build a better tutorial" might branch alongside "redesign the empty state," "add tooltips," and "pre-populate sample data."

The point of multiple solutions per opportunity is to force the team to think beyond the first idea. The first solution that comes to mind is rarely the best one.

4. Experiments (branches from solutions)

Tests of the solution before committing to building it. Customer interviews, prototypes, A/B tests, fake doors. Each experiment has a hypothesis and a decision rule. Solutions that pass experiments graduate toward implementation; those that don't get killed or revised.

The Discipline the Tree Imposes

The OST's structural value is that it makes several disciplines visible:

• Outcome accountability: every branch traces back to the outcome the team owns. Solutions disconnected from the outcome are visible as such.
• Research grounding: opportunities must come from customer evidence. An opportunity layer filled with internal opinion is a visible problem.
• Multiple solutions per opportunity: the team can't claim to have considered alternatives if the tree only shows one branch under each opportunity.
• Experiments before commitment: solutions don't graduate to delivery without validation. The tree shows whether validation actually happened.
• Visible trade-offs: the branches the team didn't pursue are still on the tree. Stakeholders can ask "why this branch and not that one?" with the alternatives in plain view.

Building a Tree

An OST is built and maintained over time, not in a single workshop:

1. Agree on the outcome: one measurable outcome the team is accountable for. Specific, time-bounded.
2. Gather customer research: interviews, observations, ticket reviews. Note recurring needs, frustrations, requests.
3. Cluster into opportunities: similar customer evidence becomes a named opportunity. Each opportunity should be specific enough to act on.
4. Brainstorm solutions per opportunity: multiple candidates each. Resist the first-idea trap.
5. Pick the priority branch: which opportunity is most leveraged for the outcome? Which solution under it is most promising?
6. Design experiments: tests that would tell the team whether the solution is worth building.
7. Run, learn, prune, regrow: as experiments succeed or fail, the tree shifts. Solutions die; new opportunities surface; the tree evolves.

What the Tree Reveals (and What It Doesn't)

• Reveals: whether the team is grounded in real customer needs, whether solutions are considered against alternatives, whether validation happens before commitment.
• Doesn't reveal: which solution will actually work. The tree organizes thinking; the experiments produce evidence.

An OST is a thinking tool, not a recommendation engine. It helps the team make better decisions; it doesn't make decisions for them.

Common Pitfalls

• Opinion-layered opportunities: the opportunity layer comes from team brainstorming rather than customer research. The tree looks complete but rests on guesswork.
• One solution per opportunity: the team picks the first idea and moves on. The OST's structural advantage — making alternatives visible — is lost.
• Solutions promoted without experiments: tree branches go from solution to delivery without the experiment layer being run. Validation disappears.
• Static tree: built once, never updated. Trees that don't evolve with research and experiment results stop being useful within weeks.
• Too many outcomes: trying to map five outcomes simultaneously dilutes focus. One outcome per tree; multiple trees if the team has multiple outcomes.
• Solo tree-building: one person (usually the PM) builds the tree alone. The collaborative thinking the format produces is lost.

Coaching Tips

Ground Opportunities in Research

If the opportunities came from team brainstorming, push back. The opportunity layer needs customer evidence to mean anything.

Force Multiple Solutions

Each opportunity should branch into at least three solution candidates. Otherwise the team is just picking the first idea and rationalizing it.

Gate on Experiments

Solutions should not graduate to delivery without passing experiments. If the team is skipping that layer, the tree's discipline is lost.

One Outcome per Tree

Multiple outcomes produce muddled trees. If the team owns several outcomes, build several trees rather than one bloated map.

Update Weekly

The tree should change as research and experiments produce evidence. A tree that hasn't moved in a month is decoration.

Build It With the Team

The PM building the tree alone misses the collaborative thinking the format is designed to produce. Make it a team artifact.

Summary

Opportunity Solution Trees are one of the more practical product strategy tools in current use. They give a team a way to talk about its work in terms of the outcome it owns, the customer needs that connect to that outcome, the alternatives it considered, and the experiments it ran before committing. None of that is unique to OSTs — teams could do all of it without the format — but most teams don't, and the structure of the tree is what makes the discipline visible.

The tree fails when it becomes a deliverable rather than a working tool. Built once, presented to leadership, never updated, it's a fancier kind of slide deck. Built and maintained over time, with real customer research feeding it and real experiment results shaping it, it becomes the team's strategic memory and the most-referenced artifact in their product practice.

Back to Experience & Story Mapping