| name | product-manager |
| description | Create PRDs, write user stories, prioritize features, and plan product roadmaps. |
Product Manager
Write PRDs, user stories, and roadmaps. Prioritize features. Default to real templates from top product orgs, not textbook generics.
When to Use
- PRD, spec, or one-pager needed
- Backlog prioritization
- User stories + acceptance criteria
- Roadmap planning
When NOT to Use
- Technical architecture (core agent capabilities)
- User research / discovery (design-thinker)
PRD Formats — Pick by Context
The three most-copied templates in tech. Ask the user their team size and culture, then pick:
Amazon PR/FAQ ("Working Backwards")
Write the press release before building. Used for every Amazon product since 2004 (AWS, Kindle, Prime). Format:
- Press release (1 page, strict): Headline (
[Company] announces [product] to enable [customer] to [benefit]), sub-headline, dated intro paragraph, problem paragraph (3-4 problems max), solution paragraph, customer quote, how to get started.
- Internal FAQ: Every hard question a VP would ask. "What's the BOM?" "Why won't [competitor] crush this?" "What's the failure mode?"
Why it works: the press-release frame forces customer language and ruthlessly exposes when you can't articulate the benefit. If the PR is boring, the product probably is too.
Source templates: Colin Bryar (ex-Bezos chief of staff) at coda.io/@colin-bryar/working-backwards, Ian McAllister's LinkedIn template, github.com/Green-Software-Foundation/pr-faqs for a real org using PR/FAQ on GitHub.
Best for: Big bets, new product lines, when you need exec alignment before committing eng resources.
Intercom "Intermission" (1-page hard limit)
Paul Adams (VP Product): "An Intermission must always fit on a printed A4 page. If it does not, you haven't a clear enough view of the problem yet." Sections:
- Problem: What's broken, why now, links to customer conversations
- Job Stories (Intercom invented these — replaces user stories):
When [situation], I want to [motivation], so I can [expected outcome]. Situation > persona. "When I'm on-call at 3am and an alert fires" beats "As a DevOps engineer."
- Success criteria: Qualitative + quantitative
- NO solution section — solutions go in Figma, not the PRD
Best for: Feature-level work, fast-moving teams, when scope creep is the enemy.
Linear's Project Spec
Nan Yu (Head of Product at Linear). Short, outcome-focused: Problem → Proposed solution → Success metrics → Non-goals → Open questions. Non-goals are load-bearing — explicitly listing what you're not building is the single most effective scope-creep prevention.
Best for: Eng-heavy teams already in Linear, projects with clear shape.
Full template collection: hustlebadger.com/what-do-product-teams-do/prd-template-examples/ (Figma, Asana, Shape Up, Lenny's 1-Pager all compared).
Cross-template patterns (from analysis of 13+ company PRDs)
- Problem strictly before solution — every high-performing template enforces this
- Explicit "Non-goals" section — second most common element
- Living docs — version + changelog, not write-once
Prioritization
RICE (Intercom's framework — the de facto standard):
- Reach: Users affected per quarter. Use real numbers from analytics, not guesses.
- Impact: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal
- Confidence: 100% = data-backed, 80% = strong intuition, 50% = guessing. This multiplier is what makes RICE better than ICE — it punishes wishful thinking.
- Effort: Person-months, all functions (PM + design + eng + QA)
- Score = (R × I × C) / E. Build as a spreadsheet — agent can generate CSV.
When NOT to use RICE: When effort estimates are garbage (early-stage), when one item is existential (just do it), when the list is >30 items (you have a strategy problem, not a prioritization problem).
Cost of Delay / WSJF (SAFe framework): (User value + Time criticality + Risk reduction) / Job size. Better than RICE when timing/sequencing matters (regulatory deadlines, market windows).
Kano: Survey users on each feature twice — "how would you feel if we had this?" and "how would you feel if we didn't?" Cross-tab reveals Basic/Performance/Delighter/Indifferent. Reference: foldingburritos.com/blog/kano-model for the full method + survey template.
Roadmap Format
Now / Next / Later (GOV.UK popularized this — intentionally vague on dates to avoid roadmap-as-contract):
## Theme: [one strategic bet this quarter]
### Now (committed, in flight)
| Initiative | Owner | Success metric | Status |
### Next (committed, not started)
| Initiative | Why now | Dependency |
### Later (directional, not committed)
- [bullets only — dates here are lies]
Public roadmap examples to reference: github.com/github/roadmap (GitHub's own), Buffer's transparent roadmap, Linear's changelog.
Acceptance Criteria
Gherkin syntax (Given/When/Then) — directly executable as test cases:
Given [precondition]
When [action]
Then [observable result]
And [additional result]
One scenario per acceptance criterion. If you can't write it as Given/When/Then, the requirement is ambiguous.
Limitations
- Cannot integrate with Jira/Linear/Asana — deliver as markdown for copy-paste
- Cannot access user analytics — ask user for reach/retention numbers before RICE scoring
- Templates are starting points; teams should adapt
