The short version
I wrote my last PRD six months ago. Twelve pages, three days of work, two engineers read it. PRDs made sense when building took three months and cost a ton. Building isn't expensive anymore. A PM with AI can prototype in an hour, as I describe in Instant Prototyping. The cost of being wrong dropped from three months of engineering to one afternoon. What replaces the PRD: a working prototype, a one-page strategic context document, a 5-minute Loom recording, and a 30-minute conversation with engineering. Complex features need more prototyping, not more documentation. If it's too complex to prototype, it's too complex to build. Build it.
I wrote my last PRD six months ago. Twelve pages. Three days of work. Two engineers read it. One asked me to "just show me what you mean." So I built a working prototype in 45 minutes and showed them.
They shipped it in a week. Based on the prototype, not the document.
That's when I got it: the document was never the point. Alignment was. And a prototype that people can click through aligns teams 100x faster than a spec they have to read and interpret.
Why PRDs existed
PRDs made sense when building took forever and cost a ton. If shipping something takes three months, you better be sure it's right before you start. The PRD was a contract: "we agreed to this, and here's why it matters."
Building isn't expensive anymore. A PM with AI can prototype in an hour. The cost of being wrong dropped from "three months of engineering" to "one afternoon of my time."
When being wrong is cheap, you don't need insurance against being wrong. You just need to fail faster.
What replaces the PRD
The prototype. Something you can click. Something that actually works. No ambiguity. No interpretation gaps. No "wait, did you mean...?" Running a product trio means PM, designer, and engineer build it together so there is no interpretation gap in the first place.
The one-pager. Strategic context: why we're building this, who uses it, how we measure success. One page. One page forces you to be clear. Twelve pages is where ideas go to hide.
The recording. Five-minute Loom walking through the prototype. Stakeholders watch at 2x and actually get it. Try that with a 12-page PRD.
The conversation. Sit with engineering. Show the prototype. 30-minute talk about what's feasible, what's hard, the approach. Write down decisions in three bullets. Done.
But what about complex features?
"Simple features don't need PRDs, complex ones do." I hear that constantly. Wrong.
Complex features need more prototyping, not more documentation. If it's too complex to prototype, it's too complex to build. No amount of pages changes that. Break it into smaller pieces until each one can be prototyped and tested independently.
The worst features I've seen shipped had the most detailed PRDs. The document became a shield: "we specified this exactly!" Yeah. You specified the wrong thing exactly.
Making the transition
If your org still requires PRDs, don't go cold turkey. Build prototypes alongside the PRD. When people keep saying the prototype is more useful than the document (they will), push to drop the PRD next time.
One PM building prototypes makes people curious. Three PMs doing it creates momentum. A whole team building prototypes becomes the culture.
PRDs had their moment. But when you can build it faster than describe it, the description is just overhead. For the assumption testing practice that makes fast prototyping safe, see the handbook.
Build it.
Frequently asked
Why is the PRD dead?+
PRDs made sense when building took three months and being wrong was expensive. A PM with AI can now prototype in an hour. The cost of being wrong dropped from three months of engineering to one afternoon. When being wrong is cheap, you don't need insurance against being wrong. You need to fail faster.
What replaces the PRD?+
Four things. A working prototype that people can actually click through. A one-pager with strategic context: why you are building this, who uses it, how you measure success. A five-minute Loom walkthrough. And a 30-minute conversation with engineering where you show the prototype and write down decisions in three bullets.
What about complex features that seem too hard to prototype?+
Complex features need more prototyping, not more documentation. If it is too complex to prototype, it is too complex to build. Break it into smaller pieces until each one can be prototyped and tested independently. The worst features I have seen shipped had the most detailed PRDs. The document became a shield for specifying the wrong thing exactly.
My org still requires PRDs. What do I do?+
Don't go cold turkey. Build prototypes alongside the PRD. When people keep saying the prototype is more useful than the document (they will), push to drop the PRD next time. One PM building prototypes makes people curious. Three PMs doing it creates momentum. A whole team building prototypes becomes the culture.
How long did the author's last PRD take and who read it?+
Twelve pages, three days of work, two engineers read it. One asked to just be shown what it meant. A working prototype built in 45 minutes then drove the entire engineering implementation. The document was never the point. Alignment was.
Comments (0)
Sign in with LinkedIn to leave a comment.
Sign in with LinkedIn