A PRD is a persuasion document before it is a spec
PRD stands for Product Requirements Document: the document that gets engineers, designers and stakeholders looking at the same picture of what to build and why. The most common beginner mistake starts right here, treating the PRD as a feature spec and filling it with screens and button lists first.
An engineer handed a bare feature list does one of two things: implements it literally and comes back with questions at every odd spot, or fills the gaps with their own interpretation. Either way, meetings multiply. A good PRD persuades instead: this problem is real, this direction is right, this is the boundary. A persuaded engineer proposes better implementations rather than asking what you meant.
Half the document is the problem
Write down who hits the problem, in what situation, and how often. Attach numbers when you have data; attach evidence like user interviews or support tickets when you do not. A feature with a vague problem statement has no defense once it starts slipping in a prioritization meeting.
If the evidence feels thin while you are writing the problem, that is not a writing problem, it is a planning problem, and the PRD just surfaced it before launch. Whether you go gather stronger evidence or change direction, the cheapest moment to do it is before any code exists.
Write down what you are not doing
A non-goals section, stating what was deliberately left out of scope, is a near-standard practice in the design docs Google engineers write. It pins down the things a reader could reasonably expect but that this round will not do: for example, this search improvement does not cover typo correction.
Without this section the same debate repeats through the whole build, because every should-this-not-also-work question has to be answered from scratch. With the decision and its reason in the document, the answer is one link. It is the cheapest device there is against scope creeping outward one question at a time.
Requirements you can verify
There is one test for a requirement sentence: can a third party judge whether it is done? Verbs like improve or make convenient cannot be judged, so they are wishes, not requirements.
Set the success metric before launch
Pick the metric after launch and you will pick whichever number went up. So the success metric goes in before anything is built, with a target and a way to measure it: success means cart abandonment drops from 60% to below 45% within four weeks of launch, for example.
With the metric fixed in advance, launch becomes the start of an experiment instead of the finish line. Even a miss survives as data on which assumption was wrong, and the problem section of your next PRD gets that much stronger.
The one-page skeleton
Formats differ by team, but the questions to answer do not. With these five sections, even a single page does the job of a PRD.
| Section | The question it answers |
|---|---|
| Background and problem | Who is struggling, in what situation, because of what |
| Goals and metrics | Which number will confirm success |
| Non-goals | What could be expected but is out of scope this time |
| Requirements | What gets built, in sentences whose completion can be judged |
| Open questions | What is undecided, and who decides it by when |
A document you keep rewriting until launch
A PRD is not written once and signed off; it is a working document updated until launch. When a requirement changes mid-build, fix the document first and note the date and reason. The moment the document and the actual build diverge, the PRD becomes a file nobody opens.
Once the draft is done, show it to your busiest engineer first and ask where they got stuck reading. Every question marks a hole in the document. Patch those holes before sharing widely, and the kickoff meeting turns from a briefing into a discussion.
Frequently asked questions
How is a PRD different from a product spec or planning doc?
Often they are the same thing under different names. The real distinction is with screen design documents: a PRD covers what to build and why, a screen spec covers what it looks like. Start development from screen specs alone, with no why, and every judgment call during implementation comes back as a question.
How long should a PRD be?
One page is a PRD if it has the problem, metrics, scope, requirements and open questions; ten pages is not one if those five answers are missing. Long material like screen details or data definitions belongs in appendices or linked documents, because a short body is what gets read.
Do agile teams need PRDs at all?
Not in the sense of a thick document every sprint (the 1-2 week development cycle). Individual backlog items are fine as user stories, single-line requirements from the user's point of view. But a chunk of functionality spanning several cycles needs one document holding the why and the scope. Without it, nobody can explain where all those story fragments are heading.