The Double Loop
Two self-contained loops — Discovery and Delivery — connected at the crossing point. Each runs independently. Together they form the complete model.
Discovery · Delivery
Two loops, not one. Discovery asks whether you are building the right thing. Delivery asks whether you built it right and whether it worked. Each is self-contained — a team can iterate through Discovery indefinitely before committing to build, and can run Delivery cycles (hotfixes, incremental improvements) without returning to Discovery.
The crossing point is not mandatory. It is a decision. When Discovery produces Acceptance Criteria that are confident enough to build, the team crosses into Delivery. When Delivery produces Impact signals that warrant a new problem cycle, the team crosses back. The loops connect where confidence justifies commitment — and where evidence justifies re-examination.
Discovery
Discovery is the problem-and-solution loop. It runs clockwise through seven nodes, each building confidence that the team is solving the right problem in the right way before any production code is written.
Something prompts inquiry — a user complaint, a metric drop, a strategic initiative, or an impact signal returning from Delivery. This node is also where the Delivery loop hands back to Discovery.
What problem are we solving? For whom? A scoped, agreed-upon problem statement. Without this, everything downstream is aimed at a moving target.
Exploring the solution space. Options, trade-offs, direction. Not a final answer — a direction recommendation that can be iterated.
UX artifacts, interaction models, and interface definitions shaped by the solution direction. The design brief becomes a structured handoff, not a Figma link and a prayer.
A working, testable artifact — lo-fi to hi-fi depending on how much confidence the team needs. The PM builds this in the developer environment with an AI coding agent before engineering begins.
Real feedback on the prototype from stakeholders and users. This is where the four product risks — value, usability, feasibility, and business viability — get answered with evidence rather than opinion, before any production code is written. The loop may return to Problem Definition or Solution Design if the prototype reveals a misalignment.
The contract for done. Authored from the validated prototype, not from abstract specification. This is the optional exit point — when AC is confident and signed-off, the team may cross into Delivery.
Delivery
Delivery is the build-and-measure loop. It runs counterclockwise through six nodes, answering whether the thing was built correctly and whether it moved the needle. Delivery can also run independently — incremental improvements and hotfixes may enter here directly without a full Discovery cycle.
Production-quality code, shaped by the Acceptance Criteria from Discovery. Engineers review, adapt, and own the output. The entry point from Discovery.
Unit, integration, and CI pipeline checks. Confirming the implementation is internally consistent before wider validation.
End-to-end tests run against the Acceptance Criteria authored in Discovery. The AC written in the left loop is validated in the right loop — this is the load-bearing connection between the two circles.
Release to production. Not the end — the beginning of the measurement phase.
Is the system working? Telemetry, error rates, latency, operational health. Operational signals — distinct from strategic impact.
Did it move the metric? Post-deployment measurement against the original problem statement. The persevere / pivot / kill decision node. When impact signals warrant a new problem cycle, this node hands back to Discovery — becoming the Signal that starts the left loop again.
When to Switch Circles
The crossing is a decision, not a gate. Discovery exits to Delivery when the Acceptance Criteria are validated and the team is confident enough to commit engineering time. Delivery exits back to Discovery when Impact signals reveal a problem worth re-examining — a feature that didn't move the metric, an assumption that turned out wrong, or a new user behavior the prototype didn't anticipate.
Teams that skip Discovery and go straight to Delivery build the wrong thing efficiently. Teams that loop Discovery indefinitely and never cross into Delivery produce validated prototypes no one uses. The discipline is knowing which crossing to make, and when.