Updated·Falk Gottlob··updated ·3 min read

The PRD Is Dead. Here's What Replaces It.

Product Requirements Documents were a necessary evil in a world where building was expensive. That world is gone.

opinionmethodology
Helpful?

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. 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...?"

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.

Build it.

Share this post

Keep Reading

Posts you might find interesting based on what you just read.