The Origin of Product Discovery

Marty Cagan explains where the term "product discovery" came from and why he chose it. He argues that software has always faced two core problems: figuring out the right product, and then building it right, which he calls discovery and delivery. In 2007, while writing the first edition of INSPIRED, he adopted "discovery" to replace the common language of gathering and defining requirements, which he saw as a root cause of failed products. He borrowed the word from pharmaceuticals, an industry that openly accepts most candidates will fail, and valued that the term is technique-agnostic and frames value, usability, feasibility and viability risks. The essay matters because it clarifies the shared vocabulary many product teams now use and signals a shift from handing teams roadmaps to empowering them to discover.

01Key takeaways

• Treat the problem of choosing what to build as distinct from, and often harder than, building it well.
• Replace requirement-dictation language with framing that invites shared problem-solving across disciplines.
• Accept up front that many ideas will fail, as pharmaceutical discovery does, and plan for learning from them.
• Prefer method-agnostic concepts so your team is not locked into one technique that may fade.
• Check discovery work against value, usability, feasibility and viability risks before committing to build.
• Give teams the authority to discover solutions instead of handing them fixed feature roadmaps.

02Key sections

Two essential problems in software

Cagan frames software work as two problems: finding the right product and building the product right. He considers discovery the harder problem where most innovation happens.

Why the term was chosen

In 2007 he rejected the prevailing language of requirements because it implied arrogance and a push-down model. He wanted a term that encouraged humility and collaboration across product, design and engineering.

Borrowing from pharmaceuticals

The drug industry openly accepts high failure rates during discovery, a candor he found missing in software. This framing made uncertainty an expected part of the process.

Technique-agnostic by design

Cagan chose discovery because it does not tie teams to any single method like MVP, design thinking, or Jobs To Be Done, since methods come and go.

Current focus

Now that the concept is widely understood, his attention has shifted to creating environments where teams are empowered to do discovery rather than simply given roadmaps to build.

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.