Product Requirements Document Template

Most PRDs share one skeleton. Keep each part short, and link to research and designs instead of pasting them in.

Describe the problem before any requirement, in numbers: who hits it, how often, and what it costs. NASA's checklist for writing requirements says each one should state the problem, not the solution¹. When one reads like a design, NASA suggests asking "Why do you need the requirement?", since the answer may point to the real one.

List the evidence one item per line, each with a source and a number: a ticket count, an analytics figure, an interview tally. If it's mostly interviews, turn the transcripts into counted findings first.

Rate each item: measurements and direct accounts from affected users are strong, small samples are moderate, and what competitors ship is only context. A requirement with no evidence is a preference; keep it if you believe in it, but label it as one.

Then decide how you'll know it worked. In a 2010 paper, three Google researchers lay out a process that moves from goals to signals to metrics². Name the goal, find the behavior or attitude that would show it, and turn that into a number you can track.

Raw counts rise as a user base grows, the researchers note, so ratios or averages per user are often more useful. Record today's baseline before you build, so the release notes can quote the before and after once the feature ships.

Priority tells engineers how much room they have when a requirement proves expensive. Labels like P0, P1 and P2 have no standard definition, so teams read them differently. The keywords in RFC 2119³, a 1997 memo on requirement levels for internet standards, have fixed meanings.

Put the keywords in capitals. RFC 8174⁴, a 2017 update, says they carry these meanings only in all capitals; in lowercase they are ordinary English. That separates a requirement from a sentence that just says "should."

Use MUST sparingly. RFC 2119 itself says the keywords "must be used with care and sparingly," and a spec where every line is MUST leaves engineers nothing to trade when time runs short.

Each requirement needs an acceptance criterion: the observable result that shows it's met. NASA's checklist asks whether you can show a requirement is met by test, demonstration, inspection or analysis. It also lists terms that make a requirement unverifiable¹, including easy, user-friendly, fast, adequate and quickly.

Replace each vague word with a number or a state someone can see. "Search is fast" becomes "results appear within 2 seconds for 95% of searches." If you can't write a check, leave the cell blank and flag it. A blank is honest; "works as expected" hides the gap.

If your team writes acceptance tests as scenarios, the Agile Alliance's Given-When-Then template⁵ gives the shape: some context, an action, then "a particular set of observable consequences."

Non-goals head off scope arguments, but only if they name things a reader would expect. Malte Ubl, a former engineering director at Google, defines non-goals in design docs as things that could reasonably be goals⁶ but are explicitly chosen not to be. A negated goal like "The system shouldn't crash" doesn't count. Look in four places:

• The adjacent scope: the obvious next step, such as one link for several boards
• The other audience: a role or platform this release doesn't serve
• The unnamed quality: scale, speed, offline use, languages or accessibility
• The deliberate shortcut: a manual step behind a feature that looks automated

Give each one a reason and the condition that would reopen it: "Guest editing is out of scope. Churned customers wanted to show work to clients, not let them change it. Revisit if commenting ships and requests turn to editing." Without a reason, a non-goal gets reargued in every review.

Keep promises out of this section. "Coming in Q3" is a commitment, and it belongs on the roadmap, where someone will track it.

Write down every unknown with an owner, the date an answer is needed, and the requirements it blocks. NASA's checklist asks much the same of an unsettled value: use a best estimate, mark it "To Be Resolved," and record who will settle it and by when¹.

A question that blocks a MUST means the spec isn't ready for review. Marty Cagan, founder of the Silicon Valley Product Group, wrote in 2006 that when hard questions go unresolved, the team is forced to tackle these issues⁷ during engineering. Then the spec churns, or engineers fill the gaps with assumptions.

When a question is answered, update every requirement it blocked and add a line to the decision log: what changed, who decided and when. Months later, that line explains why the requirement exists.

For a quick first draft, the PRD generator writes one from a few lines about the feature. Once the requirements are agreed, the user story tool breaks them into stories with testable acceptance criteria.