By Marty Cagan · svpg.com · LinkedIn
Marty Cagan argues that good product teams must excel at product discovery, which is fundamentally a skill of learning quickly: identifying the right target customer, finding the key problems to solve, and designing workable solutions. He frames the guiding principle as testing theories as fast and cheaply as possible. Two complementary techniques are described: qualitative user prototyping, which is quick and needs no developer time but yields insight rather than statistical proof, and quantitative live-data prototyping with split testing, which proves whether something works but takes longer because it requires real code. The piece concludes that teams must be capable in both forms of learning, since each answers different questions.
01Key takeaways
- Treat product discovery as a learning discipline and aim to test assumptions as fast and cheaply as possible.
- Use quick, developer-free user prototypes to gather rich qualitative insight about whether a solution addresses real needs.
- Reserve live-data prototypes and split tests for questions that only real usage can answer, and accept their longer build time.
- Pair quantitative split testing with face-to-face user testing: the first proves what works, the second reveals why something fails.
- Build organizational competence in both qualitative and quantitative learning rather than relying on one method.
02Key sections
- Discovery as fast learning
- Product teams must find the right customer, the key problems, and viable solutions, with solution design often the hardest part. The overarching goal is to learn as quickly and cheaply as possible.
- User prototyping and user testing
- Throwaway simulations of a proposed product are put in front of real users to gather qualitative insight about usage, problem fit, and willingness to adopt. They are built in hours or days without developer help, and aim for big insights rather than statistical significance.
- Live-data prototyping and split testing
- Real code is deployed to a subset of users to measure outcomes with statistical rigor. The trade-off is that it requires developers and typically takes days or weeks to build.
- Choosing the right technique
- Use user prototypes by default for speed, but live-data prototypes when only real usage can reveal whether something works. Live-data tests prove efficacy, while face-to-face testing explains failure and what would fix it.
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.