Product Discovery

Cagan argues that product teams commonly treat requirements and design as a scheduled, sequential phase, which leads to engineers building unvalidated solutions that customers don't want. He reframes this stage as 'product discovery,' a creative and uncertain process requiring validation of both the market opportunity and a usable, useful, feasible solution. He explains that management resists this uncertainty because it seems unpredictable and because engineers appear idle, yet building too early wastes engineering effort and turns customers into test subjects. He recommends a faster discovery process with small prototyping efforts before committing full engineering resources, and engaging engineers in discovery itself.

01Key takeaways

• Treat product definition as discovery, validating both the market opportunity and a workable solution before committing engineering time.
• Don't stick to a fixed schedule for requirements and design if user feedback shows the solution isn't working.
• Use quick, cheap prototyping with a small team rather than full engineering release cycles to learn what works.
• Have engineers participate in discovery and prepare infrastructure instead of waiting idle or starting full builds too early.
• Help management accept discovery's uncertainty by framing it as the stage that determines whether the product gets built successfully.

02Key sections

The scheduled-design trap

A product manager is given a fixed four-week window to define a product, but user feedback and prototype testing reveal problems that never get fixed before engineering starts building.

Discovery as a creative process

Product invention is more art than science, so the author prefers 'product discovery' to 'requirements and design' to stress validating both the market and the solution.

Why discovery is hard and uncertain

Finding the market is usually easier than finding a workable solution, and the drug industry openly accepts uncertainty in discovery, which software teams rarely do.

Management's fears

Managers resist discovery because it is unpredictable and because idle engineers look wasteful, yet this instinct causes wasted engineering effort through multiple failed release cycles.

Faster discovery and engaging engineers

Use a small, fast discovery effort first, let engineers take part in discovery and prepare infrastructure, and build full-scale only once a usable, useful, feasible solution is found.

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.