Opportunity Solution Trees: Structure Your Discovery

An opportunity solution tree is a visual map, from Teresa Torres's Continuous Discovery Habits, with four layers: a single desired outcome at the top, customer opportunities beneath it, candidate solutions under each opportunity, and assumption tests at the leaves. It keeps discovery anchored to an outcome instead of a feature backlog.

Quick Answer: An opportunity solution tree (OST) connects one desired outcome to the customer needs, pains, and desires that could move it — the "opportunities" — then branches into solutions and small assumption tests. You source opportunities from interview stories and compare options across the tree, so you commit to a direction with evidence instead of committing to a feature too early.

If you came up through product management before founding your own company, you have felt the specific ache the tree is designed to cure. Your backlog fills with feature ideas from every direction — sales, investors, your own 2 a.m. brainstorms — and nothing tells you which one matters. The opportunity solution tree replaces that flat list with a structure that shows how each idea ladders up to an outcome and back down to a test. This guide walks through building one, layer by layer, and keeping it useful week after week.

Why a Tree Beats a Flat List of Ideas

A tree beats a flat list because it makes your reasoning visible and forces every idea to justify its place. A backlog is a pile; a tree is an argument. When ideas live in rows on a board, you can only ever ask "which do we build first?" When they live on a tree, you can ask the far better question: "which customer need are we serving, and is this the best way to serve it?"

Torres's core claim is that most teams jump straight from a business goal to a solution, skipping the space in between. That leap feels efficient and is usually where products go wrong. You fall in love with one idea, build it, and only afterward discover it addressed a need almost nobody had.

The tree slows that leap down on purpose. By insisting you map the opportunity space — the full set of unmet needs, pains, and desires — before you attach solutions, it keeps you from over-committing to the first idea that excited you.

There is a second, quieter benefit. A tree externalizes thinking that usually stays locked in one founder's head. When your co-founder, your first engineer, or an advisor can see the whole structure, disagreements become concrete: they point at a branch instead of arguing about vibes. Prioritization stops being a contest of who talks loudest.

The table below contrasts the two ways of organizing discovery. It is qualitative by design — the point is how each shape changes your behavior, not a benchmark.

The takeaway: the tree is not a prettier backlog. It is a thinking tool that changes which questions you can ask, and it earns its keep the moment two people need to agree on what to work on next.

The Desired Outcome at the Root

Every tree starts with exactly one desired outcome at the top — a measurable change in customer behavior that, if it moved, would signal your product is creating value. Not a feature. Not revenue directly. A behavior you can influence and observe.

Torres distinguishes between three kinds of goals, and the distinction matters for where you plant your root. Business outcomes measure how well the business is doing — revenue, retention, margin. Product outcomes measure how well the product moves the business — activation rate, weekly active use, tasks completed. Traction metrics measure usage of a specific feature. The healthiest tree hangs from a product outcome, because that is the level a discovery team can actually influence week to week.

Why not the business outcome? Because "grow revenue" is too far from any single conversation you could have with a customer. A dozen forces move revenue, most outside your control. A product outcome like "increase the number of users who complete their first project" is close enough to customer behavior that an interview can plausibly inform it.

For a founder, choosing the outcome is often the hardest part of the whole exercise. You are tempted to list five. Resist it. One tree, one outcome. If you genuinely have two outcomes, build two trees — the discipline of a single root is what keeps the branches comparable.

A quick test for a well-formed outcome: could you draw a straight line from a customer's changed behavior up to it? "Users invite a teammate within their first week" passes. "Become the market leader" does not — there is no single behavior underneath it. Get this right and the rest of the tree almost builds itself; get it wrong and every branch inherits the confusion.

Mapping the Opportunity Space

The second layer is opportunities: customer needs, pains, and desires — framed as needs, never as solutions. This is the heart of the tree and the layer founders most often get wrong, because it is genuinely counterintuitive to describe what you learned without immediately proposing a fix.

An opportunity is something the customer wants that they do not have, expressed in their words. "I never know if my invoice actually got sent" is an opportunity. "Add a delivery-confirmation toast" is a solution wearing an opportunity's clothes. The moment you write the solution into the need, you have quietly closed off every other way of serving it.

Where opportunities come from

Opportunities come from interview stories, not from opinions or feature requests. This is the connective tissue between your weekly conversations and your tree. When you interview a customer about a specific recent experience — not their preferences in the abstract, but what actually happened last Tuesday — you collect stories. Inside those stories are moments of friction, workaround, and unmet desire. Those moments become opportunities.

Torres is firm that opinions make weak opportunities. "I'd love a dark mode" is a stated preference; it may evaporate the moment you build it. "I stopped using the app at night because the screen was blinding and I woke up my partner" is a story, and the opportunity buried in it — usable in low light without disturbing others — is far more trustworthy. Our walkthrough of building an opportunity solution tree from real interviews shows this extraction step end to end, moment by moment.

Structuring the opportunity space

Once you have a handful of opportunities, you organize them into a hierarchy — parent opportunities branching into more specific child opportunities. A broad need like "I struggle to get my team to adopt the tool" might branch into "I can't tell who has and hasn't logged in" and "new teammates don't know where to start." The parent frames the theme; the children are specific enough to solve.

