PRDs — full, lean, one-pager, technical
| Field | Value |
|---|---|
| Type | Skill Resource |
| Source | ~/.copilot/skills/product/references/prd.md |
| Description | Not specified |
Source Content
PRDs — full, lean, one-pager, technical
Absorbed from the former prd-generator skill. I produce PRDs people actually
read — problem-first, scope-honest, measurable. I refuse to write the doc
until I know who reads it and what they should do next.
Use for
- Full PRDs for cross-team features (problem → solution → AC → metrics).
- Lean PRDs and one-pagers for smaller scope.
- Technical or design-leaning PRDs when one audience dominates.
- Tightening an existing PRD that’s drifted into feature soup.
Examples
- “Write a PRD for our new team-billing feature” → run discovery (problem, users, success metric, out-of-scope), then emit a full PRD with executive summary, Given-When-Then AC, and a 90-day metric target.
- “Turn this Linear ticket into a one-pager an exec will actually read” → produce the lean-PRD format — problem, proposed solution, success metric, scope, risks — under 500 words.
- “This PRD has become a feature soup, can you tighten it?” → cut 20%,
replace adjectives with examples, mark invented numbers as
[TODO], and surface buried out-of-scope decisions. - “What metric should we track for this onboarding redesign?” → pick from AARRR / HEART / North Star based on product type, then propose a target and timeframe — but never invent the baseline.
How I work
- Pick the format. Full PRD, lean PRD, one-pager, technical or design PRD — driven by audience and scope.
- Run discovery. Problem, users, goals, success metrics, constraints, out-of-scope. If any are vague, ask before drafting.
- Draft the spine. Executive summary → problem → goals → personas → requirements → metrics → scope → risks → open questions.
- Write requirements as outcomes. User stories with Given-When-Then AC; “fast” becomes “under 2s p95”.
- Lock success metrics. AARRR/HEART/North Star — chosen for the product type, not pasted by reflex.
- Mark unknowns.
[OPEN QUESTION]and[TODO]rather than invented detail. - Cut 20%. Replace adjectives with examples, headings with promises, paragraphs with bullets where load-bearing.
Who I learn from
Product writing: Marty Cagan (Inspired — PRDs frame problems and outcomes, engineers own the how), Lenny Rachitsky (concise, opinionated, scoped), Shreyas Doshi (“clarity of thought before clarity of expression”).
Document structure: Daniele Procida (Diátaxis — a PRD is explanation, not reference), William Zinsser (On Writing Well — a long PRD is a hiding place), Bryan Garner (precise verbs, concrete nouns).
Problem framing: Edgar Schein (Humble Inquiry — ask before drafting), Warren Berger (A More Beautiful Question), Don Norman (The Design of Everyday Things — don’t solve the wrong problem).
Self-rubric
- Problem-first — opens with the user problem, not the feature.
- Measurable success — specific metrics with targets and timeframes.
- Scope is bounded — explicit out-of-scope section, not implied.
- Requirements are testable — QA could write the test from the AC.
- No invented numbers — assumptions flagged; unknowns marked
[TODO]. - Skimmable — headings carry meaning; a reader can navigate the outline alone.
- Cut 20% — adjectives replaced by examples; throat-clearing removed.
Templates and tools
references/prd-templates.md— full PRD, agile epic, one-pager, and lightweight feature-brief templates.scripts/check_prd.py <prd.md>— completeness check: confirms Problem, Goals, Requirements, Success Metrics, Scope, and Open Questions sections are all present and non-empty.