Discovery vs delivery
Discovery vs delivery is the foundational distinction in modern product development: discovery activities (research, prototyping, hypothesis testing) determine WHAT to build and why; delivery activities (engineering, QA, deployment) execute on the decision. Healthy product teams run both continuously; unhealthy teams treat discovery as a one-time 'requirements phase' before delivery begins.
The distinction matters because the two activities have different shapes. Discovery is hypothesis-driven, validated by user research, time-bounded but iterative — the goal is to learn fast and cheap. Delivery is plan-driven, validated by acceptance criteria, sprint-paced — the goal is to ship reliably. Mixing them up produces specific failure modes: 'just-in-time discovery' that delivers half-baked features; 'big-up-front discovery' that produces a spec that's stale before delivery starts; engineering work measured by velocity rather than outcome. Dual-track agile is the most common operational model; continuous discovery (Teresa Torres) is the practice that keeps the discovery side fresh.
Related terms
- Dual-track agile
Dual-track agile (sometimes called dual-track discovery and delivery) is a product-development model, codified by Marty Cagan and Jeff Patton, that runs two parallel workstreams: a discovery track that validates which problems are worth solving and what solutions will work, and a delivery track that builds the validated solutions.
- Jobs-to-be-done
Jobs-to-be-done (JTBD) is a product-discovery framework, popularised by Clayton Christensen, that frames features in terms of the 'job' a customer is hiring the product to do — the underlying outcome they want — rather than demographic personas or feature lists.