Continuous discovery and the opportunity solution tree

Origin

Teresa Torres, 2016 (tree); 2021 (book)

Level

401 · Expert

Fits

Startup, Scale-up

Time to apply

an afternoon to set up the first tree, then two to three hours a week for the trio

What you need

one product outcome the team can move, agreed with leadership · a product manager, a designer and an engineer who share the work · a way to book one customer conversation a week without manual effort · a shared board, physical or digital, for the tree

Continuous discovery is a way of running product research as a weekly habit instead of a project that happens once a year. Teresa Torres, a product discovery coach, defines it in a 2021 interview with Maze as, at minimum, weekly contact with customers by the team building the product, through small research activities aimed at a desired outcome.

Torres first published the opportunity solution tree, the method’s central diagram, in 2016, as her Product Talk article on the tree notes. Her book Continuous Discovery Habits followed in 2021; she announced it on 19 May that year as a guide for product trios. Product managers, designers and engineers in software companies are the main users, though the logic works for any team that ships changes to customers often.

Why weekly, and why the builders

Weekly contact keeps decisions close to fresh evidence. A team that runs one big study a year makes eleven months of choices on stale notes. Small, repeated research also finds problems more cheaply: Jakob Nielsen argued in 2000 that several studies with five users beat one large study.

The people who build the product do the talking themselves. Torres calls the unit a product trio: a product manager, a designer and a software engineer who share responsibility for an outcome and work together from the first interview, instead of passing work along a chain. Marty Cagan of SVPG makes a similar case when he contrasts product teams that own a problem with feature teams that only deliver a roadmap someone else wrote.

There is a reason to distrust instinct here. Kohavi and Thomke describe in Harvard Business Review how a Bing headline idea sat untested for months as low priority, then lifted revenue by 12 percent once tested. Teams misjudge their own ideas often enough that regular contact with customers pays for itself.

	Project-based research	Continuous discovery
Cadence	A study before a big release	At least one touchpoint a week
Who talks to customers	A research team, who report back	The trio that builds the product
Output	A report	An updated tree and a decision
Goal	Answer one question	Move one product outcome

How the opportunity solution tree works

An opportunity solution tree is a diagram of the paths a team might take to reach an outcome. Torres’s guide describes four layers, read from top to bottom.

The outcome sits at the root. Below it is the opportunity space: customer needs, pain points and desires that, if addressed, would move the outcome. Below a chosen opportunity is the solution space, the ideas the team is weighing. At the bottom are assumption tests, which show which solution creates value for customers in a way that also works for the business.

The hardest layer is the opportunities. Teams tend to write solutions there, such as “users need a dashboard”. Torres’s check is simple: if there is more than one way to address it, it is an opportunity; if not, it is a solution in disguise. In her 2019 Business of Software talk she also asked teams to phrase opportunities in the customer’s own words.

Choosing the right outcome

The root of the tree decides whether the rest works. Torres separates three kinds of metric in a 2022 article. Business outcomes, such as revenue or market share, usually need many teams and move slowly. Product outcomes measure what customers do in the product, so a single team can influence them. Traction metrics track one feature and are often too narrow.

Her test for a traction metric: could a happy customer reasonably never use that feature? If yes, it is a poor outcome for discovery. Teams that already run a KPI tree can pick a product outcome from one of its lower branches.

Interviews, recruiting and the weekly loop

Discovery interviews ask about one specific past event. Torres’s guide to story-based interviews shows why: general questions get idealised answers, while “tell me about the last time” brings out what really happened. This is close to the rules in The Mom Test.

Recruiting is where the habit usually breaks, so Torres asks teams to automate it. The Product Talk glossary describes the target as interviews that appear on the calendar with no weekly manual work. In a 2022 case, a product manager at Zonar Systems set up an in-app prompt and a booking page in about an hour and got almost a dozen sign-ups overnight. The same case advises booking twice as many slots as needed, because about half of participants did not show up.

Torres told Maze that teams should update the tree every three or four interviews. The loop then repeats: new stories add opportunities, tests settle some questions and raise others.

Compare and contrast, then test assumptions

Torres asks teams to compare options rather than judge one idea at a time. Reviewer Yevgeniy Brikman sums it up as replacing “should we build this?” with “which of these is best?”. Her tree guide recommends at least three solutions for the target opportunity.

Decision research supports the habit. Paul Nutt’s 1999 study of 356 organisational decisions found that about half failed, and traced failure to managers who imposed a solution and cut short the search for alternatives.

