The PRD Template: Writing Product Requirements That Work

Nine people approved a six-page PRD in forty-five minutes, and nobody disagreed with a single word of it. That was the problem. A PRD is not a description of the product — it is the record of the decisions that were made and the ones deliberately deferred. Here's the test that separates the lines that decide something from the lines that describe something, and what the document looks like when only the deciding lines survive.

Most advice about product requirements documents is advice about sections — a TL;DR, personas, success criteria, scope, open questions. Every template agrees on roughly the same list, which is a good sign that the list is not where teams go wrong.

Teams go wrong one level down, at the sentence. A PRD written in the declarative present — the system will support bulk upload, the experience will feel fast and reliable — reads like a document, passes like a document, and decides nothing. A description cannot be wrong until the thing exists; a decision can be wrong the moment it is written, which is exactly why it is worth writing down.

The document everyone approved

Here is the test, and it takes about twenty minutes on a PRD you already have.

Read each sentence and ask: could a competent, well-intentioned colleague disagree with this? Not "is it true" — could someone in the building hold the opposite position and still be reasonable?

"We want to make onboarding delightful for HR administrators." Nobody could oppose that; no one on the project is assigned to make onboarding tedious. The sentence has no opposite, so it settled nothing, so it was free to write and free to approve. Free is the diagnostic. Every line in a PRD that cost nothing to write will also do nothing when it is read.

"Import must not hold a write transaction on the employee tables for longer than five seconds, because payroll ledger writes hit the same tables between 06:00 and 09:00 ET and cannot be blocked." A DBA could say the window is really seven seconds. An engineer could argue the ledger should move instead. That sentence has an opposite, and having an opposite is what makes it a decision rather than an atmosphere.

Silence in a PRD review is usually read as agreement. More often it signals that the document contained nothing to agree or disagree with — the same dynamic that turns a signature into sign-off theater.

Run this on your current PRD: count the sentences that have an opposite. Divide by total sentences. Most PRDs land under twenty percent, and the reviewers spent their forty-five minutes on the other eighty.

One fork, walked

The following is a composite drawn from patterns common in HR-tech and payroll onboarding work. The names, dates, counts, and figures are illustrative, not measured.

A mid-market payroll company — call the product Harbor — wrote a PRD for bulk employee import. New customers were onboarding by typing employees in one at a time; the ask was to let an admin upload a spreadsheet.

Six pages, eleven sections, approved in a forty-five minute review by nine people. Two lines in it mattered, and they mattered in opposite directions.

The line that changed what got built sat in Constraints, not in Requirements:

Import must not hold a write transaction on the employees or employee_comp tables for longer than 5 seconds. Payroll ledger writes contend for the same tables during the 06:00–09:00 ET run window and cannot be blocked. Owner: Platform lead.

That sentence has a number, a condition, and a name — the same shape any non-functional requirement needs to survive. The architect read it before design started and discarded the obvious implementation: parse the file, open a transaction, insert 900 rows, commit. Instead the team built a staged importer — upload lands in a holding table, a worker drains it in batches, and the file carries one idempotency key so a retry cannot double-insert. That design cost about a week more up front, and it existed because of one sentence someone could have argued with.

The line that was decoration sat at the top, in Goals:

Make onboarding delightful for HR administrators, reducing friction so teams can get up and running quickly.

It appeared in the deck, the kickoff, and the release note, and never once determined an outcome. No engineer resolved a question by consulting it, because it had no edges to resolve anything against.

Now the fork. In week nine, a VP of Customer Success asked for something small-sounding: when a file has four bad rows out of nine hundred, let the admin fix those four and re-upload just them. Row-level partial import.

The PRD had an answer. Under Out of scope, in full:

— Partial / row-level import (post-v1)

Six words, no reasoning. Nobody could reconstruct why it had been excluded, and a decision nobody can reconstruct is not a decision — it is a rumor with a bullet point in front of it. The discussion reopened across three meetings and eleven days, ended in a reversal, and the reversal collided with the staged importer's one-key-per-file idempotency model. Row-level retry needed per-row keys and a reconciliation view the design had no place for: roughly three weeks of rework, in the sprint where the launch date was supposed to stop moving.

Here is the version of that entry that would have closed the question in twenty minutes:

