📖 Business
Discovery vs Delivery
Product work consists of two fundamentally different activities that most organizations conflate. **Product Discovery** is the process of figuring out what to build — running cheap experiments, prototypes, and customer interactions to answer the critical questions before committing engineering resources. **Product Delivery** is the process of building production-quality software at scale — reliable, performant, and maintainable. The best product teams spend roughly half their time in each. Most companies skip discovery entirely and go straight from stakeholder request to engineering backlog, which is the single biggest reason products fail.
2
Minutes
2
Concepts
+45
XP
1
How It Works
- Discovery addresses four distinct risks before any production code is written: value (will customers buy or use it?), usability (can they figure it out?), feasibility (can engineering build it within constraints?), and viability (does it work for the business — sales, legal, finance, compliance?)
- Discovery is cheap by design: prototypes, wireframes, concierge tests, and fake-door experiments cost a fraction of production code
- Delivery is expensive: production code requires architecture, testing, monitoring, ops, documentation, and ongoing maintenance
- The traditional model (stakeholder idea → roadmap → spec → build → launch) puts all learning at the end, after the most expensive phase
- Discovery output is validated learning ("we tested this and learned X"). Delivery output is shippable software
- Teams should run discovery and delivery in parallel — not sequentially. While engineers deliver sprint N, the PM and designer are discovering sprint N+2