The one-page PRD: when less is more

The PRD got a bad reputation for a reason: too many were thirty-page documents that took a week to write and that engineering skimmed once. The reaction — "PRDs are dead" — overcorrected. The document isn't the problem; the length was. For most features, the right PRD fits on a page.

Why one page helps

A constraint forces clarity. When you only have a page, you can't hide a fuzzy problem statement behind volume. You have to name the problem in a sentence, the users in a line, and the handful of requirements that actually matter. The discipline of fitting it on a page is the value — it surfaces whether you actually understand the feature.

What goes on the page

• Problem — one or two sentences.
• Users — who, specifically.
• Success metric — one measurable target.
• Requirements — the 3–5 that matter, as short user stories.
• Scope — a line on what's out.
• Open questions — the things still unresolved.

That's a complete thought for most features, and a team with shared context can build from it.

When you genuinely need more

Length should track complexity and risk, not habit. Reach for a fuller document when: the feature touches a regulated domain where compliance or legal will read the PRD directly; many stakeholders across functions need detail to do their own work; the cost of getting it wrong is high (payments, medical, security); or the feature is genuinely large and a page can't hold the necessary requirements without becoming a list of vague gestures.

The skill isn't "always short" or "always thorough" — it's matching the document to the decision. A one-pager for a settings toggle and a detailed spec for a billing change are both correct.