Each solution rests on assumptions. Torres’s assumption testing guide lists five types: desirability, viability, feasibility, usability and ethics. Teams map them by importance and evidence, a technique she credits to David Bland, and test the important, weakly supported ones first with prototypes, one-question surveys, data mining or engineering spikes. These overlap with Cagan’s four big risks of value, usability, feasibility and business viability.

How it compares with nearby methods

Method	Main focus	How it relates
Double Diamond	A design project from problem to delivery	Runs as phases; continuous discovery runs all the time
Lean Startup	Build-measure-learn on a whole business model	Tests a company’s model; the tree works inside one product outcome
Jobs to be done	Why customers choose a product	Supplies the language for the opportunity layer
Cagan’s four risks	Which risks a product idea carries	Similar to the assumption types under each solution

Limits and criticism

The method costs time every week, and that time is the first thing cut when deadlines press. Torres concedes the point: in her 2024 Y Oslo talk she pushed back on the idea that teams must adopt every habit, suggested starting with as little as 30 minutes a week, and said that something is better than nothing.

It also assumes conditions many teams lack: direct access to customers, an outcome rather than a roadmap, and leaders who accept evidence over opinion. A ProductPlan guide adds that low-risk, reversible changes may not justify the effort, and that faster AI-assisted building tempts teams back into shipping features without asking why.

Evidence for the tree itself is mostly practitioner experience. The nearest controlled test is a trial on hypothesis-driven work in general: founders trained to state and test hypotheses dropped weak ideas sooner and earned more on average, as the authors report at Innovation Growth Lab. In Pushers’ Growth Lab work, weekly customer contact of this kind feeds the hypotheses we test.

How to apply Continuous discovery and the opportunity solution tree, step by step

1. Agree on one product outcome. Translate the business goal into a customer behaviour the team can influence, such as the share of new users who complete a first payment within seven days. Avoid feature usage numbers that a happy customer could ignore. Result: one outcome at the root of the tree, owned by the team.
2. Automate interview recruiting. Add an opt-in prompt inside the product or ask sales and support to send interested customers to a self-scheduling link. Book extra slots, since many people do not show up. Result: at least one customer conversation on the calendar every week without anyone chasing it.
3. Interview for stories as a trio. The product manager, designer and engineer attend together. Ask about one specific recent event, such as the last time the customer tried to pay an invoice, and let them tell it in order. Write a one-page summary straight after. Result: a short record of needs, pain points and context from each conversation.
4. Map opportunities on the tree. Every three or four interviews, add the needs you heard as opportunities under the outcome, phrased the way customers put them. Group them, split big ones into smaller ones, and pick one target opportunity to work on. Result: an updated tree and one chosen opportunity.
5. Generate at least three solutions. Brainstorm separately, then together, and keep three distinct ideas for the target opportunity. For each, list the assumptions that must be true for it to work: that customers want it, can use it, that you can build it and that it pays. Result: three candidates and a list of their assumptions.
6. Test the riskiest assumptions and decide. Map assumptions by importance and by how much evidence supports them, then test the important, weakly supported ones with prototypes, one-question surveys or existing data. Set pass criteria before each test. Result: evidence to drop, change or build a solution, and new questions for next week's interviews.

Examples

A payments app with slow activation

Illustrative. A fintech team's outcome is the share of sign-ups who send a first transfer within seven days, now 30 percent. Six weekly interviews show that small business owners stall when asked for documents they do not have to hand. The trio maps three opportunities and targets 'I do not know which documents I need'. They compare a checklist email, a save-and-resume flow and a document photo upload. A prototype test shows owners abandon the checklist, so the team builds save-and-resume first and watches the seven-day rate.

A clinic booking service

Illustrative. A healthcare software team wants more patients to rebook a follow-up visit online rather than by phone. Story-based interviews with ten patients reveal that most were told to 'come back in a few weeks' with no date. The opportunity becomes 'I do not know when I should come back'. Of three solutions, a reminder with a suggested date passes a one-question survey and a small pilot, while a loyalty discount does not change behaviour in the pilot.

A B2B analytics tool

Illustrative. A trio at a SaaS company is told to 'increase revenue'. They agree with their manager on a product outcome they can move: weekly active report viewers per account. The engineer, who joins interviews for the first time, hears customers export data to spreadsheets because filters are slow, and proposes a research spike on query speed that becomes one of three solutions on the tree.

When to use it

Use it when a product team owns an outcome rather than a feature list, ships often enough to act on weekly learning, and can reach its customers directly. It fits startups searching for repeatable value and scale-ups whose teams have drifted into building whatever stakeholders request. It also helps when leaders want to see why a team chose one idea over another.

