Product requirements document: what to write and what to leave out

A product requirements document — a PRD — sets out what a product or feature should do, for whom, and why it is worth doing. It sits between the decision to build something and the work of building it. Its reputation is poor, mostly deserved, because the version most people have met was forty pages long, written once, and out of date before the second sprint. The short version is a genuinely useful artefact; the long version is a way of appearing to have made decisions.

What belongs in a product requirements document

• The problem, stated from the user’s side, with whatever evidence you have that it is real.
• Who it is for — specifically enough to exclude someone, or the scope will expand later by default.
• What success looks like, as a number you will actually check after launch.
• The requirements themselves, prioritised, each phrased so someone can tell whether it is met.
• What is explicitly out of scope, which is the section that saves the most time and is most often omitted.
• Open questions with owners and dates, rather than silently unresolved decisions.
• Dependencies on other teams, which is where the schedule usually breaks.

What to leave out

1. Implementation detail. If the document specifies the database schema, either it is a technical design or the engineers were not consulted.
2. Screens drawn in prose. Link the design; do not describe it in paragraphs that will disagree with it within a week.
3. Market analysis copied from a strategy deck, which nobody rereads and which dates fastest.
4. A full specification of features you have decided not to build yet — write them as out of scope, not as a future section.
5. Sign-off theatre: five approvers who did not read it add delay and no assurance.

Decide up front whether the document is a decision record or a living specification, because they are maintained differently. A decision record is frozen and dated, and disagreements later become new documents. A living specification must be updated as things change, which requires an owner who will actually do it. The failure mode is a document treated as the first and maintained like the second — frozen in practice, cited as current.

Keeping it useful after week one

• Put the decisions that changed at the top, dated, rather than editing the body silently.
• Keep the requirement identifiers stable, because tickets and tests reference them — this is what makes a requirements traceability matrix possible later if you need one.
• Link out rather than restate: to the designs, the research, the statement of work if the work is contracted.
• Review at each milestone and record explicitly that it was reviewed, even when nothing changed.
• Archive it when the thing ships. A PRD kept live for a shipped feature becomes a documentation liability nobody reads and everybody half-trusts.

Where the document lives

Ettex Docs suits a PRD better than a wiki page in one specific way: version history that shows what changed and when, which is the question asked whenever a shipped feature does not match what someone remembers agreeing. Keep comments on the document rather than in a separate thread, so the reasoning stays with the decision. Ettex does not manage backlogs and does not link requirements to tickets automatically — the identifiers are yours to keep consistent. The document is worth about as much as the conversation it caused, so keep it short enough that people finish it.