Most teams do discovery in bursts. A big research project ahead of a big bet, then nine months of building with no new customer input. The problem is not the research quality — it is that the findings expire while the roadmap keeps going.
Continuous discovery replaces the burst with a habit: a small number of customer conversations every week, feeding a structure that survives between them. That structure is usually an opportunity solution tree, popularised by Teresa Torres.
The four layers
The tree has one job: keep the line visible between what you are building and why.
- Outcome — the single measurable change you are trying to produce. Not a feature. Not revenue in general.
- Opportunities — the needs, pain points and desires you have actually heard, phrased in the customer's terms.
- Solutions — the things you could build for a given opportunity. Several per opportunity, always.
- Assumption tests — the small experiments that tell you whether a solution will work before you commit to it.
A tree with three outcomes is three trees, and in practice it becomes a wish list with branches. If you cannot name the one number this quarter is about, that is the problem to solve before you do any more research.
Opportunities are found, not invented
The discipline that makes this work: an opportunity may only go on the tree if it came out of a real conversation. Not a stakeholder request, not a competitor's feature, not an idea from the offsite.
Good opportunities sound like the customer:
- "I can never tell which of these are new since I last looked."
- "I have to check three places before I can answer my manager."
- "I redo this every month and it takes a morning."
Things that are not opportunities, however often they get filed as one:
- "We need a dashboard" — that is a solution wearing a need's clothing.
- "Users want better UX" — too vague to act on or disprove.
- "Competitor X has notifications" — that is a competitor's decision, not your customer's need.
When a stakeholder brings you a solution, your job is to walk it back up the tree until you find the opportunity underneath. Sometimes there isn't one, and that conversation is much easier to have with a tree on the wall.
Always more than one solution
The most common failure is a tree where every opportunity has exactly one solution beneath it. That is not a tree, it is a backlog with extra steps — the decision was made before the structure was drawn.
Force at least three solutions per opportunity you take seriously. The third one is usually where the cheap idea lives. Teams that do this routinely find that their expensive default was rarely the best option, only the first.
Assumption tests: the part that saves money
Before building a solution, name what has to be true for it to work. Typically four kinds of assumption:
| Assumption | The question | Cheap test |
|---|---|---|
| Desirability | Do they want it? | Interview, fake door, landing page |
| Viability | Does it work for the business? | Back-of-envelope unit economics |
| Feasibility | Can we build it? | A day of engineering spike |
| Usability | Can they operate it? | Prototype test with five people |
Test the assumption that would hurt most if wrong, first. Most teams instinctively test the one that is easiest to check, which is how you end up confident about the wrong things.
Trees become wallpaper. They get drawn in a workshop, photographed, and never updated again. A tree that has not changed in six weeks is not tracking your understanding — it is decorating a wall. Either it changes as you learn, or it is not doing the job.
The weekly rhythm
A workable cadence for a team that also has to ship:
- One or two customer conversations a week. Booked in advance, standing slot, recruited continuously so cancellations do not break the chain.
- Twenty minutes to update the tree. New opportunities added, existing ones reinforced or contradicted.
- One assumption test in flight at any time, however small.
- The trio attends — product, design and engineering together. Second-hand research loses most of what mattered.
That last point does more work than the framework itself. An engineer who has watched three customers struggle will make better decisions in a hundred small moments you are not present for. That is the actual return on continuous discovery, and no summary document reproduces it.
When not to bother
This is a framework for problem spaces with genuine uncertainty. If you are shipping a legally mandated change, paying down obvious technical debt, or fixing something clearly broken, skip it and go build. Applying discovery ritual to a decision that is already made wastes the ritual and annoys the team.
For getting the conversations themselves right, see customer interviews that produce decisions. Once you have opportunities worth acting on, prioritisation frameworks decide which one goes first.