Good structure follows a few rules:

• Frame every node as a need, pain, or desire — if it contains a verb like "add," "build," or "integrate," it belongs one layer down.
• Use the customer's language, not your product vocabulary, so the need survives independent of any solution.
• Make siblings mutually exclusive where you can, so choosing between branches is a real choice, not a false one.
• Keep children more specific than parents, narrowing as you descend until a node is small enough to attach solutions to.

Getting the parent-child relationships right is a skill of its own, and it is worth the effort — a well-structured space makes prioritization obvious. Our guide to structuring parent and child opportunities goes deeper on the sizing and mutual-exclusivity questions that trip most founders up here.

The reward for doing this well: you can now prioritize needs against each other before you have spent a single hour designing anything. You compare opportunities on how many customers they touch, how much pain they carry, and how well they fit your outcome — and you pick a branch to go deep on.

Attaching Candidate Solutions

The third layer is solutions, and the key rule is that you generate several per opportunity — not one. Only after you have chosen a target opportunity do you let yourself think about how to solve it, and even then the discipline is to produce options, not a single answer.

This ordering is the whole point. By deferring solutions until an opportunity is selected, the tree protects you from the most expensive mistake in product: falling in love with a solution and then reverse-engineering a justification for it. Here, the need comes first and earns the right to a solution — several of them.

Torres recommends generating solutions in volume before evaluating any of them. Aim for at least three genuinely distinct approaches to the target opportunity. If your first instinct was a settings toggle, force yourself past it: a smart default, an onboarding nudge, a redesign of the underlying flow. Quantity here is a feature, because the best solution is rarely the first one you think of, and a tree with a single solution under each opportunity has quietly smuggled the flat-list problem back in.

Attach each candidate as a child of its opportunity. Now the tree does something a backlog never could: it lets you compare solutions within the same need, on equal footing, all serving the same customer desire. You are no longer asking "feature A or feature B?" across unrelated goals. You are asking "given that this customer can't tell whether their invoice sent, which of these four approaches serves that best?"

Comparing across the tree also applies upward. A solution that looks strong in isolation may sit under a weak opportunity — one that touches few customers or barely moves your outcome. The structure lets you catch that. Sometimes the right move after generating solutions is to abandon the branch entirely and go deep on a different opportunity, and the tree makes that trade-off legible instead of invisible.

Resist the urge to build yet. A solution on the tree is a candidate, not a commitment. What turns a candidate into a decision is the layer beneath it.

Running Assumption Tests at the Leaves

The fourth and bottom layer is assumption tests — small experiments that probe the riskiest beliefs holding up a solution before you build it. This is where the tree touches the ground and where discovery either earns its keep or doesn't.

Every solution rests on a stack of assumptions. Torres groups them into categories worth checking deliberately: desirability (do customers want this?), viability (does it work for the business?), feasibility (can we build it?), usability (can they figure it out?), and ethical (could it cause harm?). A single promising solution might carry a dozen assumptions across these buckets.

You cannot test all of them, and you should not try. The move is to identify the assumptions that are both most important and most uncertain — the ones where, if you are wrong, the whole solution collapses. Those are your leaves. Everything else can wait.

An assumption test is deliberately small. It is not a beta launch or a full build. It is the lightest activity that would generate evidence for or against one belief — a fake-door click test, a concierge run where you deliver the outcome manually, a one-question survey, a prototype walkthrough. The goal is a signal, fast and cheap, not proof beyond doubt.

The table below sketches how a single solution decomposes into testable assumptions. The assumptions and tests are illustrative, meant to show the shape of the reasoning rather than represent findings from any real study.

The takeaway: the leaves are where opinions go to get tested. A solution that survives contact with its riskiest assumption is worth building; one that doesn't just saved you a quarter. For a deeper treatment of how the whole structure fits together, our overview of opportunity solution trees in continuous discovery situates assumption testing inside the wider practice.

Keeping the Tree Alive Week to Week

An opportunity solution tree is a living document, not a deliverable you finish and file. Its value comes from being updated continuously as new interview stories arrive, and a tree that hasn't changed in a month is a warning sign, not a milestone.

The rhythm looks like this. Each week you talk to customers, collect stories, and mine them for opportunities. New opportunities get added to the space; existing ones get reinforced or reframed. As a target opportunity comes into focus, you generate solutions; as a solution firms up, you spin off assumption tests. The tree grows and prunes in the same motion, week over week.

This is why the tree lives at the center of Teresa Torres's broader continuous discovery practice rather than standing alone. It is the artifact that connects your weekly conversations to your roadmap decisions. Without it, interviews produce a pile of notes nobody revisits; with it, every conversation has a home and every decision has a visible lineage back to a customer need.

For a solo founder or a two-person team, keeping the tree alive is lighter than it sounds. You do not need special software — a whiteboard, a sticky-note wall, or a simple diagram works. What matters is the ritual: after each batch of interviews, spend twenty minutes updating the tree before the stories go cold.

