# Product Requirements Doc > Writes a PRD that states the problem with evidence, an explicit and enforced non-goals list, the decisions already made with their rationale, the open questions with owners and due dates, and the launch and rollback criteria. Use when a feature or product change needs a written requirements document before build; trigger on 'write a PRD', 'spec this feature', 'product requirements for X', 'what are we actually building', 'we need a one-pager before engineering starts'. Not for breaking an agreed PRD into implementable stories (use product-user-story-acceptance-criteria), not for communicating timeline commitments outward (use product-roadmap-communication), and not for system or interface design decisions (use engineering-decision-record). - Skill: `alihusains/product-requirements-doc` (Agent Skill) - Install (CLI): `npx skillmds@latest add alihusains/product-requirements-doc` - Raw SKILL.md: https://api.skillmd.com/api/skills/alihusains/product-requirements-doc/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: alihusains (https://skillmd.com/u/alihusains) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/alihusains/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 | Section | What makes it valid | Common failure | | --- | --- | --- | | Summary | What changes for whom, in three sentences | A feature name with no user | | Problem | Stated as a user or business problem, with cited evidence and its date | The solution restated as a problem | | Evidence | Sources listed with dates and sample or scale | One anecdote generalised | | Users affected | Named segments, with rough size where known | "All users" | | Goals | Two or three outcomes, each with a measure and a baseline | Outputs listed as goals | | Non-goals | Explicit list of what this will not do, and why | Absent, or hedged into meaninglessness | | Requirements | Behaviour required, prioritised must / should / could | Implementation detail masquerading as requirement | | Decisions made | Each decision, the alternatives, and why | Decisions implied by the requirements only | | Open questions | Question, owner, due date, and what is blocked until answered | An unowned list that never closes | | Dependencies | Teams, systems, vendors, and approvals needed | Discovered mid-build | | Risks | Named risk, likelihood, and the mitigation or acceptance | Generic risk boilerplate | | Compliance and data | Personal or regulated data touched, lawful basis, retention, approvals | Omitted until the security review | | Success and failure criteria | What result means keep, iterate, or roll back | Success only, so nothing is ever wrong | | Rollout and rollback | Sequence, guardrails, and how the change is reversed | No reversal path | ## 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.