Craft
When a PRD Is the Wrong Document
Five situations where writing a spec delays the real question. The tell is what you are trying to get — approval, a decision, and a correct build differ.
A PRD is for making a build correct. It is a poor instrument for almost everything else, and reaching for it by default is one of the more expensive habits in the job — not because the document is bad, but because writing one takes a week and often answers a question nobody asked.
Five cases where it is the wrong artifact.
1 · The decision has not been made
You are not specifying, you are proposing. Nobody has agreed this is worth doing, and the document you are writing is trying to secure that agreement by demonstrating thoroughness.
It will not work, and it costs a week. A reader deciding whether wants the problem, the evidence, the cost, and the ask — not acceptance criteria for a thing they have not approved.
Write instead: a one-pager. If it gets a yes, the PRD picks up from there with the benefit of a decision already made.
2 · The work is a chore or a bug
A rename. A dependency bump. A broken validation. Work where the implementation is obvious and there are no user-visible decisions to settle.
Specifying it does not make it safer. It makes it slower and teaches the team that specs are paperwork, which is the belief you least want them to hold when a spec genuinely matters.
Write instead: a ticket with a clear description of the expected behaviour.
3 · The problem is still unknown
The most consequential one. You have a hunch and a request from a customer, and the honest state is that you do not yet know what is wrong.
A PRD written here manufactures precision. It will specify a solution — in detail, with criteria — to a problem nobody has validated, and the specificity of the document will be read as confidence about the diagnosis.
Write instead: a research plan. The output you need is what is actually happening, not what we will build about it.
4 · The open question is technical approach
Everyone agrees on what the product should do. The disagreement is about how to build it — queue or cron, rewrite or patch, which service owns the data.
A PRD cannot settle that and should not try. Writing the how into a product spec is the most reliable way to have your document read with suspicion.
Write instead: an RFC or design doc, owned by engineering. The PRD constrains what must be true; the RFC chooses among the ways to achieve it.
5 · It is a policy, not a feature
"Trials now last 14 days." "We do not offer refunds after 60 days." "Enterprise accounts require SSO."
These are rules. They have implementation consequences, but the artifact you need is the rule and its reasoning, not a specification of the screens.
Write instead: a decision record. The rule plus why, plus what was rejected, plus what would change it — which is exactly what someone will need in a year and exactly what a PRD does not preserve.
The tell
One question resolves most cases:
What am I trying to get?
| You want | Write |
|---|---|
| A decision | One-pager |
| The work done, no decisions in it | Ticket |
| To understand the problem | Research plan |
| Agreement on technical approach | RFC / design doc |
| A rule remembered | Decision record |
| A correct build of an agreed thing | PRD |
Only the last row is a spec. If you are in any of the others and writing a PRD anyway, the document is doing a job it is not shaped for, and it is doing it slowly.
What it costs to write one anyway
It delays the real question. A week spent specifying is a week the actual decision — should we, what is wrong, which approach — goes unmade.
It manufactures false precision. Detail reads as confidence. A PRD full of acceptance criteria for an unvalidated problem looks more certain than the situation warrants, and reviewers calibrate to the document rather than the evidence.
It spends reviewer attention on the wrong thing. You get careful feedback on your edge cases and none on whether the feature should exist, because you handed people a document whose implicit question was "is this specified well?"
The case that catches everyone
Writing to think.
This is legitimate and worth defending — putting a thing in sentences is one of the better ways to discover you do not understand it, and many good PRDs start as a draft the author wrote to find out what they believed.
The failure is not writing it. It is circulating it. A document written to clarify your own thinking has not finished doing its job when you send it out, and everyone who reviews it spends their attention resolving a question you had not resolved yet.
Write the draft. Then decide what it turned out to be — which is sometimes a PRD, and is quite often a one-pager wearing twelve headings.
When it genuinely is a PRD
To be clear about the positive case, because the default is not always wrong:
The decision to build is made. The problem is understood well enough to state. The work contains real decisions — states, limits, permissions, edge cases — that somebody would otherwise make under time pressure mid-sprint. More than one person has to act on it.
That is the shape a PRD fits. It is a narrower set of situations than the frequency with which PRDs get written, and noticing the difference is worth more than any improvement to how you write them.
FAQ
When should I not write a PRD? When the decision is unmade, the work is a chore, the problem is unknown, the question is technical approach, or you are recording a policy.
What instead? One-pager, ticket, research plan, RFC, or decision record — matched to what you are trying to get.
Is writing one to think a waste? No. Circulating it before the thinking is done is.
Do small features need one? Only if they contain decisions somebody would otherwise make in the sprint.