prd-writing

PRD Writing

When to Use

Activate when a founder or PM needs to turn a product idea, feature request, or strategic initiative into a structured Product Requirements Document. This includes situations where the user says things like "write a PRD," "spec out this feature," "define requirements for X," or "I need to document what we're building."

Context Required

• From startup-context: company stage, target customer segments, current product state, team size, technical constraints.
• From the user: the feature or initiative to spec, known user problems it addresses, any prior research or customer feedback, desired timeline, and scope preference (lightweight vs. full PRD).

Workflow

1. Clarify scope level -- Ask whether this needs a lightweight PRD (early-stage exploration, 2-3 pages) or a full PRD (committed initiative, 5-8 pages). Default to lightweight if the company is pre-product-market-fit.
2. Gather inputs -- Collect the problem statement, target users, any existing research, success criteria, and known constraints. Identify key contacts and their roles.
3. Draft the 8-section PRD -- Write each section sequentially using the template below. Use accessible language suitable for a broad audience including engineering, design, and leadership.
4. Flag assumptions -- Explicitly list key assumptions underlying each section. For each, state what evidence supports it and what would invalidate it.
5. Review and refine -- Present the draft, invite feedback, and iterate on specific sections. State the PRD version and last-updated date.

Output Format

A structured PRD document with 8 sections:

Section Template

1. Summary -- 2-3 sentence overview of what is being built and why it matters. Write for a broad audience.
2. Contacts -- Key stakeholders with their roles and relevant context about their involvement.
3. Background -- Context on the problem space: why now, what changed, what enables this initiative. Include competitive context on how others handle the same problem.
4. Objective -- Goals, business and customer benefits, and strategic alignment. Define SMART success metrics tied to OKRs. Use the format: "Enable [user segment] to [action] resulting in [measurable outcome]."
5. Market Segment(s) -- Define target users by problems and needs, not demographics. Describe primary and secondary segments with size estimates.
6. Value Proposition(s) -- Map customer jobs addressed, gains provided, and pain points eliminated. Show competitive differentiation using frameworks like Value Curve analysis.
7. Solution -- Feature descriptions, UX/prototypes, wireframes, user flows, and technology details when relevant. Include out-of-scope items explicitly. Document assumptions. Enumerate at least 5 edge cases.
8. Release -- Phased rollout plan using relative timeframes (not exact dates). Define MVP vs. future iterations, feature flags, rollback criteria, and review checkpoints.