Discovery vs. Documentation

Marty Cagan argues that during and after the pandemic, teams are sliding back into heavy requirements documents (PRDs) because remote collaboration is tiring. He reframes the core of strong product work as three things: addressing risks up front, solving problems collaboratively across product, design and engineering, and focusing on outcomes rather than output. A PRD addresses none of these, and when written in place of discovery it simply hands engineers unvalidated requirements. Documentation is fine once discovery has produced a solution worth building, and the same holds for feature roadmaps. Ultimately this is a product leadership responsibility, since abandoning discovery undermines continuous innovation.

01Key takeaways

• Document requirements only after discovery has validated the solution, not as a substitute for it.
• Check value, usability, feasibility and viability before engineers write production code.
• Treat detailed documentation as a necessary communication tax for remote teams, not a replacement for collaboration.
• Prototype and iterate with design and engineering continuously rather than handing off sequentially.
• Use outcome-based roadmaps that describe problems to solve instead of feature commitments.
• Recognize that formal PRDs create false certainty, so keep them open to challenge.

02Key sections

Why PRDs are resurging

Remote work made collaboration harder, and engineers fatigued by unclear requirements often ask for specifications instead. Cagan says this pressure predates the pandemic but has worsened.

The three things that matter

Strong product teams manage risk early, collaborate rather than hand off sequentially, and aim for outcomes instead of features.

Documentation after discovery, not instead of it

PRDs and roadmaps are acceptable communication tools when they reflect validated discovery work. Problems arise when they replace discovery, producing commitments unlikely to deliver results.

Why PRDs magnify the problem

Unlike user stories, which act as placeholders for conversation, a formal PRD carries an authority that discourages challenge, even when the author lacks evidence.

A leadership responsibility

Product leaders must decide how much they value continuous innovation and protect discovery time accordingly; otherwise the organization effectively gives up on innovation.

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.