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 (1)
Sign in with LinkedIn to leave a comment.
Sign in with LinkedInArtem Ermakov
19d ago
The PRD was doing three jobs - alignment, commitment, memory. The prototype nails the first and quietly drops the other two. Which is why I don't think it's a clean replacement, even though I agree with most of this. I'm with you on the diagnosis. The 12-page PRD two engineers skim and nobody reopens is dead, and a prototype aligns a team faster than any spec. You're also right that the fixed format was the atavism - I've shipped a SQL query as the spec, or a detailed Figma mock, when that was the clearest way to state the thing. But here's what those examples taught me: the SQL or the mock was never the spec on its own. Without the text around it - why this, what it must never do, what we chose not to build - it's just a query, or a set of screens. The artifact shows what. The text carries why. And the "why" is the part a prototype can't hold. The prototype is genuinely better at alignment. It drops the other two, and those are the text. Commitment: an obligation with regulatory, contractual or SLA weight needs a fixed, versioned, readable thing to commit to. A prototype has no version and no signature - it changes every time you touch it. You can't commit a counterparty to something that keeps moving. Memory: anyone who's picked up a system built by people who've since left knows the failure. Two years on the question is never "what does it do" - the code answers that. It's "why does it behave this way, and what did someone deliberately decide not to do." A prototype shows what exists and carries no trace of intent. This gets sharpest in a ledger FX conversion, where the commitment is regulatory and there's nothing to click - but it's true of any product that outlives its alignment moment. The cost of building the wrong thing dropped to an afternoon, you're right. The cost of a wrong commitment, and the cost of forgetting, didn't move.