Out of scope for v1: row-level partial import. Considered and rejected — the staged importer uses one idempotency key per file; row-level retry requires per-row keys plus an admin reconciliation view (est. 3 weeks). Alternative chosen: whole-file re-upload with a downloadable error report. Revisit when more than 20% of production imports fail on at least one row, measured at v1+30 days. Owner: [PM].

Same section, same template, sixty words instead of six. The second version records a decision, its cost, its rejected alternative, and the observable condition under which it should be overturned — so the week-nine conversation becomes has the trigger fired? instead of what do we think?

Run this on your current PRD: take your Out of scope list and mark every entry that a stakeholder could reopen with a single sentence of enthusiasm. Those are the ones that will be reopened.

The discovery move

Excluding partial import was correct at the time. The failure was that the exclusion was captured as a disclaimer — a thing said to protect the team — rather than as a decision, which is a thing said to bind it.

Two questions convert one into the other, and both belong in the requirements conversation rather than the review of the finished document.

The first is asked of every scope line at capture: "What would have to be true for us to change this?" If the answer is "someone senior asks," you have a disclaimer. If the answer is an observable condition with a number and a date — more than 20% of imports fail on at least one row, checked at day 30 — you have a decision, and you have written the revisit trigger that stops the argument nine weeks later.

The second is asked in the review, out loud: "Who in this room would write this line differently, and what would they write instead?" Then ask the person most likely to object, by name. On Harbor, that was the Platform lead, and asking her is how the constraint went from fast enough to 5 seconds, 06:00–09:00 ET. Nobody was ever going to write the goals sentence differently, which is exactly what marked it as inert.

This is discovery-first work applied to a document rather than a system. The three weeks were not lost in engineering; they were lost at the moment a deferral was written down without the reasoning that produced it, while that reasoning was still in the room and cost nothing to capture. When the reopening does arrive, managing requirements changes mid-sprint is the containment; the trigger is the prevention.

Run this on your current PRD: pick your three most consequential scope decisions and write the revisit trigger for each. Any one you cannot express as an observable condition was never actually decided.

What each section is actually recording

Templates list sections. This is the same list, rewritten as the decision each section exists to record — and the test that tells you whether yours did.

Section	The decision it records	How it fails	The test that catches it
TL;DR	What we build, and why now rather than later	A summary of the doc, not a commitment to a moment	Delete "now" — does the sentence still say anything?
Problem	Which user pain we chose over the others	A market observation nobody disputes	Name the problem you didn't pick this quarter
Users	Whose workflow wins when two users conflict	A persona gallery; everyone is a user	Force a conflict: admin vs. employee — who loses?
Success metric	The number and date you'd be embarrassed to miss	"Improve onboarding efficiency" — ages into fiction	State the threshold below which v1 was a mistake
Requirements	Behavior someone could build wrong	Restates the feature name as a sentence	Could an engineer satisfy this and still be wrong?
Out of scope	What was rejected, and when to revisit	A disclaimer list with no reasoning	Write the revisit trigger; if you can't, it isn't decided
Open questions	What's unknown, who owns it, by when	Owner-less questions that become assumptions	Every row has a name and a date, or it's deleted
Constraints	The limits that shape design before design starts	Buried, unowned, or stated without numbers	Bound + condition + owner on each line
Alternatives rejected	The debate you don't want to have twice	Section omitted entirely — the usual omission	Ask what week nine will reopen
Rollout	Who gets it first, and what stops it	"Phased rollout" with no phase criteria	Name the metric that halts phase two

One idea runs down the right-hand column: a PRD section works when it forecloses something. Sections that only describe are storage.

Run this on your current PRD: score your sections against column four. Any section scoring zero can be deleted this afternoon without loss.

The sections that cost something to write

Four of those rows do most of the work, and they are the four teams most often skip — because they are the ones that require someone to be wrong on the record.

Out of scope is a decision, not a disclaimer. As a bare list it protects the team from blame; with reasoning, cost, and a revisit trigger it protects the team from re-litigation, which is the expensive one. A "won't have" is only useful if it travels with why and until when.

Open questions with owners and dates are the only honest part of an early PRD. Everything else written before build is a forecast. This is the one place the document tells the truth about what nobody knows, and in weeks one through four it is worth more than the requirements list. A question with no owner does not stay a question — it silently becomes an assumption held by whoever is closest to the code, and surfaces later as a defect.

