PRD Drafting

🔵 Optional

Use this when: You need to write or refine a product requirements document — for a new feature, a product initiative, or to align stakeholders on scope and direction.

Quick version: Use the /prd-draft skill in Claude Code for one-command execution.

Why this matters

A PRD is a communication tool, not a specification. Its job is to align stakeholders, designers, and engineers on what you're building and why — before anyone starts building. A good PRD prevents the most expensive kind of waste: building the wrong thing.

An agent can generate a solid first draft of a PRD in minutes. But a PRD that's merely comprehensive isn't useful. It needs to be right — reflecting real user needs, genuine business constraints, and honest trade-offs. That's your job.

What to prepare

Before running this workflow, gather:

User research or evidence that supports the need (interviews, metrics, support data)
Business context (why now, what's the strategic rationale)
Known constraints (technical, timeline, budget, dependencies)
Prior art (competitor approaches, existing solutions, previous attempts)
Stakeholder expectations (what different people think this project should accomplish)

The workflow

Step 1: Draft the PRD

I need to write a PRD for the following feature/initiative:

Feature: (name)
One-line description: (what it does in plain language)

User problem:
(What problem does this solve? For whom? Include evidence — quotes, data, support tickets.)

Business rationale:
(Why is this worth building now? What's the strategic context?)

Known constraints:
(Technical limitations, timeline, budget, dependencies, regulatory requirements)

Prior art:
(How do competitors or existing solutions handle this? What can we learn?)

Draft a PRD with these sections:

1. **Overview** — What we're building and why, in 3-4 sentences
2. **Problem statement** — The user problem, supported by evidence
3. **Goals and success metrics** — What does success look like? How will we measure it?
4. **User stories** — The key user stories (with Gherkin acceptance criteria) that define scope
5. **Scope** — What's in scope and what's explicitly out of scope
6. **Design considerations** — Key UX questions, interaction patterns, or constraints
7. **Technical considerations** — Architecture implications, dependencies, risks
8. **Open questions** — Things we need to resolve before or during development
9. **Timeline and milestones** — High-level phases (if applicable)

Be specific. Avoid vague language like "intuitive" or "seamless." Use concrete descriptions.

Step 2: Stress-test the draft

Review the PRD you just drafted and play devil's advocate:

1. What are the weakest assumptions in this PRD?
2. What could go wrong that we haven't addressed?
3. Is the scope too broad for a first release? Suggest an MVP cut.
4. Are the success metrics actually measurable with our current tooling?
5. What questions would a skeptical engineer ask about this PRD?
6. What questions would a skeptical designer ask?

Step 3: Iterate on weak spots

Address each issue the agent raised. For the strongest objections, revise the PRD directly. For open questions, add them to the "Open questions" section honestly rather than papering over them.

Before this goes to the team:

Evidence check — Is the problem statement supported by real data, or are you asserting a need you haven't validated?
Scope check — Could the "out of scope" section be bigger? First versions should be aggressively scoped down.
Success metrics check — Can you actually measure these? With tools you have today?
Open questions check — Are you being honest about what you don't know?

What to review

Check	Why
Problem statement is evidence-based	"Users want X" needs quotes or data; "We think users want X" is honest but weaker
Scope is disciplined	The agent will generate a comprehensive scope; your job is to cut it
Acceptance criteria are testable	Engineering should be able to write tests from the stories in the PRD
Out of scope is explicit	Ambiguity about scope is the #1 source of project overruns
Open questions are honest	A PRD with no open questions is either a lie or a trivial project

PRD as living document

A PRD isn't done when you share it. It evolves:

Before development — Incorporate feedback from design review and technical review
During development — Update scope and acceptance criteria as you learn
After launch — Record what changed and why; this is valuable for future PRDs

If you're using the two-layer planning system, the PRD feeds the compiled/plan.md — it's a major input to the authoritative plan.

Common mistakes

Writing a PRD for something you haven't researched — A PRD based on assumptions is a plan to build the wrong thing. Do the research first.
Comprehensive equals useful — A 20-page PRD that nobody reads is worse than a 2-page PRD that everyone understands. Optimize for clarity, not length.
Using the agent's scope as-is — The agent will generate a complete feature description. Your job is to find the smallest version that delivers value and ship that first.
Skipping the stress test — The devil's advocate step is where the real value is. Don't skip it because the first draft "looks good."
Treating the PRD as a contract — It's a communication tool. If you learn something during development that changes the plan, update the PRD. Don't treat it as immutable.