Template PRD (Product Requirements)

PRD: anatomy of a Product Requirements Document

A PRD — Product Requirements Document — answers three questions before a single line of code is written: what are we building, why does it matter, and for whom. It is the contract between product, engineering, design, marketing and legal, and it lives as a single source of truth that everyone can link to. The format crystallized at Microsoft in the 1980s engineering culture and was refined into modern product practice by Marty Cagan in Inspired and writers like John Cutler at Amplitude and Reforge.

A solid PRD typically contains: problem statement (the user pain you are solving), goals and non-goals (what is in scope and explicitly out), user personas, use cases / user stories, functional requirements split into must-have and nice-to-have, success metrics / KPIs, timeline, dependencies on other teams or systems, and a list of open questions. Modern variants trim the format: the one-pager PRD popularized by Reforge, the lean PRD, Amazon's six-pager (no slides — narrative prose read silently at the start of the meeting), and Facebook's engineering RFC style.

Prioritization frameworks PMs pair with the PRD

Three frameworks routinely show up next to a PRD. Jobs-to-be-Done (Clayton Christensen) reframes features as the "job" the user is hiring the product to do — useful for filling the problem section. RICE (Reach, Impact, Confidence, Effort) gives a numeric score for each requirement so the must-have list does not balloon. KANO classifies features into must-have (basic expectations), performance (linear value) and delighters (asymmetric upside) — directly informs the must-have vs nice-to-have split.

Anti-patterns to avoid

PRDs fail when they are too long (engineers skip anything past five pages), too prescriptive (specifying how to implement instead of what to achieve, robbing engineering of design autonomy), or missing a clear problem statement (jumping straight to a solution). The other classic failure is shipping without success metrics — without a KPI you cannot tell whether the feature worked, only that it shipped.

Where the PRD sits in the workflow

A typical loop: PRD → engineering review → design specs → tickets in Jira/Linear → implementation → A/B test → analyze metrics → iterate. The PRD is a living document — update it as you learn during development. Common tools: Notion (rich templates and database views), Confluence, Productboard, Aha! and ProductPlan for roadmaps, and Linear for specs that live close to the engineering work.

FAQ

What is the ideal length? One to five pages. FAANG-scale PRDs sometimes go longer; Y Combinator startups keep them short on purpose. If the doc feels long, split into a one-pager + appendix.

Which tool should I use? Notion and Confluence dominate. Productboard and Aha! add roadmap integration. Pick the tool your engineers already read — a beautiful PRD nobody opens has zero value.

Is a PRD mandatory at a startup? A heavyweight PRD is not, but even a one-page version pays for itself: it forces you to articulate the problem, the audience and the success metric before burning engineering time. Skip the formality, not the discipline.

Who signs off on a PRD? The PM owns it; engineering and design review it; for major features an executive sponsor signs off. Treat sign-off as alignment, not bureaucracy — the goal is shared understanding, not a paper trail.