Continuous discovery

What it is

Product work is two jobs running in parallel: discovering the right product, and delivering that product right. Marty Cagan described the parallel structure in 2012 — a discovery track continuously generating validated backlog items while the delivery track continuously builds, tests and deploys them. Jeff Patton had shared the name “Dual-Track Scrum” with him; Cagan later retired the dual-track label because it pulled attention toward process and away from principle, and settled on the terms used here: continuous discovery and continuous delivery.

Teresa Torres turned the principle into an operating habit in Continuous Discovery Habits (2021): the team building the product — not a separate research function — holds customer touchpoints at least weekly, running small research activities in pursuit of a desired product outcome. Her cadence and this playbook’s agree on the core: discovery is something the team does every week, not something done to the team before delivery begins.

The reasoning is economic. Building and launching a feature is the slowest and most expensive way to find out whether anyone wanted it. An interview, a prototype or a fake-door test answers the same question in days for a fraction of the cost. Discovery exists to kill bad ideas while they’re still cheap.

That last word is deliberate. A healthy discovery track kills hypotheses regularly. A killed hypothesis is the cheapest feature you never built — the waste you never created. And the price of killing climbs steeply with time: Boehm’s cost-of-change curve — the exponential behind How to fix a $25 bug before it becomes a $37,500 problem — applies to misconceived features just as it does to defects. An idea killed in discovery costs an interview and a prototype; the same idea killed after release has already consumed increments. If every idea that enters your discovery loop comes out “validated,” you don’t have a discovery track; you have a confirmation ritual.

Delivery answers are we building it right? Discovery answers are we building the right thing? — and that answer decays. The playbook’s early activities (product vision, event storming, value mapping) produce a strong first draft of what’s valuable. But those workshop outputs are hypotheses, and customers, markets and constraints move. A team that did discovery once and delivers forever is a feature team pretending to follow a product model.

When to use it

Always — that’s the point of continuous. But certain signals mean the absence of discovery is already costing you:

• The value map hasn’t changed since the workshop. Value mapping (3.1) re-runs every increment; if its inputs never change, the team is iterating on build decisions while the what-to-build decisions quietly go stale.
• The backlog justifies features with “the customer asked for it.” A request is a signal, not evidence. Discovery turns requests into tested hypotheses before they consume an increment.
• Demos land flat. The team ships what was specified and the customer’s reaction is polite. That gap — between specified and wanted — is exactly what weekly touchpoints close.
• Prioritization debates run on opinion. When nobody has fresh evidence, the loudest voice wins. Discovery gives the product manager standing to say “we tested that” instead of “I think.”
• The designer’s calendar is all production work. If your product designer spends every hour on delivery-track artifacts, nobody owns learning. Discovery is where the designer’s research skills earn their seat in the trio.

How to run it

Minimal viable discovery is three habits. Start with these; add technique as the team matures.

1. One customer touchpoint every week. Held by the trio — product manager and product designer leading, tech lead joining when feasibility is the open question. Interviews, prototype walkthroughs, watching a user work: small activities, held weekly without exception. The cadence matters more than the format; a team that “does research when needed” does research never. And the touchpoint is the trio’s discipline, not the team’s only line to the customer — the customer is part of the team throughout the playbook, joining event storming, attending demos, sharing the table from team mobilization (1.1) onward. Discovery adds a structured weekly channel; it doesn’t replace the open ones.
2. A hypothesis log beside the increment backlog. The log is created during team mobilization (1.1) from this template — empty, alongside the backlog — and starts filling the moment the team forms its first opinion about what to build; strategic event storming (2.3) is where it usually gets its first real harvest. Every candidate feature gets written as a falsifiable statement — who it serves, what outcome it should move, what evidence would change your mind. Each hypothesis gets the cheapest test that can settle it: an interview script, a clickable prototype, a fake door, a feasibility spike. Log the verdict where the whole team can see it: validated (feeds the value map and increment selection) or killed (celebrated, then closed).
3. Prototype before you build anything you haven’t tested. The prototype is the discovery track’s unit of work, the way the increment is the delivery track’s. Most of the time you can validate an idea before writing production code — and the prototype that validates it becomes the cheapest, clearest specification delivery could ask for.

Ownership is the trio’s, with the pair at the center: the product manager owns what the evidence means for value and viability; the product designer owns how usability gets tested and runs the research craft; the tech lead answers for feasibility and joins spikes. Owning the loop is not the same as monopolizing the customer — the whole team keeps its direct contact through workshops, demos and day-to-day co-working, and discovery findings land in the open where everyone works with them. What the trio owns is the discipline: that the cadence holds, the tests are honest and the verdicts reach the backlog. Discovery is not delegated to a research team, a “discovery office” or the customer’s own product staff. The moment discovery becomes a separate function that hands “validated features” to delivery, you’ve rebuilt the requirements silo with newer furniture.

Track the health of the loop with two numbers: touchpoints held per week (target: one, every week) and the kill rate. A kill rate near zero means the tests aren’t honest. Roughly a third of hypotheses dying in discovery is normal — that’s the waste you didn’t build.

Where it lands in the playbook

