Two loops running at once: delivery ships code, discovery learns what to build. The operating model that keeps a team from becoming a feature factory.
▸ Try the interactive toolThe Discovery–Delivery Cycle is the operating model describing how modern teams run two loops simultaneously rather than sequentially. The delivery loop ships code — build, test, release in sprint cadence. The discovery loop learns — interviews, experiments, and analysis that decide what's worth building next.
The crucial word is simultaneously. Discovery isn't a phase that finishes before delivery starts; the two loops run continuously and in parallel, with discovery always working slightly ahead on what delivery will build next. When the loops separate — discovery as an occasional project, delivery as the default — the team drifts into a feature factory, shipping steadily without learning whether any of it matters.
Delivery loop — build, test, ship validated work (engineering-led, sprint cadence)
Discovery loop — learn what to build and validate it (PM/design-led, continuous)
Run in parallel, discovery slightly ahead — not in sequence.
The default gravity of any team is toward delivery, because shipping is visible and learning is not. Without a deliberate cycle, discovery quietly disappears.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Sequential, not parallel | Discovery becomes a one-time phase; once building starts, learning stops. | Parallel loops keep learning continuous alongside shipping. |
| Delivery crowds out discovery | Shipping is visible and rewarded; discovery gets dropped under pressure. | A defined cycle protects discovery time structurally. |
| Feature factory | The team ships constantly without knowing if it matters. | Continuous discovery ensures what's shipped was worth building. |
| Discovery lags delivery | Learning arrives after the build, too late to change it. | Discovery runs ahead, so findings shape what's built next. |
Set up discovery and delivery as concurrent, ongoing activities. Delivery ships this sprint's validated work while discovery validates next sprint's.
Discovery should always be working on what delivery will tackle next, so validated work is ready when engineering needs it. If discovery falls behind, slow delivery — don't skip discovery.
Because delivery's gravity is strong, discovery needs defended time — a weekly rhythm, dedicated sessions. Left to chance, it evaporates.
The loops connect: validated learnings flow into the delivery backlog, and delivery's results raise new questions for discovery. Keep the handoff constant, not occasional.
Track not just velocity (delivery) but what was learned and how it changed the plan (discovery). What you don't measure, you stop doing.
A team prided itself on velocity — it shipped every sprint, reliably. But it ran discovery only occasionally, as a project before big initiatives, and the rest of the time just built from the backlog. Plenty shipped; little of it moved the metrics.
Restructuring around continuous discovery — a parallel loop running every week, slightly ahead of delivery — meant features entered the build only after the value risk was retired. Velocity stayed high, but now it was pointed at validated work. The shipping rate barely changed; the hit rate transformed.
The deliverable is a working rhythm where both loops run weekly — discovery feeding a validated backlog that delivery pulls from.
| Loop | Owns | Cadence | Output |
|---|---|---|---|
| Delivery | Engineering + QA | Sprint | Shipped, validated features |
| Discovery | PM + design (+ research) | Continuous, weekly | Validated problems & solutions |
| The link | PM bridges both | Constant | Findings → backlog; results → questions |
The two loops aren't a sequence — they're a system running in parallel. The moment discovery becomes a phase that ends before delivery begins, the team starts shipping blind.
The structural insight is that delivery always wins a fair fight for attention, because shipping is visible, measurable, and praised, while learning is none of those by default. So discovery can't be left to good intentions — it has to be protected by cadence and made visible by measurement. A team that runs both loops continuously, with discovery always a step ahead, keeps its velocity and its aim. That's the whole difference between a team that ships a lot and a team that ships what matters.
“We did discovery, now we build” kills the parallel loop. Discovery is continuous.
Under deadline pressure discovery is the first casualty. Protect its time structurally.
Learning that arrives after shipping can't change it. Keep discovery ahead.
If you track shipping but not learning, you'll optimise for a feature factory.
The discovery loop's job is retiring the four risks (Tool 01) before delivery commits.
The cycle stays alive through a concrete weekly cadence (Tool 23) — the operational form of “continuous.”
The OST (Tool 03) is how the discovery loop stays organised around an outcome rather than wandering.
This is the fuller treatment of Module 1's Dual-Track model — the same parallel-loops idea, here as a continuous operating system.
For a team you know, ask: is discovery continuous and parallel, or an occasional phase? Is it ahead of delivery, behind it, or absent?
Look at the last quarter's shipped work: how much was validated by discovery before building versus pulled straight from a backlog on assumption?
If most work shipped without a discovery loop ahead of it, you've found a feature factory — and the fix is parallel loops, not slower shipping.