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.

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:

Context -- What is the current state? What exists today?
Why now? -- What changed in the market, technology, or business that makes this urgent?
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:

Jobs addressed -- What tasks or goals does this product help accomplish?
Gains created -- What positive outcomes does the user experience?
Pains relieved -- What frustrations, risks, or obstacles are removed?
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

Gather context: product name, target segment, core problem.
Run scripts/prd_scaffolder.py to generate the skeleton.
Fill in each section using the guidance above and references/prd-writing-guide.md.
Review against the checklist in references/prd-writing-guide.md.
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"`

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

create-prd