pm-skills/pm-execution/commands/write-prd.md

description, argument-hint

description	argument-hint
Create a comprehensive Product Requirements Document from a feature idea or problem statement	<feature or problem statement>

/write-prd -- Product Requirements Document

Create a structured PRD that aligns stakeholders and guides development. Accepts anything from a vague idea to a detailed brief.

Invocation

/write-prd SSO support for enterprise customers
/write-prd Users are dropping off during onboarding — we need to fix step 3
/write-prd [upload a brief, research doc, or strategy deck]

Workflow

Step 1: Understand the Feature

Accept the input in any form:

• A feature name ("SSO support")
• A problem statement ("Enterprise customers keep asking for centralized auth")
• A user request ("Users want to export their data as CSV")
• A vague idea ("We should do something about onboarding drop-off")
• An uploaded document (brief, research, Slack thread, email)

Step 2: Gather Context

Ask conversationally — most important questions first, fill gaps as you go:

1. User problem: What problem does this solve? Who experiences it? How painful is it?
2. Target users: Which user segment(s)? How many? What's their current workaround?
3. Success metrics: How will we know this worked? What moves if we nail it?
4. Constraints: Technical constraints, timeline, regulatory, dependencies on other teams?
5. Prior art: Has this been attempted before? Existing solutions in the market?
6. Scope preference: Full solution or phased approach?

If the user provides a document with context, extract what's available and only ask about gaps.

Step 3: Generate the PRD

Apply the create-prd skill to produce an 8-section document:

## Product Requirements Document: [Feature Name]

**Author**: [user]
**Date**: [today]
**Status**: Draft
**Stakeholders**: [if known]

### 1. Executive Summary
[2-3 sentences: what, for whom, why now]

### 2. Background & Context
[Problem space, prior research, market context, what prompted this]

### 3. Objectives & Success Metrics
**Goals** (what success looks like):
1. [Specific, measurable goal]
2. [...]

**Non-Goals** (explicitly out of scope):
1. [What we're not doing, and why]
2. [...]

**Success Metrics**:
| Metric | Current | Target | Measurement |
|--------|---------|--------|-------------|

### 4. Target Users & Segments
[Who this serves, user profiles, segment sizing]

### 5. User Stories & Requirements

**P0 — Must Have**:
| # | User Story | Acceptance Criteria |
|---|-----------|-------------------|

**P1 — Should Have**:
| # | User Story | Acceptance Criteria |
|---|-----------|-------------------|

**P2 — Nice to Have / Future**:
| # | User Story | Acceptance Criteria |
|---|-----------|-------------------|

### 6. Solution Overview
[High-level approach, key design decisions, technical approach if known]

### 7. Open Questions
| Question | Owner | Deadline |
|----------|-------|----------|

### 8. Timeline & Phasing
[Milestones, dependencies, phasing if applicable]

Step 4: Review and Iterate

After generating, offer:

• "Want me to tighten the scope? I can challenge which P1s should really be P2s."
• "Should I run a pre-mortem on this PRD?"
• "Want me to break this into user stories for engineering?"
• "Should I create a stakeholder update to socialize this?"

Save the PRD as a markdown file to the user's workspace.

Notes

• Be opinionated about scope — a tight PRD is better than an expansive vague one
• If the idea is too big, proactively suggest phasing and spec only Phase 1
• Non-goals are as important as goals — they prevent scope creep
• Success metrics must be specific: "improve NPS" is bad, "increase NPS from 32 to 45 within 90 days of launch" is good
• Open questions should be genuinely unresolved — don't list things you can answer from context
• If the user provides research, weave insights into the Background section with attribution