Continuous Discovery Feedback Loop
Run customer learning beside delivery so each product bet improves over time.
- Difficulty
- Advanced
- Time to result
- ~ongoing to results
- Steps
- 6
- Confidence
- 98%
Continuous Discovery treats discovery as a recurring feedback system rather than a research phase that precedes delivery. Digital products are never finished, customer needs continue to change, and teams continuously decide what to build. The method therefore keeps the customer inside that decision process through sustainable touchpoints, such as one interview each week, while assumption tests and delivery proceed in parallel. The team does not stop all work until every backlog item is fully researched. It keeps making bets, adds discovery alongside them, instruments what reaches production, and learns from the resulting feedback. Over time, its understanding of the opportunity space deepens and its bets improve. The cadence matters because small, repeated learning activities fit the pace of a business better than occasional research projects that require delivery to stop.
Origin
Torres frames the method as a response to digital products that never reach a final state and therefore require teams to make customer-informed product decisions continuously.
Core principles
- 01Digital products and customer needs keep evolving.
- 02Discovery is the work of deciding what to build.
- 03Customer feedback belongs inside an ongoing decision process.
- 04Discovery and delivery happen in parallel, not as sequential phases.
- 05Discovery improves bets rather than eliminating all risk.
How to run it
- 1
Own an outcome
Start with the result the team is responsible for influencing. Use it to focus discovery without prescribing the solution in advance.
Pro tip Connect the outcome to the product's business model and customer value.
Watch out A fixed feature list leaves the team little room to use what it learns.
- 2
Establish a weekly touchpoint
Create a customer-learning activity the team can sustain every week. A single weekly interview can be enough to begin building the habit.
Pro tip Reduce the recruiting work until the interview appears on the team's calendar automatically.
Watch out A heavy project-based study is difficult to repeat at the cadence of product decisions.
- 3
Update the opportunity space
Use interviews or observations to identify unmet needs, pain points, and desires. Add what the team learns to its evolving view of customer opportunities.
Pro tip Ground opportunities in behavior rather than requested features.
Watch out Customer inclusion is not achieved by collecting opinions that never affect decisions.
- 4
Test while delivering
Run small assumption tests as delivery continues. Treat testing as the beginning of delivery rather than a gate that must be completed before work can proceed.
Pro tip Add discovery alongside existing delivery before trying to change the whole operating model.
Watch out Stopping every bet until it is fully discovered can destroy organizational appetite for discovery.
- 5
Measure released impact
Instrument solutions and observe what happens after release. Use production behavior as a larger feedback loop that follows the smaller discovery tests.
Pro tip Compare expected impact with observed impact to improve the team's judgment about risk.
Watch out Without measurement, the team cannot tell whether apparently safe bets were actually risky.
- 6
Improve the next bet
Feed interview, test, and production evidence into the next decision. The objective is not certainty but a steadily better series of bets.
Pro tip Review how new evidence changed the team's opportunity framing and solution choices.
Watch out Treating a discovery activity as a one-time certification loses the compounding value of the loop.
In the wild
Torres describes a team that has historically made every product bet with no discovery. Instead of freezing the backlog until every item is researched, the team continues delivery and adds a weekly interview plus small assumption tests in parallel. Released work is instrumented, so the team can compare its expectations with actual behavior and fold the result into the next decision.
→ The organization preserves delivery while its product bets become better informed over time.
Common mistakes
Treating discovery as a phase
Separating discovery and delivery into consecutive stages conflicts with a product environment where both decisions and delivery are continuous.
Requiring perfect discovery first
Blocking every backlog item until it has been fully researched can halt delivery and make colleagues resist discovery.
Using project-sized research by default
Long studies may be valuable, but they rarely match the weekly cadence at which product teams need to learn and decide.
Is it for you?
Best for
Digital product teams that continuously evolve an existing product and repeatedly decide what to build next.
Not ideal for
One-off projects with no continuing product decisions, customer feedback, or post-release iteration.
From the episode
Teresa Torres on how to interview customers, automating continuous discovery, the opportunity solution tree framework, making the case for user research, common interviewing mistakes, and much more