A success metric needs a number and a date you would be embarrassed to miss. "Reduce time-to-onboard" is a direction, and directions cannot fail. "Median time from contract signature to first payroll run drops from 9 business days to 4, measured on customers signed after March 1, reviewed May 15" can fail, and its capacity to fail is its entire value. If missing it would produce no meeting, the metric was decoration.

Rejected alternatives stop the same debate reopening in week nine. This is the section templates omit and the one Harbor needed most. The pattern is borrowed rather than invented: Michael Nygard's architecture decision records exist because a future reader needs the context and consequences that produced a choice, not just the choice (Documenting Architecture Decisions, 2011). A PRD is the same instrument pointed at product decisions — status, context, decision, consequences, in one or two pages.

Run this on your current PRD: find the last scope debate your team reopened, then check whether the original PRD recorded the alternative that was rejected. It almost never does, and that absence is why the debate could reopen at all.

The exception: when a PRD is the wrong artifact

A PRD is a coordination instrument. Its cost scales with the number of people who need to hold the same picture, and its value is near zero when that number is small. Skip it when all three hold:

• The change is small and reversible. A copy change, a validation rule, a new column in an export. The decisions fit in the ticket, and a PRD here produces a document whose only reader is its author.

• One team owns every dependency. No partner contract, no other team's schema, no shared release train. When the people who decide and the people who build are in the same standup, the coordination value collapses and the maintenance cost does not.

• You are still in continuous discovery. Pre-product-market-fit work where the problem statement changes faster than the document can. Marty Cagan's argument is precisely that early-stage teams should be testing ideas against users rather than documenting them for handoff (Inspired, 2nd ed.).

What replaces it, in increasing weight: acceptance criteria on the story; a one-page decision record for a single consequential choice, in Nygard's format; a short problem brief with a success metric and three open questions, for discovery work where the answer isn't known yet.

One thing survives every exception. Even when you skip the document, write the deferrals down with their triggers — a paragraph in the ticket is enough. Deferrals are the only part of the record you cannot reconstruct later, because the reasoning that produced them lives in one conversation and then evaporates. Skipping the PRD is usually right; skipping the deferral log is what makes week nine expensive.

The diagnostic

Take the PRD on your screen and do one pass with a highlighter.

1. Strike every sentence nobody could argue with. Goals no one would oppose, benefits everyone agrees on, restatements of the feature name. Do not soften them — strike them.

2. Read what is left. That is your actual PRD. If it fits in half a page, the other five and a half were review time your team spent producing agreement about nothing.

3. For each surviving sentence, name the person who could dispute it. A sentence with a plausible dissenter is a real decision. A sentence whose dissenter you cannot name is decoration wearing a number.

4. Add the two missing rows. Rejected alternatives, and a revisit trigger on every deferral. These are the only sections whose absence stays invisible until the argument restarts.

ISO/IEC/IEEE 29148:2018 sets out what a well-formed requirement must be — verifiable, unambiguous, singular, feasible — and is worth applying line by line to the requirements section. This diagnostic covers the rest of the document, which is where the deciding actually happens and where no standard is watching.

Harbor's three lost weeks did not come from a bad template. Every section a PRD is supposed to have was present and filled in. They came from six words under a heading, written in the ninety seconds at the end of a meeting when the reasoning was still fresh and free, and captured as a disclaimer instead of a decision. Whether your next PRD is worth writing comes down to that same ninety seconds, repeated a dozen times — the cost of a sentence someone could argue with, paid now rather than in week nine. For the upstream discipline that makes those sentences easier to write, writing good requirements covers turning a vague ask into a line that can be wrong.

Sources

• ISO/IEC/IEEE 29148:2018, Systems and software engineering — Life cycle processes — Requirements engineering — characteristics of well-formed requirements, including verifiability, singularity, and unambiguity.

• Karl Wiegers and Joy Beatty, Software Requirements, 3rd ed. (Microsoft Press, 2013) — documentation structure, scope boundaries, assumptions and open issues.

• Michael Nygard, Documenting Architecture Decisions (2011) — the title / status / context / decision / consequences record, and the case for capturing the forces behind a choice.

• Marty Cagan, Inspired: How to Create Tech Products Customers Love, 2nd ed. (Wiley, 2018) — continuous discovery, and the case against requirements documents as handoff artifacts early on.

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide), v3 — requirements traceability, approval, and the distinction between requirements and design.