Cited from real sources 6 min read Updated September 2026

A product framework by Teresa Torres

Teresa Torres's Opportunity Solution Tree, From Root Outcome to Assumption Test

An Opportunity Solution Tree maps the space between a goal and a build. Teresa Torres puts one outcome at the root. Under it go unmet needs drawn from customer stories. Solutions branch under a need. Assumption tests branch under a solution. The point is to stay in the problem before you pick a fix.

The framework

Four layers, drawn top down

Torres draws the tree the way you would draw a decision tree. One outcome at the root. The opportunity space below it. Solutions below that. Assumption tests below those. Sketching one is simple. Filling it in is the work.

The gap it covers is a real one. A team owns a number to move and has no method for turning that number into work. Torres calls the jump from an outcome to a build list wide open and hard.

That was the purpose of the opportunity solution tree: how do I add some structure to this wide open messy problem?

Torres on why the tree exists Watch at 08:15

Scaffolding is the right word for it. The tree does not tell you what to build. It holds the space between the goal and the guess long enough for a team to see the whole board.

The second layer is where most trees break. An opportunity is an unmet need or a pain point that showed up in a customer's story. It is never a feature with "ability to" bolted on the front. Torres counts 98% of written opportunities as solutions in disguise.

Teams tend to want to frame opportunities as I wish this was easier to use. We can spend our lives making this product easier to use. What are you solving for who?

Torres on framing an opportunity you can solve Watch at 16:56

The last layer is the cheapest one. You do not test a whole solution. You break it into the beliefs it rests on and test those one at a time.

How to apply it

How do you build an Opportunity Solution Tree?

Six moves. You grow the tree from the top down and prune it from the bottom up.

Put one outcome at the root.

Pick a number the team owns and can move. Everything below the root earns its place by explaining how you might move that number. That rule is what makes a branch prunable later.

Lay the top row over an experience map.

Write out the moments a customer moves through, from the trigger to the choice to the use. Hang opportunities under those moments. Torres keeps the top row to three to seven branches so a human can hold the whole tree in their head.

Read every branch back and hunt for solutions.

If a branch names a thing you would build, it is a solution and it belongs a layer down. If it names a moment that hurt, it stays. This pass is the whole difference between a tree and a roadmap in a new shape.

Frame each opportunity small enough to solve.

Torres uses the Apple TV remote and the on-screen keyboard as her example of the right size. "I wish this was easier to use" is a wish. If you cannot picture the moment it happens, the branch sits too high.

Break the big branches down until one fits a week.

"I cannot decide what to watch" is an evergreen problem. Under it sits "I cannot tell if this show is any good" and under that sits "who is in the cast". The third one a team can solve.

Branch three solutions, then test their assumptions.

Torres tells teams to compare several solutions under an opportunity instead of committing to the first obvious one. Then split each into its assumptions and run six to twelve small tests in a week.

We have to learn how to take an idea and break it into its underlying assumptions. We have to learn how to prioritize those assumptions. Then we have to learn how to run tests that are small enough that they're just testing that assumption.

Torres on the bottom layer of the tree Watch at 45:10

A team running a dozen assumption tests a week can carry three ideas at once. A team testing whole ideas struggles to carry one. The bottom layer is what sets the pace of everything above it.

Boundary conditions

When it works, when it fails

Works best when

The team owns an outcome and can pick what to build against it
You have a stock of customer stories to draw the opportunity space from
The problem space is wide and the room disagrees about where to start
Product, design and engineering read the same tree together

Fails when

The opportunity space fills with features wearing problem language
One person draws the tree and nobody else opens it again
Branches stay so broad that no team can solve a single one
You need a market size; a tree gives direction and not a number

The tree fails in a quiet way. It looks right and the boxes are full. The team then ships the roadmap it already had.

The honest test is whether the team ever cuts a branch. A tree that only grows is a backlog with better graphics.

The sources

Where Torres discusses this

08:15

Timestamp

Lenny's Podcast · Build better products with continuous product discovery

Why the tree exists at all

"That was the purpose of the opportunity solution tree: how do I add some structure to this wide open messy problem?"

13:07

Timestamp

Lenny's Podcast · Build better products with continuous product discovery

Why depth is the point of the tree

"As you move vertically down the tree your opportunities are getting smaller and smaller."

16:56

Timestamp

Lenny's Podcast · Build better products with continuous product discovery

The test that prunes a vague branch

"Teams tend to want to frame opportunities as I wish this was easier to use. We can spend our lives making this product easier to use."

45:10

Timestamp

Lenny's Podcast · Build better products with continuous product discovery

The layer under the solutions

"We have to learn how to take an idea and break it into its underlying assumptions. We have to learn how to prioritize those assumptions."

Where experts disagree

Where operators disagree: map the problem space, or shape one solution and bet?

Teresa Torres

grows the tree downward from an outcome and refuses to let a solution into the opportunity space. Several solutions branch under one opportunity so the team can compare them, and every branch has to trace back to something a customer said in a story.

Jason Fried

shapes work the other way. A senior person defines the problem and a rough solution together at the right level of abstraction, leadership bets on that shape for a fixed six-week cycle, and the filter on ideas is whether they keep coming back rather than whether an interview surfaced them.

The deciding condition is whether you already are the customer. Basecamp builds for a market Fried has lived in for two decades, so his intuition is compressed evidence and the tree would mostly re-derive what he already knows. A team handed an outcome in a domain it does not live in has no such stock, and shaping from intuition there is guessing with a deadline attached.

Useful? Send it to whoever owns the roadmap.

Want the full playbook?

Get 128 product management frameworks.

34 frameworks 21 rules 65 heuristics & principles 49 operators

From Stewart Butterfield, Ami Vora, Codebase Guidelines, and 46 more. Drop one .md into Claude, Cursor, or ChatGPT. Your AI cites practitioners, not guesses.

See the pack

Instant .md download · One-time purchase · No subscription

Related frameworks

Research

Continuous Discovery Cadence

Teresa Torres

Everything in the backlog is a bet. Weekly interviews and an opportunity tree are how the bets get better.

Research

The Reference Customer Method

Christian Idiodi

Product-market fit is not a score. It is a count of people who will put their reputation behind you.

Research

The Overall Evaluation Criterion

Ronny Kohavi

Decide what an A/B test optimizes for before it runs, and pair it with a countervailing metric, or the experiment will faithfully optimize the wrong thing.

Research

Product-Market Fit Test (40% Survey)

Sean Ellis

Ask active users how they'd feel without you. 40% 'very disappointed' is the leading indicator of fit.