By Marty Cagan · svpg.com · LinkedIn
Cagan argues that product teams face two simultaneous goals: learning fast through discovery about what customers need, and delivering robust, scalable, production-quality software they can release with confidence. These goals seem in tension, which causes confusion around the Minimal Viable Product concept. He clarifies that 'product' should mean something that can run a business, and that discovery exists to provide evidence before engineers invest in production-quality builds. Most discovery techniques should avoid consuming developer time, relying instead on opt-in customers and prototypes. The core message is to learn quickly with customers early, and only then let engineers build to production standards.
01Key takeaways
- Treat discovery and delivery as two distinct modes with different standards for speed and quality.
- Reserve the word 'product' for software that is scalable, tested, instrumented, and releasable with confidence.
- Validate customer demand and solution fit before asking engineers to build production-quality software.
- Use opt-in customers, prototypes, and observation to learn fast without consuming developer time.
- Get ideas in front of real users early and often, without pushing quick experiments straight into production.
02Key sections
- Two competing goals
- Teams must discover the right solution quickly while also delivering reliable software that customers can depend on. These goals often feel contradictory.
- The MVP tension
- Teams struggle with MVPs because fast customer feedback clashes with the fear that an early version embarrasses the brand.
- What 'product' really means
- A true product is scalable, instrumented, tested, localized, maintainable, and something the team can release with confidence, which takes substantial effort.
- Purpose of discovery
- Discovery provides evidence that the solution is worth building, so production-quality engineering effort is not wasted.
- Opt-in customers and experiments
- Many discovery techniques use volunteer customers and prototypes, mostly without developer time, to test ideas quickly.
03From the post
“A partnership dedicated to teaching best practices to product teams and product leaders”
04Frameworks mentioned
Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.