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
- 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.
- Gather inputs -- Collect the problem statement, target users, any existing research, success criteria, and known constraints. Identify key contacts and their roles.
- 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.
- Flag assumptions -- Explicitly list key assumptions underlying each section. For each, state what evidence supports it and what would invalidate it.
- 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
- Summary -- 2-3 sentence overview of what is being built and why it matters. Write for a broad audience.
- Contacts -- Key stakeholders with their roles and relevant context about their involvement.
- Background -- Context on the problem space: why now, what changed, what enables this initiative. Include competitive context on how others handle the same problem.
- 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]."
- Market Segment(s) -- Define target users by problems and needs, not demographics. Describe primary and secondary segments with size estimates.
- Value Proposition(s) -- Map customer jobs addressed, gains provided, and pain points eliminated. Show competitive differentiation using frameworks like Value Curve analysis.
- 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.
- 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.
Related Skills
roadmap-planning-- Chain after writing PRDs to slot the initiative into the broader roadmap with dependencies and timelines.mvp-scoping-- Chain before writing a PRD to determine what to include in v1 vs. defer to later releases.user-research-synthesis-- Chain before writing a PRD to ground the Background and Market Segments sections in real customer data.
Examples
Example 1: Lightweight PRD prompt
User: "We need a PRD for adding Slack notifications to our project management tool."
Good output excerpt:
Summary: Add configurable Slack notifications so that teams using ProjectFlow are alerted to task updates, mentions, and deadline changes without leaving their primary communication tool. This addresses the #1 feature request from our Q3 customer survey (38% of respondents).
Objective: Enable team leads on paid plans to receive real-time project updates in Slack, resulting in a 20% reduction in average response time to task assignments within 6 weeks of launch.
Market Segment: Teams of 10+ coordinating across tools, whose primary pain is context-switching between project management and communication platforms.
Out of scope: Microsoft Teams integration, custom notification templates, Slack bot commands.
Example 2: Full PRD prompt
User: "Write a full PRD for our new self-serve onboarding flow. We're losing 60% of signups before they complete setup."
Good output excerpt:
Background: Current onboarding requires 7 steps and takes an average of 12 minutes. Hotjar recordings show 45% of users abandon at the "connect data source" step. Competitor X reduced their onboarding to 3 steps in Q2 and reported a 2x improvement in activation. Our support team handles 30+ onboarding tickets per week, costing approximately $4,500/month.
Value Proposition: Eliminate the "connect data source" friction by offering a sample dataset that lets users experience core value before committing to integration. Differentiated from Competitor X which still requires immediate data connection.
Release:
- Phase 1: Internal dogfood with the team (2 weeks)
- Phase 2: 10% of new signups via feature flag
- Phase 3: 50% rollout if activation rate > 45%
- Phase 4: GA if no P0 bugs and support ticket volume decreases
- Rollback trigger: activation rate drops below current 40% baseline
