PRD
A Product Requirements Document answers one question: what problem is
being solved, for whom, and how will anyone know it's solved? It is
audience-facing to stakeholders who may never read the implementation —
product owners, other teams, future maintainers deciding whether a
feature still matches its original intent. It deliberately excludes
architecture, interfaces, and implementation approach; those belong in a
spec written against this document, not inside it.
Reach for this when
- Asked to write, update, or review a PRD specifically.
- Asked to define what a product or feature should do, for whom, and why
— before any technical approach has been chosen.
- A
spec is being requested but no PRD exists yet to hand off from; flag
the gap and offer to write the PRD first rather than letting the spec
invent requirements it should be receiving.
Do not reach for it when the request is about how something will be
built (spec), a checklist for whether a specific change is ready to
start (close-the-loop), or a reduction of existing material to what a
reader needs to act on (distill).
Structure
Keep every section traceable to a decision someone will actually make from
it. A section nobody will use to decide anything is padding.
- Problem. What is broken, missing, or costly today, for whom,
evidenced where possible — not asserted. If there's no problem, there's
no PRD; say so instead of inventing one to justify a solution already
chosen.
- Goals. The outcomes this delivers, stated as what changes for the
user or business, not as a list of features.
- Non-goals. What this explicitly does not attempt, named as
specifically as the goals. A PRD without non-goals invites scope creep
because nothing in it says no.
- Success criteria. Observable conditions a stakeholder — not an
engineer — could check to tell whether the problem from section 1 is
actually solved. If a criterion requires reading the implementation to
evaluate, it belongs in the spec instead.
- Audience / users. Who this is for, and who it is explicitly not
for, when that distinction changes what gets built.
What this hands off
A PRD that's ready to hand to spec states the problem and success
criteria concretely enough that two different engineers reading it would
propose comparably-scoped solutions, even if their technical approaches
differ. If the problem statement is vague enough that a spec would have to
guess at what "done" means, the PRD isn't finished yet — finish it before
handing off, rather than letting the spec quietly redefine the problem to
fit a chosen implementation.
What this is not
- Not a technical design. If you find yourself naming a database, an API
shape, or a library while writing this, that content belongs in the
corresponding
spec — move it there.
- Not a general plan.
close-the-loop checks whether a already-scoped
change has everything it needs to start; a PRD exists upstream of that,
before the change is scoped at all.
- Not a summary of existing material.
distill reduces a large source to
what a reader can act on; a PRD originates requirements, it doesn't
compress something that already exists.
1---2name: prd3description: Author or review a Product Requirements Document — the problem being solved, who it's for, the goals and explicit non-goals, and the success criteria a stakeholder would use to judge whether the problem is actually solved. Use when asked to write, update, or review a PRD, or to define what a product or feature should do and why before any technical approach is chosen. Not for how it will be built — that is spec, which a PRD hands off to once the problem and goals are settled. Not a general project plan or pre-flight checklist — see close-the-loop for that.4---56# PRD78A Product Requirements Document answers one question: what problem is9being solved, for whom, and how will anyone know it's solved? It is10audience-facing to stakeholders who may never read the implementation —11product owners, other teams, future maintainers deciding whether a12feature still matches its original intent. It deliberately excludes13architecture, interfaces, and implementation approach; those belong in a14`spec` written against this document, not inside it.1516## Reach for this when1718- Asked to write, update, or review a PRD specifically.19- Asked to define what a product or feature should do, for whom, and why20 — before any technical approach has been chosen.21- A `spec` is being requested but no PRD exists yet to hand off from; flag22 the gap and offer to write the PRD first rather than letting the spec23 invent requirements it should be receiving.2425Do not reach for it when the request is about *how* something will be26built (`spec`), a checklist for whether a specific change is ready to27start (`close-the-loop`), or a reduction of existing material to what a28reader needs to act on (`distill`).2930## Structure3132Keep every section traceable to a decision someone will actually make from33it. A section nobody will use to decide anything is padding.34351. **Problem.** What is broken, missing, or costly today, for whom,36 evidenced where possible — not asserted. If there's no problem, there's37 no PRD; say so instead of inventing one to justify a solution already38 chosen.392. **Goals.** The outcomes this delivers, stated as what changes for the40 user or business, not as a list of features.413. **Non-goals.** What this explicitly does not attempt, named as42 specifically as the goals. A PRD without non-goals invites scope creep43 because nothing in it says no.444. **Success criteria.** Observable conditions a stakeholder — not an45 engineer — could check to tell whether the problem from section 1 is46 actually solved. If a criterion requires reading the implementation to47 evaluate, it belongs in the spec instead.485. **Audience / users.** Who this is for, and who it is explicitly not49 for, when that distinction changes what gets built.5051## What this hands off5253A PRD that's ready to hand to `spec` states the problem and success54criteria concretely enough that two different engineers reading it would55propose comparably-scoped solutions, even if their technical approaches56differ. If the problem statement is vague enough that a spec would have to57guess at what "done" means, the PRD isn't finished yet — finish it before58handing off, rather than letting the spec quietly redefine the problem to59fit a chosen implementation.6061## What this is not6263- Not a technical design. If you find yourself naming a database, an API64 shape, or a library while writing this, that content belongs in the65 corresponding `spec` — move it there.66- Not a general plan. `close-the-loop` checks whether a already-scoped67 change has everything it needs to start; a PRD exists upstream of that,68 before the change is scoped at all.69- Not a summary of existing material. `distill` reduces a large source to70 what a reader can act on; a PRD originates requirements, it doesn't71 compress something that already exists.
jonhill90