The PRD is dead. Not the concept — the concept of capturing product intent in writing is as valuable as it's ever been. What's dead is the format: the 20-page document that nobody reads, that's out of date before it's finished, and that creates the illusion of alignment without actually producing it.
Here's the format I've landed on after ten years of specs that ranged from genuinely useful to catastrophically misleading.
The Working Document
I don't write PRDs. I maintain working documents. The difference is philosophical but consequential.
A PRD is a finished artifact. It implies that thinking is complete, requirements are locked, and the team's job is now to execute what's been specified. This is almost never true, and the pretense that it is creates friction.
A working document is a living record of current thinking. It captures decisions and their rationale, open questions and their owners, and assumptions that are still being tested. It's the PM's public working memory — available to the team, updated as things change.
What Goes In
My working documents have five sections, always in this order:
- The problem — who has it, how bad is it, why now
- The bet — what we're building and why we think it'll work
- What success looks like — specific, measurable, with a timeframe
- Open questions — what we don't know yet and how we'll find out
- Decisions log — what we've decided and why, with dates
That's it. No user stories. No acceptance criteria (those live in tickets). No feature lists masquerading as strategy.
A spec that answers "what are we building?" without answering "why does this matter?" is a work plan, not a product document.
Length
If it's longer than two pages, it's not a spec — it's a report. Reports get filed. Specs get read.
Ruthless editing is a core PM skill. If you can't explain the problem, the bet, and the success criteria in under 500 words, you don't understand them well enough yet.
Who Reads It
The working document is written for three audiences, in order of importance:
- Your future self — the you who will need to explain a decision in six months
- Your engineering and design partners — who need context, not just instructions
- Your stakeholders — who need confidence, not comprehensiveness
Write for reader one. Make it scannable for reader three.