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)

Discovery — Ask Before You Write

Before choosing a PRD format or writing anything, run a lightweight intake to understand context. Ask the user:

1. Product stage: New product/feature, iteration on existing, or pivot?

2. Team size and culture: Startup (5 people, move fast) vs. enterprise (cross-functional, needs alignment)?

3. Decision this document needs to enable: Exec go/no-go? Eng scoping? Design kickoff?

4. Audience: Who reads this and what do they need to say yes/no to?

5. Competitive landscape: Are there direct competitors or alternatives the user is aware of? Reference the

   competitive-analysis

   secondary skill if the user needs a deeper market scan before writing the PRD.

Use the answers to select the right PRD format below. Do not default to the longest template — match format to context.

Stakeholder Mapping — DACI Matrix

Before writing the PRD, clarify who is involved. Use a DACI matrix (Atlassian/Intuit standard):

| Role | Who | Responsibility |

|------------|------------------|---------------------------------------------|

| Driver | [name/role] | Owns the document, drives decisions forward |

| Approver | [name/role] | Final sign-off authority (one person only) |

| Contributor| [names/roles] | Provides input, reviews, raises concerns |

| Informed | [names/roles] | Kept in the loop, no active role |

Rules: Exactly one Approver. Driver is usually the PM. If there are more than 3 Contributors, the scope is probably too broad — split the PRD.

Best for: Amazon PR/FAQ (where exec alignment is the goal), any cross-functional project, or when the user says "I need buy-in from multiple teams."

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

Competitive / Market Context Section

Every PRD should include a lightweight competitive scan. Add this section after the problem statement in any format:

## Alternatives & Competitive Landscape

| Alternative | How users solve this today | Key weakness we exploit |

|---------------------|---------------------------|-------------------------------|

| [Competitor/workaround] | [description] | [gap or pain point] |

| [Status quo] | [what they do without us] | [cost, time, error rate] |

If the user needs a deeper analysis, reference the

competitive-analysis

secondary skill.

Cross-template patterns (from analysis of 13+ company PRDs)

1. Problem strictly before solution — every high-performing template enforces this

2. Explicit "Non-goals" section — second most common element

3. Living docs — version + changelog, not write-once

Scope Estimation

Effort estimates feed into RICE and roadmap sequencing. Use one of these approaches depending on maturity:

T-shirt sizing (early stage, low confidence)

When detailed estimates are unreliable, use relative sizing:

| Size | Rough meaning | Example |

|------|--------------------------------------|----------------------------------|

| XS | < 1 day, one person | Copy change, config tweak |

| S | 1-3 days, one person | New API endpoint, simple UI page |

| M | 1-2 weeks, 1-2 people | Feature with frontend + backend |

| L | 2-4 weeks, small team | Multi-screen flow, new integration|

| XL | 1+ month, cross-functional | New product area, platform change|

Reference-class estimation (higher confidence)

Compare to similar past work. Ask the user: "What shipped feature is this most similar to? How long did that take?" Adjust from there. This outperforms bottom-up estimation for novel work (Kahneman & Tversky's "planning fallacy" research).

Rules for estimation

• Always estimate in ranges, not points: "2-4 weeks" not "3 weeks"

• Include all functions in the estimate (PM + design + eng + QA), not just eng

• Explicitly flag unknowns that could blow up the estimate — these become "Open questions" in the PRD

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]

## Goal/OKR link: [which company or team OKR does this theme serve?]

### Now (committed, in flight)

| Initiative | Owner | Goal/OKR link | Success metric | Status |

### Next (committed, not started)

| Initiative | Why now | Goal/OKR link | Dependency |

### Later (directional, not committed)

- [bullets only — dates here are lies]

Every roadmap item should trace back to a goal or OKR. If an item doesn't link to any goal, it's either a missing goal or a distraction — surface this to the user.

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.

Living Document Workflow

PRDs are not write-once artifacts. Include this header in every PRD:

---

Version: [1.0]

Last updated: [date]

Status: [Draft | In Review | Approved | Superseded]

Owner: [Driver from DACI]

---

### Changelog

| Version | Date | Author | Change summary |

|---------|------------|--------|-----------------------------------|

| 1.0 | YYYY-MM-DD | [name] | Initial draft |

| 1.1 | YYYY-MM-DD | [name] | Added success metrics from review |

Review cadence: Recommend the user revisit the PRD at each major milestone — after design review, after eng scoping, and after launch. Update status and log changes.

Output Formats

Default output is markdown. Adapt format when it serves the user better:

• RICE scoring table: Generate as CSV when the user wants to import into a spreadsheet or share with stakeholders

• Roadmap: Markdown table for docs, CSV for spreadsheet import

• Connected tools: Check if the workspace has project management integrations (Linear, Jira, etc.) via the

  integrations

  skill. If connected, format output to match the tool's conventions (e.g., Linear project spec format for Linear users) and mention that items can be copied into their tool

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