handbooksContinuous discovery, explained
What continuous discovery actually is, why weekly beats quarterly, and how the opportunity solution tree connects a business goal to the thing you build next.
- Continuous discovery is a weekly habit, not a phase at the start of a project. Small research activities, run by the team that builds the product, aimed at one clear outcome.
- The bar is low and specific: at least one customer conversation per week, involving the people who write the code and design the screens.
- The opportunity solution tree is the artifact that holds it together. One outcome at the top, customer needs underneath, ideas under those, tests under those.
- The hard part is not the technique. It is giving up the comfort of a roadmap that promises features on dates.
The problem this solves
Two different jobs get done by the same team, and only one of them usually gets time on the calendar. Delivery is building and shipping. Discovery is deciding what is worth building. Most companies are good at the first and treat the second as something you do once, in a kickoff, before the real work starts.
That split is how teams end up shipping a great deal and moving nothing. The code works. The feature launched on time. Nobody uses it.
Discovery is not a one-time activity because a digital product is never done. Customers change what they expect, competitors change what is normal, and the market moves underneath you. A decision you researched thoroughly in March can be wrong by September without anyone doing anything careless.
What continuous means, exactly
Teresa Torres gives it a definition tight enough to argue with, which is the useful kind:
At a minimum, weekly touchpoints with customers, by the team building the product, where they conduct small research activities, in pursuit of a desired outcome.
Every part of that sentence is doing work. Drop the weekly and you are back to project-based research. Drop the team and you get a researcher writing reports nobody reads. Drop small and each activity becomes a quarter-long study. Drop the outcome and discovery wanders forever without ever finishing anything.
The tree that holds it together
You will hear about the opportunity solution tree constantly in this handbook, so here it is early. It is a picture of how one business goal connects to the specific thing you are testing this week.
Read it top to bottom. One outcome. Underneath it, the opportunities, which are customer needs and pain points in the customer's own words, not your feature ideas. Underneath the one opportunity you picked, several competing solutions. Underneath each solution, the assumptions you need to test before you trust it.
The value is not that it is pretty. It is that the shape of it makes certain bad decisions visibly wrong. A solution floating with no opportunity above it has nothing to justify it. An opportunity that is really a feature in disguise looks obviously out of place next to its siblings.
What changes when you work this way
| Without discovery habits | With them |
|---|---|
| Success is measured by what shipped | Success is measured by what changed for customers |
| Research happens at project kickoff | Research happens every week |
| One idea, defended | Several ideas, compared |
| You test the whole feature, late | You test the riskiest assumption, early |
| The roadmap promises features on dates | The roadmap commits to an outcome |
| Leadership sees the conclusion | Leadership sees the reasoning |
Who does this
Three people, called the product trio: a product manager, a designer, and an engineer. Not a researcher who hands findings over. The people who will build the thing are the people who talk to customers, because each of them hears something the other two miss. The product trio covers how that works when your team does not look like a neat group of three.
Where to go next
- New to this? The six mindsets is the shortest path to understanding why the rest of the handbook is shaped the way it is.
- Told to ship a feature by a date? Outcomes over outputs is the conversation to have first.
- Ready to build the tree? Start with Experience maps, then Customer interviews.
- No support from your company? Start small is written for exactly that.
You are never one feature away from success, and you never will be. If you are reading this hoping for a technique that tells you which feature to build next, the answer this handbook gives is that the question itself is the problem.