|
1
|
--- |
|
2
|
name: product-manager |
|
3
|
description: Create PRDs, product briefs, user stories, and roadmaps with prioritization frameworks. |
|
4
|
--- |
|
5
|
|
|
6
|
# Product Manager |
|
7
|
|
|
8
|
Write PRDs, user stories, and roadmaps. Prioritize features. Default to real templates from top product orgs, not textbook generics. |
|
9
|
|
|
10
|
## When to Use |
|
11
|
|
|
12
|
- PRD, spec, or one-pager needed |
|
13
|
- Backlog prioritization |
|
14
|
|
|
15
|
- User stories + acceptance criteria |
|
16
|
- Roadmap planning |
|
17
|
|
|
18
|
## When NOT to Use |
|
19
|
|
|
20
|
- Technical architecture (core agent capabilities) |
|
21
|
- User research / discovery (design-thinker) |
|
22
|
|
|
23
|
## Discovery — Ask Before You Write |
|
24
|
|
|
25
|
Before choosing a PRD format or writing anything, run a lightweight intake to understand context. Ask the user: |
|
26
|
|
|
27
|
1. **Product stage**: New product/feature, iteration on existing, or pivot? |
|
28
|
2. **Team size and culture**: Startup (5 people, move fast) vs. enterprise (cross-functional, needs alignment)? |
|
29
|
|
|
30
|
3. **Decision this document needs to enable**: Exec go/no-go? Eng scoping? Design kickoff? |
|
31
|
4. **Audience**: Who reads this and what do they need to say yes/no to? |
|
32
|
|
|
33
|
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. |
|
34
|
|
|
35
|
Use the answers to select the right PRD format below. Do not default to the longest template — match format to context. |
|
36
|
|
|
37
|
## Stakeholder Mapping — DACI Matrix |
|
38
|
|
|
39
|
Before writing the PRD, clarify who is involved. Use a DACI matrix (Atlassian/Intuit standard): |
|
40
|
|
|
41
|
```text |
|
42
|
|
|
43
|
| Role | Who | Responsibility | |
|
44
|
|
|
45
|
|------------|------------------|---------------------------------------------| |
|
46
|
|
|
47
|
| Driver | [name/role] | Owns the document, drives decisions forward | |
|
48
|
|
|
49
|
| Approver | [name/role] | Final sign-off authority (one person only) | |
|
50
|
|
|
51
|
| Contributor| [names/roles] | Provides input, reviews, raises concerns | |
|
52
|
|
|
53
|
| Informed | [names/roles] | Kept in the loop, no active role | |
|
54
|
|
|
55
|
``` |
|
56
|
|
|
57
|
**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. |
|
58
|
|
|
59
|
**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." |
|
60
|
|
|
61
|
## PRD Formats — Pick by Context |
|
62
|
|
|
63
|
The three most-copied templates in tech. Ask the user their team size and culture, then pick: |
|
64
|
|
|
65
|
### Amazon PR/FAQ ("Working Backwards") |
|
66
|
|
|
67
|
Write the press release *before* building. Used for every Amazon product since 2004 (AWS, Kindle, Prime). Format: |
|
68
|
|
|
69
|
- **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. |
|
70
|
- **Internal FAQ**: Every hard question a VP would ask. "What's the BOM?" "Why won't [competitor] crush this?" "What's the failure mode?" |
|
71
|
|
|
72
|
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. |
|
73
|
|
|
74
|
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. |
|
75
|
|
|
76
|
**Best for**: Big bets, new product lines, when you need exec alignment before committing eng resources. |
|
77
|
|
|
78
|
### Intercom "Intermission" (1-page hard limit) |
|
79
|
|
|
80
|
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: |
|
81
|
|
|
82
|
- **Problem**: What's broken, why now, links to customer conversations |
|
83
|
- **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." |
|
84
|
|
|
85
|
- **Success criteria**: Qualitative + quantitative |
|
86
|
- **NO solution section** — solutions go in Figma, not the PRD |
|
87
|
|
|
88
|
**Best for**: Feature-level work, fast-moving teams, when scope creep is the enemy. |
|
89
|
|
|
90
|
### Linear's Project Spec |
|
91
|
|
|
92
|
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. |
|
93
|
|
|
94
|
**Best for**: Eng-heavy teams already in Linear, projects with clear shape. |
|
95
|
|
|
96
|
Full template collection: `hustlebadger.com/what-do-product-teams-do/prd-template-examples/` (Figma, Asana, Shape Up, Lenny's 1-Pager all compared). |
|
97
|
|
|
98
|
### Competitive / Market Context Section |
|
99
|
|
|
100
|
Every PRD should include a lightweight competitive scan. Add this section after the problem statement in any format: |
|
101
|
|
|
102
|
```text |
|
103
|
|
|
104
|
## Alternatives & Competitive Landscape |
|
105
|
|
|
106
|
| Alternative | How users solve this today | Key weakness we exploit | |
|
107
|
|
|
108
|
|---------------------|---------------------------|-------------------------------| |
|
109
|
|
|
110
|
| [Competitor/workaround] | [description] | [gap or pain point] | |
|
111
|
|
|
112
|
| [Status quo] | [what they do without us] | [cost, time, error rate] | |
|
113
|
|
|
114
|
``` |
|
115
|
|
|
116
|
If the user needs a deeper analysis, reference the `competitive-analysis` secondary skill. |
|
117
|
|
|
118
|
### Cross-template patterns (from analysis of 13+ company PRDs) |
|
119
|
|
|
120
|
1. Problem strictly before solution — every high-performing template enforces this |
|
121
|
2. Explicit "Non-goals" section — second most common element |
|
122
|
|
|
123
|
3. Living docs — version + changelog, not write-once |
|
124
|
|
|
125
|
## Scope Estimation |
|
126
|
|
|
127
|
Effort estimates feed into RICE and roadmap sequencing. Use one of these approaches depending on maturity: |
|
128
|
|
|
129
|
### T-shirt sizing (early stage, low confidence) |
|
130
|
|
|
131
|
When detailed estimates are unreliable, use relative sizing: |
|
132
|
|
|
133
|
```text |
|
134
|
|
|
135
|
| Size | Rough meaning | Example | |
|
136
|
|
|
137
|
|------|--------------------------------------|----------------------------------| |
|
138
|
|
|
139
|
| XS | < 1 day, one person | Copy change, config tweak | |
|
140
|
|
|
141
|
| S | 1-3 days, one person | New API endpoint, simple UI page | |
|
142
|
|
|
143
|
| M | 1-2 weeks, 1-2 people | Feature with frontend + backend | |
|
144
|
|
|
145
|
| L | 2-4 weeks, small team | Multi-screen flow, new integration| |
|
146
|
|
|
147
|
| XL | 1+ month, cross-functional | New product area, platform change| |
|
148
|
|
|
149
|
``` |
|
150
|
|
|
151
|
### Reference-class estimation (higher confidence) |
|
152
|
|
|
153
|
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). |
|
154
|
|
|
155
|
### Rules for estimation |
|
156
|
|
|
157
|
- Always estimate in ranges, not points: "2-4 weeks" not "3 weeks" |
|
158
|
- Include all functions in the estimate (PM + design + eng + QA), not just eng |
|
159
|
|
|
160
|
- Explicitly flag unknowns that could blow up the estimate — these become "Open questions" in the PRD |
|
161
|
|
|
162
|
## Prioritization |
|
163
|
|
|
164
|
**RICE** (Intercom's framework — the de facto standard): |
|
165
|
|
|
166
|
- **Reach**: Users affected per quarter. Use real numbers from analytics, not guesses. |
|
167
|
- **Impact**: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal |
|
168
|
|
|
169
|
- **Confidence**: 100% = data-backed, 80% = strong intuition, 50% = guessing. This multiplier is what makes RICE better than ICE — it punishes wishful thinking. |
|
170
|
- **Effort**: Person-months, all functions (PM + design + eng + QA) |
|
171
|
|
|
172
|
- Score = (R × I × C) / E. Build as a spreadsheet — agent can generate CSV. |
|
173
|
|
|
174
|
**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). |
|
175
|
|
|
176
|
**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). |
|
177
|
|
|
178
|
**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. |
|
179
|
|
|
180
|
## Roadmap Format |
|
181
|
|
|
182
|
Now / Next / Later (GOV.UK popularized this — intentionally vague on dates to avoid roadmap-as-contract): |
|
183
|
|
|
184
|
```text |
|
185
|
|
|
186
|
## Theme: [one strategic bet this quarter] |
|
187
|
|
|
188
|
## Goal/OKR link: [which company or team OKR does this theme serve?] |
|
189
|
|
|
190
|
### Now (committed, in flight) |
|
191
|
|
|
192
|
| Initiative | Owner | Goal/OKR link | Success metric | Status | |
|
193
|
|
|
194
|
### Next (committed, not started) |
|
195
|
|
|
196
|
| Initiative | Why now | Goal/OKR link | Dependency | |
|
197
|
|
|
198
|
### Later (directional, not committed) |
|
199
|
|
|
200
|
- [bullets only — dates here are lies] |
|
201
|
|
|
202
|
``` |
|
203
|
|
|
204
|
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. |
|
205
|
|
|
206
|
Public roadmap examples to reference: `github.com/github/roadmap` (GitHub's own), Buffer's transparent roadmap, Linear's changelog. |
|
207
|
|
|
208
|
## Acceptance Criteria |
|
209
|
|
|
210
|
Gherkin syntax (Given/When/Then) — directly executable as test cases: |
|
211
|
|
|
212
|
```text |
|
213
|
|
|
214
|
Given [precondition] |
|
215
|
|
|
216
|
When [action] |
|
217
|
|
|
218
|
Then [observable result] |
|
219
|
|
|
220
|
And [additional result] |
|
221
|
|
|
222
|
``` |
|
223
|
|
|
224
|
One scenario per acceptance criterion. If you can't write it as Given/When/Then, the requirement is ambiguous. |
|
225
|
|
|
226
|
## Living Document Workflow |
|
227
|
|
|
228
|
PRDs are not write-once artifacts. Include this header in every PRD: |
|
229
|
|
|
230
|
```text |
|
231
|
|
|
232
|
--- |
|
233
|
|
|
234
|
Version: [1.0] |
|
235
|
|
|
236
|
Last updated: [date] |
|
237
|
|
|
238
|
Status: [Draft | In Review | Approved | Superseded] |
|
239
|
|
|
240
|
Owner: [Driver from DACI] |
|
241
|
|
|
242
|
--- |
|
243
|
|
|
244
|
### Changelog |
|
245
|
|
|
246
|
| Version | Date | Author | Change summary | |
|
247
|
|
|
248
|
|---------|------------|--------|-----------------------------------| |
|
249
|
|
|
250
|
| 1.0 | YYYY-MM-DD | [name] | Initial draft | |
|
251
|
|
|
252
|
| 1.1 | YYYY-MM-DD | [name] | Added success metrics from review | |
|
253
|
|
|
254
|
``` |
|
255
|
|
|
256
|
**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. |
|
257
|
|
|
258
|
## Output Formats |
|
259
|
|
|
260
|
Default output is markdown. Adapt format when it serves the user better: |
|
261
|
|
|
262
|
- **RICE scoring table**: Generate as CSV when the user wants to import into a spreadsheet or share with stakeholders |
|
263
|
- **Roadmap**: Markdown table for docs, CSV for spreadsheet import |
|
264
|
|
|
265
|
- **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 |
|
266
|
|
|
267
|
## Limitations |
|
268
|
|
|
269
|
- Cannot integrate with Jira/Linear/Asana — deliver as markdown for copy-paste |
|
270
|
- Cannot access user analytics — ask user for reach/retention numbers before RICE scoring |
|
271
|
|
|
272
|
- Templates are starting points; teams should adapt |