Craft
The Sections of a PRD, and Which Ones Earn Their Place
Five sections are irreducible, six are conditional, and six are usually inherited from a template rather than chosen. Each with the failure it prevents.
Most PRD templates carry somewhere between twelve and twenty headings, and a meaningful share of them are there because they were in the template somebody copied. Nobody chose them. They are inherited, and they get filled in dutifully with material that no reader will use.
Here is the version that earns its place: five sections that are always load-bearing, six that depend on the feature, and six that usually do not survive contact with a real reader.
Always
Problem and why now. Who is affected, how often, and what changed to make this the moment. The section most often written as a formality and the one that most determines whether the rest of the document is aimed at anything.
Absent: you build a well-specified solution to a problem nobody validated, and the review can only critique implementation detail because there is no stated goal to evaluate against.
Scope, in and out. What this includes and — explicitly — what it does not.
Absent: the scope argument happens after approval, during the build, when your leverage is gone and the request arrives framed as a gap rather than an addition.
Requirements with acceptance criteria. The behaviour, and the condition that decides whether it was met.
Absent: "done" becomes whatever the implementer decided, and QA writes cases against their own interpretation.
States and edge cases. Empty, loading, error, permission-denied, at-limit. Every screen has more states than the happy one.
Absent: the generic red toast, and a feature that works perfectly right up until it does not.
Success metric with a baseline. One number, where it is today, where you expect it to go.
Absent: the launch cannot be evaluated, so it gets declared a success by whoever is most invested in it having been one.
Those five are the irreducible spec. A document with only those, done well, beats a twenty-heading template with three of them thin.
Sometimes
These earn their place when there is something non-obvious to say, and not otherwise:
| Section | Include when |
|---|---|
| Dependencies | Anything is needed from another team, system or vendor |
| Rollout and phasing | There is more than one phase, or a rollback worth writing down |
| Non-functional requirements | There are real thresholds — a number, not an adjective |
| Entity or data model | The feature introduces or changes entities |
| Permissions | More than one role can reach it |
| Instrumentation | Measuring success requires an event you do not emit yet |
The judgment is the same in every row: include it when the answer is non-obvious, omit it when there is nothing to say. A rollout section reading "ship to everyone at once" is fine if that is a real decision someone might otherwise get wrong, and noise if nobody would have assumed anything else.
Usually not
Executive summary. Almost always a restatement of the TL;DR, two paragraphs later, for a reader who does not exist. If your TL;DR needs a summary, fix the TL;DR.
Background and history. How we got here is interesting and rarely changes what anyone builds. Link it.
Competitive analysis. Belongs to the decision about whether to build, which happened before this document. Keeping it in the spec is re-arguing an approved bet.
Personas. Unless the feature genuinely behaves differently per persona — in which case it is not a persona section, it is a permissions or requirements section. Most persona blocks exist to make the spec feel user-centred, and the concrete rule three paragraphs later is what actually is.
Appendix. Where material goes to be technically present and never read. If it matters, put it inline; if it does not, cut it.
Open questions. The interesting one, because it looks responsible. It is a list of decisions you have not made, presented as thoroughness — and every unanswered item will be answered during the sprint by whoever hits it first, under time pressure, with no review. Either decide them, or give each one a name and a date. An open question with an owner is a dependency. Without one, it is a gap wearing a heading.
Order matters more than the list
Most templates open with context, background and goals, then reach scope and requirements on page three. That ordering front-loads exactly the material engineers skip and buries the sections they re-read.
A sequence that matches how the document is actually used:
- TL;DR — what ships, for whom, why now. Three sentences.
- Problem — brief, evidenced.
- Scope — in and, explicitly, out.
- Requirements and acceptance criteria — the bulk.
- States and edge cases — attached to the requirements they belong to, not in an appendix.
- Success metric.
- Conditional sections.
The move that matters most is putting scope third rather than eighth. It is the section people most need early and most often find late.
One more ordering rule: attach edge cases to their requirement rather than collecting them. An "Edge cases" section at the end is where cases go to be skipped — the person implementing requirement four is reading requirement four, not scrolling to page nine.
The empty-section problem
A heading followed by N/A or TBD is worse than no heading.
Not because it wastes a line, but because of what it teaches. A reader who hits three empty headings learns that headings in this document are decoration, and starts skimming past all of them — including the two that were load-bearing. You cannot un-teach that within the same document.
Delete the heading. The template is a prompt, not a contract, and a Lean PRD with six real sections is a better artifact than a Standard with fourteen and half of them hollow.
Two tests
For any section you are unsure about:
If I deleted this, would someone have to make a decision I have already made?
Keep it if yes, regardless of length. This is the same test that decides how long a spec should be, applied at section granularity.
And the second, which catches the sections that pass the first on a technicality:
Has anyone ever re-read this section?
Requirements and criteria get returned to constantly. Background gets read once, if that. A section nobody returns to is either reference material that belongs elsewhere or a decision that should be stated more prominently.
Template sections are a starting prompt. Which ones survive is a decision, and it is yours to make once per document rather than inherited once and never revisited.
FAQ
What sections should a PRD have? Five always — problem and why now, scope, requirements with criteria, states and edge cases, metric with baseline. Six more conditionally.
Is "open questions" a good section? Rarely. It is undecided decisions presented as thoroughness. Give each a name and a date, or decide it.
Delete sections that don't apply? Yes. "N/A" teaches readers that headings are decoration.
What order? Decision-carrying sections early, and scope third rather than eighth.