How I Write a PRD Now

My best PRD was forty-one pages long. I remember the number because I was proud of it.

It had a glossary. It had an appendix with three wireframe variants. It had a section titled "Non-Functional Requirements" that I had copied, structurally, from a template a consultant left behind in 2011. It took me nine days to write. In the steering committee, someone asked a question that was answered on page fourteen. Nobody, including me, could find page fourteen fast enough. We talked around it for twenty minutes and moved on.

That was the moment, though it took me a few more years to admit it: the document wasn't the point. It had never been the point.

What a PRD is actually for

Here's the trap. We're taught that a product requirements document exists to describe what to build, so engineers can build it. So we optimize for completeness. Every edge case, every field validation, every state. And then a strange thing happens — the more complete it gets, the less anyone reads it, and the less it changes what actually ships.

The PRDs that changed things, in my experience, weren't the complete ones. They were the ones that made a decision visible.

A PRD isn't a document. It's the record of a decision — and most of mine recorded nothing.

That reframing changed everything about how I write. If the PRD is where a decision gets recorded, then its job is to show: what problem we chose to solve, what we chose not to solve, what we'd accept as proof that we were wrong. Everything else is furniture.

The four sections that survived

I've thrown out most of what I used to write. Four things stayed, and they map to four questions I now can't ship without answering.

The problem, with no solution in it

Try writing your problem statement without naming your feature. It's harder than it sounds — most of what we call problems are solutions in disguise. "Users need a dashboard" is not a problem. "Team leads can't tell which of their 34 daily notifications matter, so they've stopped reading all of them" is a problem. If you can't state it without the fix, you don't understand it yet.

The evidence

Every claim in the problem statement needs a source: an interview, a number, a support ticket. I now write the evidence in the document, next to the claim. Half the time, doing this kills the project — I discover the "problem" rests on one loud customer and a hunch. That's the section doing its job.

What's out of scope

This is the section that separates a senior PRD from a junior one, and almost nobody writes it. Listing what v1 will not do is how you protect it from dying under the weight of everyone's good ideas. I now also list the three requests I predict I'll have to refuse — so that when they arrive in the meeting, I've already thought about my answer instead of improvising a yes.

The kill criterion

What result would make us stop? Decided in advance, in writing, before anyone is emotionally invested. This is the only sentence in the entire document that costs you something to write, which is exactly why it's the most valuable one in it.

Notice what's missing: the wireframes, the glossary, the exhaustive requirements table. Those things aren't useless — they're just not the PRD. They're attachments. The confusion between the two is what produced my forty-one pages.

Where AI changed the math

For most of my career, writing a PRD was expensive. That expense was doing something useful, even if we never admitted it: it forced you to think, because you had to sit there and produce the sentences.

That expense is gone. An AI drafts a coherent PRD in four minutes from a pile of messy notes. Which sounds like the end of the problem, and is actually the beginning of a new one — because the AI will happily produce a beautifully structured document about a problem you never validated. It doesn't know your evidence is thin. It won't tell you your idea is bad. It fills the shape you give it, confidently, and confident nonsense is worse than an empty page. An empty page, at least, makes you nervous.

So I changed how I use it. The AI drafts each section — that part is free now. Then I run a second prompt on my own draft, and the second prompt is the whole game: act as a skeptical senior PM, attack this document, find the fragile assumptions, the missed edge cases, the vanity metrics, rank them by severity, be harsh.

The first time I ran that on a PRD I was proud of, it found four things. Two of them were real. One of them would have cost us a quarter.

Drafting got cheap. Judgment got expensive. Most people have only noticed the first half.

What I'd tell myself, fifteen years ago

Stop measuring your PRD by its length. Measure it by whether a smart colleague could read it in six minutes and tell you what you decided, what you refused, and how you'd know if you were wrong.

If they can, the document is done. It doesn't matter that it's two pages. It never mattered.

Everything I've described here — the four sections, the draft prompt, the attack prompt — lives in a Notion system I built for myself and eventually cleaned up for other people. It comes with a PRD that's already written, so you can see what "done" looks like before you stare at your own blank page. Because the blank page was never the hard part either.