How Long Should a PRD Be?

There is no page count, and any answer that gives you one is guessing about your feature.

The usable rule: a PRD is the right length when every section is a decision somebody would otherwise have to make during the sprint. Sections that carry a decision earn their space no matter how many they are. Sections that carry context, justification or reassurance do not.

In practice that lands around one to two pages for a small feature, three to six for something with real scope, and six to twelve for a migration or a platform change.

Why page limits fail as a rule

A limit does not remove decisions from a project. It removes them from the document.

The invite limit still has to be a number. The empty state still has to say something. Cut those sections to hit a page target and the decisions land in the sprint instead, made under time pressure by whoever reaches them first — which is the most expensive possible moment and the least reviewed.

Page limits also punish the wrong specs. A feature with nine states and two cross-team dependencies is long because it is long. Compressing it does not make it simpler, it makes it under-specified.

Count decisions, not words

The measure that works: how many decisions per page?

A two-page spec with twenty decisions in it is dense and probably excellent. A nine-page spec with six decisions is padded, and the padding is hiding how little was settled. Same document length tells you nothing; the ratio tells you everything.

Four reasons specs get long for nothing

Restating context the reader has. Three paragraphs of background for a team that has been in every meeting about this.

Justifying work that is already approved. The decision to build it was made before the spec existed. Re-arguing it is writing for a reader who is not there.

Describing the interface instead of specifying behaviour. "The user clicks the button in the top right, which opens a modal containing a form" is a screenshot rendered as prose. What is the rule?

Hedging. The most reliable one. A spec that is long because it is uncertain reads as thorough and is the opposite — every "we might want to consider" is a decision someone else now has to make.

Three reasons they get long for good ones

Many states. Each is a real requirement. Do not cut these to save space; they are the space.

Genuine edge cases. A feature touching billing or permissions has more of them, and every one you leave out is one QA finds in staging.

Cross-team dependencies. Each needs an owner, a date, and a fallback. That is three lines you cannot compress into zero.

If your spec is long for these reasons, it is not too long. It is accurately sized to a hard feature.

The cut test

Go section by section and ask one question:

If I deleted this, would someone have to make a decision I have already made?

If yes — keep it, regardless of length. If no, and deleting it only leaves the reader less informed about background, cut it or replace it with a link.

Most specs lose 20–30% to that pass without losing a single requirement.

Where the cut material goes

"Cut it" rarely means delete it. Most of what a spec should lose belongs somewhere else, and naming the destination is what makes the cut survive review:

• Background and market context → a one-pager, or the strategy doc that justified the work. It had a reader; that reader is not the person implementing.
• Why we decided this → a decision record. This is the material people most often keep in the spec out of fear it will be lost, and a log is where it is actually findable a year later.
• Interface description → the prototype. A paragraph describing a modal is a worse version of a screen somebody can click.
• Research findings → linked, not summarised. Three sentences of summary is enough; the reasoning belongs with the research.

Cut without a destination gets reversed at the next review, because someone reasonably points out that the information mattered. It did. It just did not belong there.

Length by type

Document	Typical	Why
One-pager	1 page	It exists to get a decision, not to specify
Lean PRD	1–2 pages	One team, simple flow, no phased rollout
Standard PRD	3–6 pages	Multiple states, some dependencies
Migration or platform	6–12 pages	The middle state is where the risk lives

These are observations, not targets. A five-page lean PRD is telling you the feature was not lean.

Too short is also a failure

Brevity is not automatically a virtue, and the symptom of over-compression is measurable: the same questions arrive at every handoff.

If engineering asks about error handling every single time, your specs are not concise — they are missing a section, and the answers are being supplied verbally, where nobody can find them later.

Track that. It is a better length metric than any page count, because it measures what the document failed to do rather than how much of it there is.

FAQ

How long should it be? Long enough that every section is a decision somebody would otherwise make mid-sprint. Roughly 1–2 pages small, 3–6 standard, 6–12 for migrations.

Should it be one page? Only if the feature fits. A limit relocates decisions into the sprint rather than deleting them.

What makes one too long? Restated context, justification of approved work, UI description instead of behaviour, and hedging.

Can it be too short? Yes — and you can measure it by the questions that arrive at every handoff.