Opportunity solution tree: how to build one, with an example

An opportunity solution tree is a visual map, created by product coach Teresa Torres, that connects a single desired outcome at the top to the customer opportunities (needs, pains and desires) beneath it, then to candidate solutions, then to experiments that test them. It keeps every idea tied to a real customer need and a measurable goal.

Most teams jump straight from "we should build X" to a roadmap of features. The opportunity solution tree slows that reflex down. It forces you to name the outcome you are chasing, lay out the customer problems that could move it, and only then start generating ideas. This article walks through what the tree is, who made it, its four parts, how to build one, and why it beats a plain feature list.

What is an opportunity solution tree?

An opportunity solution tree is a diagram that structures product discovery. Read top to bottom, it starts with one outcome (a metric you want to move), branches into the opportunities that could influence that outcome, branches again into solutions that address each opportunity, and ends in experiments that check whether a solution actually works.

The tree does two useful things at once. First, it makes the whole space of options visible, so you can compare opportunities against each other before you commit to any one path. Second, it enforces a chain of logic: every experiment traces back to a solution, every solution back to an opportunity, and every opportunity back to the outcome. If a proposed feature does not connect to a real customer need that plausibly moves your metric, the tree exposes that gap immediately.

Who created the opportunity solution tree?

The opportunity solution tree was created by Teresa Torres, a product discovery coach and the author of "Continuous Discovery Habits." She developed it as a practical tool for teams practicing continuous discovery, meaning they interview customers regularly rather than in occasional bursts, and use what they learn to steer their next decisions.

Torres designed the tree to sit at the intersection of research and delivery. The opportunities on it come directly from customer conversations, and the solutions and experiments feed straight into what the team builds and tests next. It is less a one-off deliverable and more a living artifact the team updates as they keep learning.

What are the four parts of an opportunity solution tree?

The tree has four levels, stacked from top to bottom. At the top sits a single outcome, a measurable result you want to achieve, such as increasing activation or reducing churn. Below it are opportunities, the customer needs, pain points and desires you have surfaced through interviews and research. Each opportunity is a distinct problem worth solving, phrased in the customer's terms rather than as a feature.

Under each opportunity sit solutions, the ideas you believe could address that specific need. One opportunity usually spawns several competing solutions, which is the point: you want options, not a single guess. At the bottom are experiments, the small tests you run to learn whether a solution will actually deliver the opportunity and, in turn, the outcome. Prototypes, fake door tests and quick usability sessions all live here.

How do you build an opportunity solution tree?

Start at the top with one outcome, and be strict about picking just one. If you list three outcomes, you really have three trees, and the focus that makes the tool work evaporates. Choose a metric your team can actually influence within a quarter or two, and write it so anyone can tell whether it moved.

Next, populate the opportunity layer from research, not from a whiteboard brainstorm about the business. Go through your interview notes and pull out the needs, frustrations and desires customers actually voiced. Group and phrase them as opportunities, then arrange them so related ones cluster and broad ones sit above narrower ones. Resist the urge to solve anything yet; this layer is about mapping the problem space honestly.

Once you have a clear set of opportunities, choose one to target and start branching into solutions. This is where you want breadth. Rather than defending your first idea, deliberately generate a wide set of solutions so you have real alternatives to weigh. From there, compare them and pick where to invest. That compare-and-choose step is essentially idea prioritization: you are scoring candidate solutions against how well they serve the opportunity and how much effort they take, then betting on the strongest one. Define clear idea evaluation criteria up front so the comparison is honest rather than a popularity contest. Finally, design a small experiment under your chosen solution to test the riskiest assumption before you commit to building the whole thing.

What is the difference between an opportunity and a solution?

An opportunity is a problem; a solution is a proposed answer to it. Opportunities are stated from the customer's point of view and describe an unmet need, a recurring frustration or a desire: "I never remember to come back" is an opportunity. Solutions are things your team could build or change: "send a reminder email" or "add a home-screen widget" are solutions to that same opportunity.

The distinction matters because it is easy to smuggle a solution into the problem layer without noticing. "We need a notifications feature" sounds like a need, but it is already an answer, and it quietly rules out every other way of solving the underlying problem. Keeping opportunities solution-free preserves your options. A single well-framed opportunity should be able to hold several rival solutions underneath it, and that competition is exactly what produces better bets.

Why use an opportunity solution tree instead of a feature list?

A feature list is a pile of answers with the questions removed. It tells you what someone decided to build but not which customer problem each item solves, whether that problem matters, or how it connects to the outcome you are accountable for. When priorities get questioned, a list gives you nothing to reason with, so the loudest voice or the newest request usually wins.

The tree fixes this by preserving the reasoning. Because every solution hangs off an opportunity and every opportunity off the outcome, you can trace any proposed feature back to the need it serves and the metric it should move. That traceability makes it far easier to say no to work that does not connect, and far easier to explain your choices when you pitch it to stakeholders. It also encourages a diverge-then-converge rhythm: explore many opportunities and many solutions first, then narrow with intent, instead of locking in the first idea that gets airtime.

One honest caveat lives at the very top of the tree. The outcome is only useful if you can see it change. Pick a metric, then make sure you are actually tracking it. If your signals are scattered across an ad platform, a store dashboard and an analytics tab, you will argue about whether anything moved instead of knowing. You only learn that the outcome shifted if you are watching it, ideally with every channel on one dashboard rather than five browser tabs and a spreadsheet stitched together on Friday afternoons.

The short version

The opportunity solution tree, created by Teresa Torres, is a four-level map that connects one measurable outcome to the customer opportunities that could move it, then to candidate solutions, then to experiments that test them. It replaces a disconnected feature list with a visible chain of reasoning, keeps every idea tied to a real customer need, and pushes teams to explore widely before they compare options and commit to the strongest bet.