create-prd

What this skill does

# PRD Scaffolding Expert

## Overview

Structured product requirements document creation using a proven 8-section framework. This skill produces clear, jargon-free PRDs that communicate what to build, why it matters, and how success is measured. Every PRD generated follows a consistent structure that keeps engineering, design, and business stakeholders aligned.

### When to Use

- **New Product Initiative** -- Starting a product from scratch and need a comprehensive spec before development begins.
- **Feature Expansion** -- Adding significant functionality to an existing product that requires cross-team alignment.
- **Stakeholder Alignment** -- Need a single document that answers "what are we building and why?" for everyone involved.

## Pre-PRD Techniques

Before writing the PRD, use one or both of these techniques to sharpen the problem definition and align the team on value.

### Technique A: Problem Framing Canvas

Frame the problem from the user's perspective before jumping to solutions. This canvas produces the narrative that feeds directly into PRD Sections 3 (Background) and 5 (Market Segments).

```markdown
## Problem Framing Canvas

### Problem Framing Narrative

**I am**: [Describe the key persona experiencing the problem]
- [Key characteristic 1]
- [Key characteristic 2]
- [Key characteristic 3]

**Trying to**: [A single sentence listing the desired outcomes]

**But**:
- [Barrier preventing outcomes 1]
- [Barrier 2]
- [Barrier 3]

**Because**: [Root cause explanation in empathetic language]

**Which makes me feel**: [Emotional impact from persona perspective]

### Context & Constraints
- [Geographic, technological, time-based, organizational constraints]

### Final Problem Statement
- [Single concise, empathetic summary for stakeholder alignment]

### Assumptions to Validate
- [Assumption 1]
- [Assumption 2]
```

**Next steps:** Generate testable solution hypotheses, convert into a workshop facilitation guide, or create stakeholder-specific variants (Exec, Eng, Design).

### Technique B: Working Backwards Press Release

Write an Amazon-style "future press release" announcing the product as if it already shipped. This forces you to articulate customer value before implementation.

```markdown
## Working Backwards Press Release

"[Product Name] by [Company] Aims to [Main Purpose/Goal]"

"[City], [Date] --"

"Today, [Company], a [type of organization], announced [product/feature],
a [brief description]. This [product] is set to [main benefit], addressing
[key issue or need]."

"[Product] will [what it does/solves]. [Quote from key person]:
'[customer-outcome-focused quote].' This initiative reflects [Company]'s
commitment to [core value]."

"In addition to [mentioned features], [product] also [additional benefits].
According to [source], [relevant data supporting the news]."

**Media Contact:** [Name, Title, Email]
```

**Writing rules:**
- Focus on customer outcomes, not feature lists.
- Avoid hype; favor credible claims and concrete benefits.
- If you can't write a compelling PR, the product concept needs more work.

**Next steps:** Generate an FAQ, create stakeholder-specific variants, generate objection-handling talking points, or define launch success metrics.

---

## PRD Framework (8 Sections)

### Section 1: Summary

Write 2-3 sentences that a busy executive can read in 10 seconds and understand the full scope. Answer three questions: What is this? Who is it for? Why are we doing it now?

Do not use marketing language. State the product, the user, and the expected outcome plainly.

### Section 2: Contacts

A table of people involved in the decision:

| Name | Role | Responsibility |
|------|------|----------------|
| ... | Product Manager | Final decision on scope |
| ... | Engineering Lead | Technical feasibility |
| ... | Design Lead | UX direction |
| ... | Stakeholder | Business approval |

Keep this short. Only list people who will actively contribute or approve.

### Section 3: Background

Answer three questions:

1. **Context** -- What is the current state? What exists today?
2. **Why now?** -- What changed in the market, technology, or business that makes this urgent?
3. **What recently became possible?** -- New capabilities, partnerships, data, or insights that enable this initiative.

This section sets the stage. A reader who skips every other section should still understand the motivation after reading Background.

### Section 4: Objective

State the business benefit and the customer benefit separately:

- **Business benefit**: How does this move a business metric? (revenue, retention, cost reduction, market share)
- **Customer benefit**: How does this improve the user's life? (time saved, friction removed, new capability)

Then define 2-4 SMART Key Results in OKR format:

- **Objective**: [qualitative, inspirational statement]
- **KR1**: [metric] from [current] to [target] by [date]
- **KR2**: [metric] from [current] to [target] by [date]
- **KR3**: [metric] from [current] to [target] by [date]

### Section 5: Market Segment(s)

Define segments by the problems they face or jobs they need done -- not by demographics. A segment is a group of people who share a common struggle or desired outcome.

Format: "[Segment name]: People who need to [job/problem] because [context]."

Bad: "Millennials aged 25-35 in urban areas"
Good: "Time-constrained professionals who need to coordinate schedules across 3+ tools because their organization lacks a unified calendar system"

### Section 6: Value Proposition(s)

For each market segment, define:

1. **Jobs addressed** -- What tasks or goals does this product help accomplish?
2. **Gains created** -- What positive outcomes does the user experience?
3. **Pains relieved** -- What frustrations, risks, or obstacles are removed?
4. **Competitive advantage** -- Why is our approach better than existing alternatives?

Use the **Value Curve** framework to visualize where you compete, where you exceed, and where you deliberately underinvest relative to alternatives.

### Section 7: Solution

Break into subsections:

- **UX / Prototypes** -- Key screens, flows, or interaction patterns. Link to design files.
- **Key Features** -- Numbered list of features with one-sentence descriptions. Mark each as P0 (must-have), P1 (important), or P2 (nice-to-have).
- **Technology** (optional) -- Architecture decisions, integrations, or infrastructure requirements that constrain the solution.
- **Assumptions** -- Explicit list of things you believe to be true but have not validated. Each assumption should have a plan to validate it.

### Section 8: Release

- **Relative timeline** -- Use T-shirt sizes (S/M/L/XL) or Now/Next/Later rather than specific dates, unless dates are firm.
- **v1 scope** -- What ships in the first version? Draw a clear line.
- **Future versions** -- What is explicitly deferred? List it so stakeholders know it was considered but intentionally excluded.
- **Success criteria** -- When do we know v1 succeeded? Reference the Key Results from Section 4.

## Writing Principles

- **Plain language** -- No jargon, no acronyms without definition, no buzzwords.
- **One idea per sentence** -- If a sentence has "and" connecting two distinct ideas, split it.
- **Specificity over abstraction** -- "Reduce onboarding from 12 steps to 4" beats "Simplify onboarding."
- **Saved as**: `PRD-[product-name].md`

## Workflow

1. Gather context: product name, target segment, core problem.
2. Run `scripts/prd_scaffolder.py` to generate the skeleton.
3. Fill in each section using the guidance above and `references/prd-writing-guide.md`.
4. Review against the checklist in `references/prd-writing-guide.md`.
5. Share with stakeholders for feedback.

## Tools

| Tool | Purpose | Command |
|------|---------|---------|
| `prd_scaffolder.py` | Generate PRD skeleton | `python scripts/prd_scaffolder.py --product-name "MyProduct" --objective "Short description" --segments "Segment A, Segment B"` |

## Troubleshooting

| Sympto