Product Requirements Document Template
Every PRD template gives you an outline. This one gives you a requirement register where priority means something and every line names its evidence.
Free download · No account needed
A PRD outline is easy to fill in and easy to argue with later. The arguments always land in the same three places. Nobody can tell which requirements are genuinely required, because P0 and P1 have no agreed meaning and everything becomes P0 by week three. Nobody can tell which requirements came from evidence and which came from a preference somebody held strongly in a meeting. And the questions that were still open at review get discovered again, halfway through the sprint, by an engineer.
This pack replaces the outline with a register. Priority uses the requirement keywords from RFC 2119, so MUST is an absolute requirement and SHOULD grants latitude that has to be weighed rather than assumed. Every row carries an acceptance criterion written as something observable, not as "works correctly". Every row cites the Evidence Map entry that justified it, and the space rule forbids filling that cell when nothing exists to point at, so a preference stays visible as a preference.
The unresolved parts get the same treatment. Open Questions carries every unanswered question with an owner, a needed-by date, and the requirements it blocks, so a question blocking a MUST means the spec is not ready for review rather than meaning nothing. The Decision Log records every answer that changed the spec, which is what stops a requirement looking arbitrary six months later when the person who decided it has moved teams.
What you get
Requirement Register
One row per requirement with a keyword that has a published definition, an acceptance criterion written as an observable outcome, the evidence behind it, and whichever open question is blocking it.
Evidence Map
What you actually know, one row per source, with the number in it and a strength rating. Ticket volumes, analytics figures, interview counts, security reviews. Evidence that ends up justifying nothing stays in the sheet saying so.
Requirement Language
The vocabulary, defined once. What MUST commits you to at ship time, how much latitude SHOULD really grants, and why the keywords are uppercase. Rename it to your team's own words in the first session, or read what belongs in a PRD first.
Open Questions
Every unanswered question with an owner, a needed-by date, and the requirements it blocks. A question blocking a MUST is reported as making the spec unready, rather than sitting in a bullet list nobody reads.
Decision Log
Every answer that changed the spec, with who decided and which requirements moved. This is what a requirement that looks arbitrary next quarter points at.
Non-Goals that hold
A guide and a prompt for the section most templates fill with things nobody was going to build. Each non-goal gets a reason and the trigger that would reverse it.
How it works
- 1
Send what you know
Research findings, support tickets, analytics, churn interviews, the constraints engineering flagged, a half-written doc. River fills the Evidence Map before writing a single requirement.
- 2
Get the register
Every requirement gets a keyword, a testable acceptance criterion and its evidence cited both ways. Anything that cannot be resolved becomes an open question with an owner instead of a guess.
- 3
Find the non-goals
River proposes the things a reader would assume are included and are not, each with a reason and the trigger that would change it.
- 4
Audit before review
The spec check reports unevidenced MUSTs, untestable criteria, one-way evidence links and any question blocking a MUST, then gives you a verdict.
Frequently asked questions
Why MUST and SHOULD instead of P0, P1 and P2?
Because the numbered labels have no published definition, so they mean different things in different teams and collapse into all-P0 under pressure. RFC 2119 defines MUST as "an absolute requirement" and SHOULD as meaning "valid reasons in particular circumstances" may justify ignoring it, provided the implications are weighed first. That tells an engineer their latitude.
Why are the keywords always uppercase?
Because only uppercase carries the defined meaning. RFC 8174 updates RFC 2119 specifically to clarify that point. It matters practically: a PRD is full of ordinary sentences containing the word should, and a reader has to be able to tell a requirement from a sentence without guessing.
How is this different from your PRD writing tool?
The PRD tool writes a document from a brief in one pass. This is a working space with four linked sheets that stays alive through build, tracking evidence and decisions. Use the tool for a first draft, this pack once the spec has to survive a sprint. The user story writer turns it into stories; the non-functional requirements template catches what a story never shows.
What counts as a testable acceptance criterion?
Something a person or a test can observe. "Returns the expired state on day 31 and does not render content" is testable; "link expiry works correctly" is not. If your team writes them as scenarios, the Gherkin reference is a good structure to borrow. Where none can be written, the cell stays blank and the check reports it.
What if a requirement has no evidence?
It ships with an empty evidence cell and River tells you which ones they are. The space rule forbids inventing a justification. Unevidenced requirements are legitimate, since a product lead's judgement is often right and undocumented, but the register makes them visible so nobody mistakes a preference for a finding.
Does this decide what to build?
No. This space assumes the bet is made and answers whether the spec can be built from. Sequencing initiatives and checking a quarter against real delivery capacity is a different job, handled by the roadmap pack. Requirements here read effort estimates from your team rather than producing them.
Can I keep my own priority labels?
Yes. The first prompt asks, and if your labels have written definitions somewhere it keeps them and rewrites the vocabulary doc around them. The failure this space cares about is not the wrong words, it is words with no agreed meaning. The guide to writing a PRD covers the wider document if you want the reasoning first.
Write the spec that survives the sprint
Send your research, tickets and constraints. River builds the register, cites the evidence, and tells you which questions make it unready.
Write my spec