The playbook is already built to receive discovery. The subway map draws a continuous feedback channel running from validation back through the design and delivery chapters — elaboration, increment selection, functional architecture, context mapping, domain modeling, event storming — all the way to business capabilities (1.4), and a second channel carrying production intelligence along the same path. Evidence riding those channels can inform any stop it passes — every activity re-opens when the evidence says it should. Discovery is what keeps the channels carrying fresh evidence rather than old assumptions. The most common landing zones:

• 3.1 Value mapping — discovery evidence is a named input. The value map is refreshed by what the trio learned this week, not re-drawn from memory of the workshop.
• 3.3 Identify product increment — increment selection cites the hypothesis log. A validated hypothesis strengthens a candidate; a killed one legitimately removes it.
• 2.2 Roadmaps and OKRs — outcome checks draw on discovery evidence and the instrumentation prescribed in 3.8 Engineering, on their own cadence.
• Production telemetry feeds discovery directly. Usage data, support themes and incident intelligence flow to the team — the team hears the product itself, not a quarterly report about it.

The loop’s intake runs just as wide as its outputs. Customer requests and telemetry feed it continuously, but the richest single source is strategic event storming (2.3): an event map is a room full of assumptions made visible, and that chapter’s Harvesting hypotheses step walks the fresh map specifically to seed this log.

Worked example

A team building a claims-intake product had “bulk document upload” at the top of its candidate list — the feature brokers requested most often. Written as a hypothesis: brokers lose enough time to one-at-a-time uploads that batch upload would move intake completion time. The cheapest test wasn’t building it; it was watching three brokers work. Two touchpoints later the evidence said something different: brokers weren’t uploading documents one at a time because the tool lacked batch — they were doing it because each document required a classification the insured had usually gotten wrong upstream. The time sink was correction, not clicking.

The hypothesis was killed in eight days. Its replacement — pre-validate classification at the insured’s first submission — was prototyped the following week, tested with the same brokers, validated and selected into the next increment through the increment-selection activity (3.3). The team never built batch upload. Nobody missed it.

That is the loop working: a request became a hypothesis, the cheapest test killed it, and the evidence surfaced the feature that was actually worth an increment — before a line of production code existed.

Common failure modes

• Discovery as a phase. The team runs strong workshops in Phase 1–2, then never tests another assumption. Symptom: the value map’s last edit date. Discovery that ended is discovery that failed. Fix: put the weekly touchpoint on the calendar as a standing event, and treat the value map’s age as a health metric — older than two increments means discovery has stopped.
• The discovery office. A separate function does the “validating” and hands finished, “validated features” to the delivery team. This is the requirements silo reborn — the team building the product never meets the customer, and the empowered team the model depends on never appears. Fix: move discovery inside the team. The product manager and designer run it; researchers and specialists support the trio rather than replacing it.
• Research theater. Touchpoints happen, notes accumulate, nothing changes in the backlog. If the hypothesis log and the increment selection can’t point to each other, the loop isn’t closed — you’re collecting anecdotes, not evidence. Fix: require every increment-selection decision to cite the hypothesis log, and every touchpoint to end with a log entry — a verdict, a new hypothesis or an explicit “learned nothing.” A touchpoint that produces no entry didn’t happen.
• A 100% validation rate. Every hypothesis confirms. The tests are designed to succeed, or the only hypotheses entering the loop are safe ones. Watch the kill rate the way you watch escaped defects. Fix: write every hypothesis falsifiably before testing — name the evidence that would change your mind — and review the kill rate in retrospectives. A quarter that killed nothing gets a harder look than one that killed five.
• The designer as wireframe vendor. Usability testing and user research are the product designer’s discovery craft. A designer consumed entirely by production artifacts means usability risk goes untested until customers find it for you. Fix: plan discovery hours as first-class work in increment planning, not slack the designer scrapes together. If the designer’s week has no research in it, the plan is wrong, not the designer.
• Waiting for permission. Teams sometimes treat customer contact as something account management grants. One touchpoint a week is the team’s own responsibility — negotiate access once, then keep the cadence. Fix: make customer access part of team mobilization (1.1) — it’s already a stakeholder commitment there. Agree on the standing weekly slot at kickoff and never renegotiate it session by session.

References

• Marty Cagan, Continuous Discovery, Silicon Valley Product Group, October 24, 2012 — the continuous discovery and delivery trend, and why kanban-style flow fits it naturally.
• Marty Cagan, Dual-Track Agile, Silicon Valley Product Group, September 17, 2012 — the parallel-track structure; credits Jeff Patton for the “Dual-Track Scrum” name, and explains (in a later update) why Cagan retired the term in favor of continuous discovery and delivery.
• SVPG, The Product Operating Model: An Introduction, February 10, 2023 — where discovery sits among the model’s concepts, the four risks (valuable, usable, feasible, viable) and team competencies.
• Teresa Torres, Continuous Discovery Habits (Product Talk LLC, 2021) — the weekly-touchpoint definition, the product trio in discovery and the opportunity solution tree.
• Marty Cagan, Inspired: How to Create Tech Products Customers Love, 2nd ed. (Wiley, 2018) and Marty Cagan et al., Transformed: Moving to the Product Operating Model (Wiley, 2024).
• Hypothesis log template — the working surface for this practice: entry format, verdicts and worked examples.
• Playbook glossary — Continuous discovery, Product trio, Flow.
• Building a product oriented team and Product teams really do outperform — the team model discovery assumes, and the evidence behind it.