PRD Writer

A requirements document exists to make the same product appear in every reader's head. Most fail by describing a solution before establishing the problem, or by hiding the sharp edges — non-goals, edge cases, open questions — that were the reason to write things down at all. This skill drafts a PRD a stranger could build from, a reviewer could challenge in specifics, and a future team could audit against what actually shipped.

When to use this skill

• A feature idea or problem statement needs to become something engineering can scope and build
• Stakeholders keep describing different products in meetings about the same project
• A build is underway with no written source of truth, and the drift is starting to show
• An inherited or stale spec needs a rewrite before work restarts on it

Workflow

1. Interrogate the problem before drafting. Who hurts, how often, what do they do about it today, what does it cost them, and how do we know — usage data, support volume, research, revenue at risk? If the evidence is thin, write the PRD anyway and say so in a confidence line; hidden uncertainty is how bad bets get funded.
2. Write goals as measurable outcomes, not activities. "Reduce time-to-first-report from 40 minutes to under 10 for new workspace admins" — metric, target, population. Two or three goals at most; a PRD with seven goals has none.
3. Write the non-goals immediately after. Name the adjacent problems this deliberately does not solve and the scope requests already declined, each with one line of reasoning. Non-goals are the cheapest scope-creep insurance that exists.
4. Specify requirements as numbered, testable statements grouped by user-facing capability, each with a priority: must (launch blocks without it), should (strong default, negotiable), or later (explicitly deferred). "The system feels fast" is not testable; "search results render under 500 milliseconds at the 95th percentile" is.
5. Hunt edge cases by walking the boundaries: empty states, maximum scale, permission collisions, concurrent edits, offline and retry behavior, and the user who does everything in the wrong order. Each edge case gets a decided behavior or an explicit open question — silence is the only wrong answer.
6. Define success measurement before launch, not after. For each goal: the metric, its baseline today, the target, when it will be read (two weeks out, six weeks out), and what result would trigger rollback or iteration.
7. Route the open questions. Every unresolved item gets an owner and a needed-by date tied to the build sequence. An open question without an owner is a future incident with a timestamp.

PRD skeleton

• Title, one-line summary, author, status, confidence line
• Problem and evidence
• Goals (measurable) and non-goals (with reasons)
• Users and primary scenarios
• Requirements: numbered, prioritized, testable
• Edge cases and decided behaviors
• Dependencies and assumptions
• Success metrics: baseline, target, read date, rollback trigger
• Open questions with owners and dates
• Launch checklist: docs, support readiness, rollout stages, kill switch

Quality bar

• A new engineer could scope this without a meeting; a reviewer could disagree with it in specifics
• Every requirement is testable and traceable to a goal
• Every goal is measurable with existing instrumentation, or the instrumentation is itself a requirement
• The non-goals section contains real refusals, not padding
• Edge cases show decisions made, not discoveries left for QA
• The document states what it does not know: confidence declared, open questions owned and dated