Most opportunity solution trees fail at the second layer, not the fourth. Teams get the outcome roughly right at the top, and they are happy to run experiments at the bottom, but the row in between (the opportunities) ends up full of features wearing a disguise. “Customers want a dashboard” is not an opportunity. It is a solution someone has already fallen for.
Teresa Torres introduced the opportunity solution tree in 2016 and built her book Continuous Discovery Habits around it in 2021. Her current guide on Product Talk is far more specific than most summaries of it, and the specifics are where the value is. This piece walks through the structure, builds a small tree from scratch, and then covers the mistakes that make a tree look busy while it tells you nothing. It ends with the newest wrinkle: AI tools that now draft the tree for you.
The four layers, and what each one is for
An opportunity solution tree has four levels, read from top to bottom:
- Outcome. One metric the team is trying to move. Torres recommends a product outcome (something the team can directly influence, like “percentage of new accounts that send a second invoice”) rather than a business outcome like revenue, which a single team can only nudge indirectly.
- Opportunities. Unmet customer needs, pain points and desires that, if addressed, would drive the outcome. Torres deliberately avoids the word “problem” because products also serve desires that nobody would call a problem.
- Solutions. Ideas for addressing one specific opportunity.
- Assumption tests. Small, fast checks on the riskiest beliefs behind each solution.
The tree’s job is to make the reasoning visible. When someone asks “why are we building this?”, you should be able to trace a line from the solution, up through the opportunity it serves, to the outcome that opportunity drives. If the line breaks anywhere, you have found the weak spot in your plan before you paid to build it.
Torres also lists prerequisites that most tutorials skip: a working theory of who the customer is, a clear outcome, and three or four story-based customer interviews. Without those, you are not mapping an opportunity space; you are inventing one in a conference room.
A test for spotting solutions in disguise
The single most useful check in the whole method is one question Torres asks of every opportunity: is there more than one way to address this?
Her own example is dinner. “I’m hungry” and “I don’t have time to cook” are opportunities; you could order takeout, go to a restaurant or subscribe to a meal kit. “I want to go out to eat” fails the test, because it already names the answer. Reframed, it might become “I want to eat right now” or “I don’t want to do dishes tonight,” and suddenly several solutions are back on the table.
Run that test against your own backlog and the results are usually uncomfortable. “Users need bulk export” has one answer. “I have to reconcile this data in a spreadsheet every month” has a dozen.
Building one: a small worked example
Here is a hypothetical tree for a B2B invoicing product, kept small on purpose. Real trees get wider, but the shape is the same.
Outcome: increase the share of invoices paid within 30 days.
After four interviews with small business owners, each one telling the story of the last invoice that got paid late, the team maps the moments in that experience. Three top-level opportunities stand out:
- “I don’t know an invoice is overdue until I check my bank account.”
- “Checking is tedious, so I only do it once a month.”
- “I can’t tell which clients usually pay late.”
- “Chasing a client for money feels awkward.”
- “I don’t want a reminder to sound rude to a long-term client.”
- “My client’s accounts payable team loses the invoice.”
- “The invoice goes to my contact, not to the person who actually pays.”
Notice the nesting. Broad opportunities sit higher; the more specific versions sit beneath them. Torres recommends building this structure from an experience map: plot the moments in the customer’s journey, turn each moment into a top-level opportunity, then group the specific needs underneath and work through one branch at a time.
Choosing a target. Rather than spreading effort across all three, the team assesses them on four factors Torres names: opportunity sizing (how many customers, how often), market factors, company factors (does this fit our strategy) and customer factors (how much do customers care). She explicitly leaves effort out at this stage, because judging an opportunity by how hard it looks to solve kills good bets before anyone has generated a single idea.
Say the team targets “the invoice goes to the wrong person.” Only now do they brainstorm, and only for that one opportunity:
- Ask for an accounts payable email at invoice creation.
- Let the recipient forward the invoice inside the product, with tracking.
- Detect when an invoice is opened but not paid after seven days, and prompt the sender to confirm the billing contact.
Testing. For the first idea, the riskiest assumption might be “senders know who handles payment at their client’s company.” That can be tested in an afternoon by adding an optional field to the invoice form for a small group of accounts and watching how often it gets filled in. No engineering sprint required.
That is the whole loop: outcome, mapped opportunities, one target, at least three candidate solutions compared against each other, and the cheapest test that could prove you wrong.
Where trees go wrong
Torres’s guide is candid about the failure modes, and they are worth naming because each one produces a tree that looks complete.
Building it without interviews. A tree assembled from stakeholder opinions has the right shape and none of the substance. Torres also warns against treating sales calls, support tickets or analytics as opportunity sources on their own; they lack the story context that tells you why a need exists. Our piece on why customer interview questions produce biased answers covers how to get those stories without leading the witness.
Chasing the latest interview. One vivid conversation can reshape a tree overnight. Torres’s guidance is to update the opportunity space every three or four interviews, which at a weekly cadence means roughly every three or four weeks. That rhythm smooths out the noise.
Several outcomes at once. A team pursuing three metrics builds three half-trees and makes progress on none. One team, one outcome. If a group is too large for that, split by customer segment or by step in the journey.
Brainstorming across the whole tree. Generating solutions for every opportunity at once produces a long list of features and no decision. Solutions belong under the one opportunity you have chosen to target.
One tree for the whole company. Torres is specific here: company-wide alignment is the job of a KPI tree or a shared experience map. Each team’s opportunity solution tree should hang off its own outcome.
Starting over too often. A new tree is warranted when the direction of the outcome changes, not when the target number does. Moving a goal from 22% to 25% is the same tree.
Letting it sprawl. If six to eight interviews in, the opportunity space is a tangle nobody can read, that is the signal to stop adding and start restructuring.
Why the tree works in operations, too
I spent more than two decades in IT operations at a large telecom, and nobody there called anything an “opportunity solution tree.” But the pattern the tree guards against was everywhere. Internal tooling requests almost always arrived as solutions: a new report, another dashboard, one more field on a form. They got funded as solutions and shipped as solutions, and the question of what was actually slowing the people doing the work often got asked after launch, if at all. The tools that earned their keep were the ones where somebody had sat with the users first.
That is the reason I push the product teams I coach toward this framework. The middle layer is a discipline, not a diagram. Writing a need in the customer’s own words, and refusing to let a solution sit in that row, is what forces the conversation that should have happened before the money was spent.
Who should be in the room
Torres designed the tree for a product trio: typically a product manager, a designer and an engineer who share responsibility for a single outcome and interview customers together. The older version of this article described the trio as including an “architect.” That was wrong; the third seat is usually an engineer, and Torres is clear that the model flexes by company and does not shut anyone else out.
The trio matters because the tree is a shared artifact. If the PM builds it alone and presents it, the designer and engineer inherit conclusions rather than the reasoning, and you lose the main benefit. Torres suggests matching how much of the tree you show to how close someone is to the work: the full tree for the trio and their manager, the highlights for everyone else.
AI can now draft the tree. Read the fine print.
The biggest change since this framework went mainstream is that software now builds first drafts. Torres herself designs the AI behind Vistaly’s interview snapshots and generated trees: the system summarizes each interview into key moments and opportunities, then drafts a tree across interviews and proposes updates as new ones arrive. Product Talk’s page is explicit that the outputs are drafts and the team keeps responsibility for synthesis and decisions.
An October 2026 Product Talk episode with the Vistaly team is unusually frank about where generated trees break. The central risk is a “house of cards” cascade: a weak interview snapshot or a badly framed opportunity corrupts every layer above it. Beta users also uploaded sales demos, stakeholder meetings and even AI-generated fake transcripts as “interviews,” which is the same garbage-in problem Torres warns about in the manual method, now running at machine speed. And one customer’s complaint, “I’ll have to come back and clean up this branch,” sums up the reality that the output still needs a human to repair it.
The practical takeaway is that AI moves the bottleneck rather than removing it. Synthesis gets faster; judgment about which opportunities are real, and which are solutions in disguise, still sits with the trio. If you are tempted to skip the interviews entirely and feed the tree simulated customers, our look at synthetic users in product discovery explains why they tend to agree with everything you propose.
Going further
If the framework is new to you, the fastest route in is Torres’s 2022 conversation on Lenny’s Podcast, where she builds an example tree for Netflix out loud. From there, the habits that keep interviewing weekly matter more than any diagramming tool, and assumption mapping is a natural partner for the bottom layer of the tree, where you decide which belief to test first.
Start small. One outcome, four interviews, one target opportunity, three solutions. A tree with eight nodes that the whole trio believes is worth more than a wall of sticky notes nobody can explain.