Product Requirements Doc

PRD Authoring

Purpose

Most PRDs describe a solution and omit the boundary, so scope grows silently during build and nobody can say whether it grew or was always intended. This skill fixes the sections that actually prevent that: an evidenced problem statement, non-goals written as commitments rather than caveats, decisions recorded with their reasoning, and open questions that carry an owner and a date.

Prerequisites

• Inputs: the problem or opportunity with at least one source of evidence; the affected users or segments; the accountable product owner; the engineering and design counterparts.
• Access: whatever evidence exists — usage data, support or service records, research notes, sales or account feedback, incident history.
• Required decisions available: whether the work is committed or exploratory, and who signs off. If the work is unfunded exploration, say so at the top; the document's job changes.

If there is no evidence for the problem, write the PRD's first open question as "what evidence do we have that this problem exists?" with an owner, and do not fabricate usage figures, adoption estimates, or revenue impact to fill the section. An invented number in a PRD is quoted for years.

Data classification

Internal by default; Confidential where the document contains unreleased plans, pricing, or commercially sensitive customer detail. Cite customer evidence by segment and source, never by named individual, account number, or record. If someone supplies raw customer data to illustrate a problem, aggregate it before it enters the document and flag the raw data rather than storing it there.

Document structure

Procedure

1. Write the problem before any solution. State who experiences it, in what situation, how often, and what it costs them or the business. If you cannot write it without naming your intended feature, the problem is not yet understood.

2. Attach evidence with dates and scale. For each piece: source, date, and how many. One customer complaint is a signal to investigate, not a mandate to build; say which it is. Where the evidence is thin, mark the confidence level rather than inflating it.

3. Set goals with baselines. Each goal needs a current value and a target. If the metric is not currently measured, the first requirement is instrumentation — make that explicit, and route the metric's definition to data-analytics-metric-definition so it is not redefined later during the review.

4. Write non-goals as commitments. For each non-goal give a one-line reason: deferred, out of scope for this problem, or explicitly rejected. Include the adjacent things stakeholders will ask for during build — that is exactly what the section is for. A non-goals list containing nothing anyone wanted is decoration.

5. Record decisions with their alternatives. Format: decision, options considered, the reason for the choice, who decided, and the date. Six weeks later somebody will ask why; without this, the team re-litigates. Decisions that are structural or architectural belong in an engineering-decision-record instead — link, do not duplicate.

6. Give every open question an owner and a due date, plus what is blocked until it resolves. Questions without owners are how a PRD reaches sign-off with its riskiest assumption untested.

7. Prioritise requirements explicitly. Mark each must, should, or could, and state what happens if a should is cut. If everything is a must, priority has not been applied and the first schedule pressure will apply it arbitrarily.

8. Complete the compliance and data section before review, not after. Identify personal or regulated data touched, the lawful basis, retention, third-party processors, and which approvals are needed. Discovering this at security review costs a release cycle.

9. Define failure criteria alongside success. State the result that would cause the change to be reverted or the investment stopped, and the window in which that is judged. Agree it before launch; afterwards, nobody agrees to it.

10. Review with the accountable parties named in the prerequisites, and record sign-off with names and dates. Circulate the non-goals list explicitly at review — that is where a stakeholder either objects or is bound by it.

11. Keep the document current or mark it superseded. A PRD that diverges from what shipped is worse than no PRD. Record material changes with a date and a reason at the top; if the change is large, supersede the document rather than editing history quietly.

Failure modes

• Solution-first framing. The problem section written backwards from a chosen feature cannot rule anything out.
• Non-goals as a hedge. "We may consider this later" is not a non-goal. State deferred or rejected.
• Invented sizing. Estimated revenue or adoption presented without derivation becomes a commitment in someone else's slide.
• Goals that are outputs. "Ship the new flow" is not a goal; it is the work.
• Silent scope growth. Anything added after sign-off is a change to the PRD with a dated note, or it did not happen.
• No rollback path. Changes to pricing, data models, or externally visible behaviour need a stated reversal plan before they launch.

Boundaries

• Turning agreed requirements into implementable, testable stories — use product-user-story-acceptance-criteria.
• Communicating dates and commitment levels to stakeholders — use product-roadmap-communication.
• Technical approach, architecture, and interface choices — use engineering-decision-record.
• Documenting a repeatable operational process rather than a product change — use operations-sop-authoring.

Hand-offs

• Receives from: sales-discovery-preparation and support or service records as problem evidence; product-roadmap-communication for commitment status.
• Routes to: product-user-story-acceptance-criteria for decomposition, engineering-decision-record for technical decisions, and data-analytics-metric-definition for every metric named in goals.