Create Prd

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).

## 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.

## 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:

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

Troubleshooting

Success Criteria

• PRD passes the "10-second executive test" -- a busy executive understands scope from Section 1 alone
• All 8 sections are complete before development begins (no placeholder sections remain)
• Market segments defined by jobs-to-be-done, not demographics
• Key Results in Section 4 are measurable with baselines, targets, and deadlines
• Every assumption in Section 7 has a validation plan and owner
• PRD reviewed by PM, Engineering Lead, Design Lead, and at least one stakeholder before commitment
• v1 scope in Section 8 draws a clear line between what ships and what is explicitly deferred

Scope & Limitations

In Scope:

• 8-section PRD skeleton generation with guided placeholders
• Section-by-section writing guidance following plain-language, specificity-over-abstraction principles
• Market segment definition using jobs-to-be-done framework
• Value proposition mapping with Value Curve competitive analysis
• Release planning with Now/Next/Later and explicit deferral documentation

Out of Scope:

• Technical architecture or system design documents (see engineering/ skills)
• User story writing and backlog creation (see execution/job-stories/ and execution/wwas/)
• Detailed UX research or usability testing plans (see product-team/ skills)
• Financial business case modeling (see finance/ domain skills)

Important Caveats:

• A PRD is a communication tool, not a contract. Treat it as a living document that evolves with implementation learning.
• The 8-section framework is a proven structure, but lightweight agile teams may need only sections 1, 3, 4, 7, and 8. Heavyweight compliance contexts (medical devices, regulated industries) may need additional sections.
• A 2025 Carnegie Mellon SEI study found that effective requirements management eliminates 50-80% of project defects. The investment in a clear PRD pays for itself in reduced rework.

Integration Points

Tool Reference

prd_scaffolder.py

Generates a complete 8-section PRD markdown skeleton with guided placeholders, market segment sections, and value proposition templates.

References

• references/prd-writing-guide.md -- Section-by-section writing guide and review checklist
• assets/prd_template.md -- Complete PRD template ready to fill in

PRD: [Product Name]

Status: Draft | In Review | Approved Author: [Name] Date: [YYYY-MM-DD] Last Updated: [YYYY-MM-DD]

---

1. Summary

[2-3 sentences. What is this? Who is it for? Why now?]

---

2. Contacts

---

3. Background

Context

[What is the current state? What exists today?]

Why Now?

[What changed in the market, technology, or business?]

What Recently Became Possible?

[New capabilities, data, partnerships, or insights that enable this.]

---

4. Objective

Business Benefit

[How does this move a business metric?]

Customer Benefit

