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.

For lightweight PRDs, sections 2, 3, and 8 can be condensed to 2-3 sentences each.

Frameworks & Best Practices

• Problem before solution. Spend 40% of the document on sections 1-5 (the "why") before touching section 7 (the "what"). A PRD that jumps to the solution is a spec, not a PRD.
• One objective, not five. A PRD with multiple objectives is multiple PRDs. Split them. Each PRD should have a single primary metric it moves.
• Market segments defined by needs. Describe who this is for based on the problems they face and jobs they hire the product to do, not by demographics or firmographics alone.
• Value Proposition clarity. For each segment, explicitly state the customer jobs addressed, gains provided, and pains eliminated. Use the Value Curve to show where you differentiate from competitors.
• Data-driven specificity. Replace vague language with specific numbers. "Improve retention" is not a metric; "Increase D7 retention from 25% to 35% within 8 weeks of launch" is.
• Scope creep guard. Explicitly list what is NOT in scope. Revisit the out-of-scope list when stakeholders propose additions.
• Relative timeframes over dates. Use phases and relative windows rather than exact calendar dates. This prevents false precision and allows flexibility.
• Assumption tracking. List the top 3 assumptions underlying the PRD. For each, state supporting evidence and what would invalidate it.
• Audience awareness. Engineers need technical constraints and edge cases. Designers need user flows and personas. Executives need the summary and metrics. Write for all three in a single document.
• Living document. State the PRD version and last-updated date. PRDs that never change were never read.
• Lightweight PRD triggers: pre-PMF exploration, hackathon projects, internal tools, experiments with <2 week timelines.
• Full PRD triggers: cross-team initiatives, features with external dependencies, anything touching payments or compliance.