The Product Discovery Plan

Cagan argues that teams who genuinely value product discovery still waste time when they lack a plan, so they should write a Product Discovery Plan spelling out who is involved, what must be done, what resources are needed, and a rough timeline. He stresses using the components as a toolkit rather than a fixed template, selecting only what each project needs. He then describes two layers of oversight: leaders actively probing progress with weekly questions about customer contact, learning, pivots and feasibility, and project management ensuring the plan is executed and implementation-ready. The core goal throughout is converging quickly on a minimum viable product rather than merely documenting requirements.

01Key takeaways

• Write a discovery plan naming the core team, extended helpers, and stakeholders with veto power.
• Choose only the plan components a given project needs instead of filling out every section of a template.
• Define who you will talk to and how you will test ideas with real users, and when.
• Review progress weekly by asking what customers you spoke with and what surprised you.
• Involve the engineer early and often to surface feasibility concerns and alternative solutions.
• Set a checkpoint on whether MVP is reachable within a couple of weeks, and be willing to drop the effort if not.

02Key sections

The problem of unplanned discovery

Teams that believe in discovery can still waste time without a plan to maximize learning and progress toward a minimum viable product. The article contrasts this with the earlier failure mode where discovery is just last-minute spec writing.

Components of a discovery plan

The plan covers core and extended team members, key stakeholders, customer development, risks, research and testing, strategy, principles, and documentation levels. Each item is a tool to select deliberately rather than a template to fill in mechanically.

Leadership oversight through weekly questions

Product leaders should regularly ask the team what customers they spoke with, what they learned, whether pivots are needed, how engineering is involved, and whether MVP is achievable soon. These questions keep the focus on real progress.

Project management and execution

Separate project management ensures engineering has what it needs, timing is managed, and communication flows among product, design and engineering. It should keep the goal on finding the MVP rather than just producing documentation.

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.