When not to use it

It is overkill for low-risk changes that are cheap to reverse, such as copy tweaks you can A/B test. It struggles when the team cannot reach customers at all, when leadership hands down a fixed roadmap and measures output, or when a single large decision needs a one-off study, such as sizing a new market. In those cases fix the outcome and access problems first, or run a dedicated research project.

Common mistakes

• Putting a business metric like revenue at the root. Few teams can move it directly, so the tree turns into a wish list.
• Writing solutions disguised as opportunities, such as 'customers need a dashboard'. If there is only one way to address it, it is a solution.
• Interviewing to validate an idea the team already likes, instead of collecting stories about past behaviour.
• Choosing the first solution that sounds good rather than comparing at least three.
• Leaving the engineer out of interviews, which turns discovery back into a handoff.

FAQ

What is an opportunity solution tree?

It is a diagram Teresa Torres introduced on her Product Talk blog to show how a product team might reach an outcome. The outcome sits at the root, customer needs and pain points (opportunities) branch below it, possible solutions hang under the chosen opportunity, and assumption tests sit under the solutions. It keeps every idea tied to a need and a goal.

How do you build an opportunity solution tree?

Start with one product outcome your team can influence. Interview customers about specific recent experiences and add the needs you hear as opportunities beneath the outcome. Group and split them, pick one target opportunity, list at least three solutions for it, and add tests for the riskiest assumptions behind each. Update the tree every few interviews.

What is continuous discovery?

Continuous discovery is Teresa Torres's term for product research done as a habit rather than a project. Her benchmark is at least one customer touchpoint a week by the team building the product, with small research activities aimed at a desired outcome. Interviews, opportunity mapping and assumption tests happen alongside delivery, not before it.

How many customer interviews per week does continuous discovery need?

Torres sets the minimum at one touchpoint a week for the team that builds the product. In a 2024 talk she suggested starting with as little as 30 minutes a week and growing from there. The cadence matters more than the count, which is why she recommends automating recruiting so interviews keep happening.

How does continuous discovery relate to jobs to be done?

They work well together. Jobs to be done explains what progress customers are trying to make. Continuous discovery is an operating rhythm for a product team: weekly interviews, a tree of opportunities and assumption tests. Many teams use job-style story interviews to fill the opportunity layer of the tree.

Sources

1. Teresa Torres, Product Talk, Opportunity solution trees: visualize your discovery to stay aligned, 2023
2. Teresa Torres, Product Talk, Continuous Discovery Habits book announcement, May 2021
3. Teresa Torres, Product Talk, Product trios: what they are and why they matter, 2021
4. Maze, Making better product decisions with Teresa Torres, 2021
5. Teresa Torres, Product Talk, Story-based customer interviews
6. Teresa Torres, Product Talk, Y Oslo 2024: when it comes to discovery, something is better than nothing
7. Teresa Torres, Product Talk, Assumption testing, 2023
8. Teresa Torres, Product Talk, Defining product outcomes: the 8 most common mistakes, 2022
9. Product Talk, Product in practice: automating customer interview recruiting at Zonar Systems, 2022
10. Product Talk glossary, Automate your recruiting
11. Business of Software, Teresa Torres: shifting from managing by outputs to managing by outcomes, 2019
12. Lenny's Podcast, Teresa Torres on how to interview customers and the opportunity solution tree, 2022
13. Yevgeniy Brikman, review of Continuous Discovery Habits, 2023
14. ProductPlan, How to build a weekly continuous discovery habit you can defend
15. Marty Cagan, SVPG, The four big risks, 2017
16. Marty Cagan, SVPG, Product vs feature teams, 2019
17. Paul Nutt, Surprising but true: half the decisions in organizations fail, Academy of Management Executive, 1999
18. Innovation Growth Lab, Camuffo, Gambardella, Cordova and Spina on the scientific approach to entrepreneurial decisions, 2020
19. Ron Kohavi and Stefan Thomke, Harvard Business Review, The surprising power of online experiments, 2017
20. Jakob Nielsen, Nielsen Norman Group, Why you only need to test with 5 users, 2000
21. UK Design Council, The Double Diamond
22. Eric Ries, The Lean Startup, principles
23. Steve Blank, Harvard Business Review, Why the lean start-up changes everything, 2013
24. Christensen, Hall, Dillon and Duncan, Harvard Business Review, Know your customers' jobs to be done, 2016

Last updated Oct 9, 2026