[How does this improve the user's life?]

Key Results

Objective: [Qualitative, inspirational statement]

---

5. Market Segment(s)

Segment 1: [Name]

Definition: People who need to [job/problem] because [context].

• Size estimate: [TAM/SAM/SOM or qualitative]
• Current behavior: [How do they solve this today?]
• Key pain point: [Primary frustration]

Segment 2: [Name]

Definition: People who need to [job/problem] because [context].

• Size estimate:
• Current behavior:
• Key pain point:

---

6. Value Proposition(s)

[Segment 1 Name]

• Jobs addressed:
• Gains created:
• Pains relieved:
• Competitive advantage:

Value Curve

---

7. Solution

UX / Prototypes

• [ ] [Screen/Flow 1]: [Description]
• [ ] [Screen/Flow 2]: [Description]

Design links: [URL]

Key Features

Technology (Optional)

• Architecture:
• Integrations:
• Infrastructure:

Assumptions

---

8. Release

Timeline

v1 Scope

• [What ships first]

Explicitly Deferred

• [Item] -- Reason: [why]

Success Criteria

v1 is successful when: 1. KR1 reaches [target] 2. KR2 reaches [target] 3. [Additional criteria]

PRD Writing Guide

A section-by-section guide for writing effective product requirements documents.

---

Section 1: Summary

What Makes a Good Summary

• Length: 2-3 sentences maximum. If it takes longer, the scope is too large or you do not understand it yet.
• Structure: What it is + who it is for + why now.
• Test: Can someone who knows nothing about your company read this and understand what you are building?

Good Example

"TaskFlow is a task management tool for distributed engineering teams that need async collaboration across time zones. It replaces manual standup updates with automated progress tracking. We are building this now because remote-first work has made synchronous updates impractical for 70% of our customer base."

Bad Example

"TaskFlow is a next-generation, AI-powered productivity platform that leverages cutting-edge technology to synergize cross-functional workflows and empower teams to achieve unprecedented efficiency gains."

The bad example uses jargon, makes vague claims, and does not tell you what the product actually does.

---

Section 2: Contacts

Tips

• Only list people who will actively contribute decisions or approvals.
• Include their specific responsibility, not just their job title.
• Keep it under 6 people. If more are involved, the project may be too large for one PRD.

---

Section 3: Background

Three Questions to Answer

1. Context: Describe the current state as if explaining to a new team member. What exists? What do users do today? 2. Why now? Something changed. Name it specifically: competitor launched X, customer churn increased Y%, new API became available, board set a new strategic direction. 3. What recently became possible? This is the most overlooked question. It separates "we should do this eventually" from "we can and should do this now."

Anti-Patterns

• Restating the objective as background ("We need to build this because it is important")
• Including solution details in the background section
• Writing more than one page

---

Section 4: Objective

Good Objectives vs Bad Objectives

Pattern: Good objectives include a specific metric, current value, target value, and timeframe.

Writing Key Results

• Each KR must have a number attached to it.
• KRs measure outcomes, not outputs. "Launch feature X" is an output. "Reduce time-to-task from 5 min to 2 min" is an outcome.
• Aim for 60-70% confidence that you can hit the target. If you are 100% confident, the target is too easy.

---

Section 5: Market Segments

Definition Tips

Define segments by shared problems or jobs-to-be-done, not demographics.

Why: Demographics describe who people are. Jobs describe what people need. Two people with identical demographics may have completely different needs. Two people with different demographics may share the exact same problem.

Format

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

Examples

• "Overwhelmed managers: People who need to track progress across 5+ direct reports because their organization lacks standardized reporting."
• "Solo founders: People who need to validate product-market fit quickly because they have limited runway and no dedicated research team."

---

Section 6: Value Proposition

Frameworks

Jobs-Gains-Pains:

• Jobs: Functional tasks, social goals, or emotional needs the user is trying to satisfy.
• Gains: Outcomes the user wants. Benefits they expect, desire, or would be surprised by.
• Pains: Risks, obstacles, and negative outcomes the user wants to avoid.

Value Curve: Plot your product against alternatives on key factors. Identify where you invest heavily (differentiation), where you match (table stakes), and where you deliberately underinvest (strategic tradeoff).

The value curve prevents "me too" products by forcing explicit tradeoff decisions.

---

Section 7: Solution

Feature Prioritization

• P0 (Must-have): Product does not ship without this. Users cannot accomplish the core job.
• P1 (Important): Significantly improves the experience. Ship in v1 if possible, v1.1 at latest.
• P2 (Nice-to-have): Adds polish or secondary value. Defer without guilt.

Assumptions

Every PRD contains assumptions. The dangerous ones are the ones you do not write down. List them explicitly with a plan to validate each one.

Common assumption categories:

• User behavior assumptions ("Users will adopt this workflow")
• Technical assumptions ("The API can handle this load")
• Market assumptions ("Competitors will not ship this first")
• Business assumptions ("This will reduce churn")

---

Section 8: Release

Timeline Tips

• Use relative sizing (S/M/L/XL) or Now/Next/Later unless you have firm dates.
• Specific dates create false precision. Stakeholders treat "Q2 2026" as a promise.
• Be explicit about what is NOT in v1. Deferred items show stakeholders their request was heard but intentionally sequenced.

---

PRD Review Checklist

Use this before sharing the PRD with stakeholders:

Clarity

• [ ] Can someone outside the team understand the Summary in 10 seconds?
• [ ] Is every acronym defined on first use?
• [ ] Are there zero instances of jargon ("leverage," "synergy," "paradigm")?

Completeness

• [ ] All 8 sections are filled in (not just placeholder text)?
• [ ] At least 2 Key Results with metrics, baselines, and targets?
• [ ] At least 1 market segment defined by problem, not demographics?
• [ ] At least 3 assumptions listed with validation plans?

Specificity

• [ ] Objective includes a measurable metric?
• [ ] Features have priority labels (P0/P1/P2)?
• [ ] v1 scope has a clear boundary (what is in and what is out)?
• [ ] Success criteria reference specific Key Results?

Consistency

• [ ] Summary aligns with Objective aligns with Key Results?
• [ ] Market segments match the value propositions?
• [ ] Features map to at least one value proposition?
• [ ] Deferred items do not contradict v1 scope?

---

Common PRD Anti-Patterns

1. The Novel -- PRD is 20+ pages. Nobody reads it. Solution: If it is longer than 6 pages, split into multiple PRDs. 2. The Wishlist -- Everything is P0. Solution: Force-rank. Only 3-5 features can be P0. 3. The Solution Looking for a Problem -- Starts with the feature, not the customer need. Solution: Write Sections 3-5 before Section 7. 4. The Vague Objective -- "Improve the user experience." Solution: Attach a number. 5. The Missing Audience -- Written for engineers but shared with executives (or vice versa). Solution: Summary for execs, Details for engineers, same document. 6. The Immortal PRD -- Never updated after initial writing. Solution: Set a review cadence (biweekly during active development). 7. The Assumption-Free Zone -- No assumptions listed, as if the team knows everything. Solution: List at least 3 things you believe but have not proven.