A few habits keep it healthy:

• Update after every interview batch, not once a quarter, so the tree reflects what you actually know now.
• Prune ruthlessly — kill branches for opportunities that turned out to be rare or solutions that failed their tests.
• Keep exactly one outcome at the root; if a second outcome creeps in, start a second tree.
• Let the tree drive your standup, so the next experiment is always visible and agreed on.

When the tree is alive, prioritization stops being a recurring argument and becomes a glance. You look at the structure, see which opportunity is most promising and which assumption is most dangerous, and you know what to do next.

Common Opportunity Solution Tree Mistakes

Most OST failures trace back to collapsing one of the four layers into another. The structure only works when each layer stays distinct, and the mistakes below are the ways founders quietly break that separation.

The most common error is writing solutions as opportunities. "Add a Slack integration" feels like a customer need but is actually a fix in disguise. The tell is a verb — build, add, integrate, automate. Rewrite it as the need it serves ("I lose track of updates because they're scattered across tools") and suddenly you can see three other ways to solve it.

The second is sourcing opportunities from opinions instead of stories. Feature requests, survey wishlists, and stakeholder pet ideas all masquerade as opportunities. They are weak because they describe what people say they want, not what actually happened to them. Anchor every opportunity in a specific remembered experience or leave it off the tree.

Third: too many outcomes at the root. Founders hedge by listing three or four goals, which makes the branches incomparable and the whole tree mush. Discipline yourself to one. A tree with two outcomes is really two trees pretending to be one.

Fourth: jumping to a single solution and skipping the opportunity space entirely. This is the exact leap the tree was built to prevent, and it is easy to make by accident when you are excited. If your tree has one solution under one opportunity, you have drawn a picture of a decision you already made, not a discovery.

Finally, treating the tree as a static artifact. Built once, presented in a deck, never touched again. A dead tree gives you the comfort of structure without any of the benefit. The whole value is in the weekly revision.

The pattern across all five: respect the layers. Outcome, opportunity, solution, test — each is a different kind of thing, and the tree works precisely because it keeps them apart.

Key Takeaways

• An opportunity solution tree has four layers — one desired outcome at the top, customer opportunities beneath it, candidate solutions under each opportunity, and assumption tests at the leaves — from Teresa Torres's Continuous Discovery Habits.
• Plant one product outcome at the root, a measurable customer behavior you can influence, and build a separate tree for any second outcome rather than crowding the root.
• Frame opportunities as needs, pains, and desires, never as solutions; a node with a verb like "add" or "build" belongs one layer down.
• Source opportunities from interview stories, not opinions or feature requests, because what actually happened is far more trustworthy than what people say they want.
• Generate several solutions per opportunity and compare them within the same need, so you commit late and with evidence instead of falling for the first idea.
• Test the riskiest, most uncertain assumptions behind a solution with small, cheap experiments before you build the full thing.
• Keep the tree alive by updating it after every interview batch and pruning branches that fail — a tree that never changes has stopped doing its job.

Frequently Asked Questions

What is an opportunity solution tree?

An opportunity solution tree is a visual map from Teresa Torres's Continuous Discovery Habits that connects a business goal to daily discovery work. It has four layers: a single desired outcome at the top, customer opportunities (needs, pains, desires) beneath it, candidate solutions under each opportunity, and assumption tests at the leaves. It keeps discovery anchored to an outcome instead of a feature backlog.

What is the difference between an opportunity and a solution?

An opportunity is a customer need, pain, or desire expressed in their words — "I never know if my invoice got sent." A solution is a specific way to serve that need — "add a delivery-confirmation notice." The test is whether the node contains a verb like add or build; if it does, it is a solution. Keeping the two layers separate lets you compare multiple solutions against the same need.

How do I choose the outcome at the top of the tree?

Choose one measurable product outcome — a customer behavior you can influence and observe, like "users complete their first project in week one." Avoid business outcomes like revenue, which are too far from any single conversation, and avoid feature-usage metrics, which are too narrow. A good test: you should be able to draw a straight line from a customer's changed behavior up to the outcome.

Where do opportunities on the tree come from?

Opportunities come from customer interview stories, not opinions or feature requests. When you interview someone about a specific recent experience, you collect moments of friction and unmet desire, and those become opportunities. Torres treats stated preferences ("I'd love dark mode") as weak, because they may vanish once built. A need pulled from something that actually happened is far more trustworthy.

How is an opportunity solution tree different from a backlog?

A backlog is a flat list of features ranked by gut feel; a tree is a structure that ladders every idea up to a customer need and an outcome. The backlog only lets you ask "which feature first?" The tree lets you ask "which need matters, and what's the best way to serve it?" It also makes your reasoning visible so a team can agree on priorities by pointing at a branch.

How often should I update the opportunity solution tree?

Update it after every batch of customer interviews — typically weekly — not once a quarter. The tree is a living document whose value comes from reflecting what you know right now. Add new opportunities from fresh stories, spin off solutions and assumption tests as branches firm up, and prune anything that failed its test. A tree that hasn't changed in a month has stopped doing its job.