product-management

PRD Writing

Write clear, comprehensive Product Requirements Documents with problem statements, success metrics, scope boundaries, and actionable requirements.

prdrequirementsdocumentationproduct

prd-writing/

SKILL.md

Markdown

1
2	# PRD Writing
3
4	## Before you start
5
6	Gather the following information. If any is missing, ask the user before proceeding:
7
8	1. Problem statement — What user pain or business need are we addressing?
9	2. Target users — Which user segments are affected? How many?
10	3. Constraints — Timeline, budget, team size, technical limitations
11	4. Prior art — Has this been attempted before? What happened?
12	5. Stakeholders — Who needs to approve this? Who has opinions?
13
14	If the user only gives you a feature idea ("we need dark mode"), push back and ask for the problem ("what user need does dark mode serve?").
15
16	## PRD template
17
18	Use the following template. Every section is required unless explicitly marked optional.
19
20	---
21
22	### Title
23
24	`[Feature Name] — Product Requirements Document`
25
26	### 1. Problem Statement (2-3 sentences)
27
28	State the problem from the user's perspective. Include:
29	- Who is affected (specific user segment, not "users")
30	- What they're struggling with (observable behavior, not assumed feelings)
31	- How severe and frequent the problem is (data if available)
32
33	Good: "Enterprise customers with 50+ team members report spending 20+ minutes per week manually reassigning tickets when team members go on PTO, leading to SLA breaches in 12% of cases."
34
35	Bad: "Users want better ticket management."
36
37	### 2. Goals & Success Metrics
38
39	Define 2-4 measurable outcomes. Each must have:
40	- A metric name
41	- A current baseline (if known)
42	- A target value
43	- A measurement method
44
45	\| Metric \| Baseline \| Target \| How to measure \|
46	\|--------\|----------\|--------\|----------------\|
47	\| Time to reassign tickets \| 20 min/week \| < 2 min/week \| Avg from activity logs \|
48	\| SLA breach rate \| 12% \| < 3% \| Monthly SLA report \|
49
50	### 3. User Stories
51
52	Write 3-8 user stories in standard format:
53
54	> As a [user type], I want [action] so that [outcome].
55
56	Order by priority. Mark each as P0 (must have), P1 (should have), or P2 (nice to have).
57
58	### 4. Scope
59
60	In scope — List specific capabilities included in this work.
61
62	Out of scope — Explicitly list things that might be assumed but are NOT included. This section prevents scope creep and is as important as the in-scope list.
63
64	Future considerations — Things deliberately deferred to a later phase.
65
66	### 5. Functional Requirements
67
68	Number each requirement. Use RFC 2119 language:
69	- MUST — Non-negotiable for launch
70	- SHOULD — Expected but can be deferred with justification
71	- MAY — Optional enhancement
72
73	```
74	FR-1: The system MUST automatically reassign open tickets when a team member's
75	OOO status is detected via calendar integration.
76	FR-2: The system SHOULD notify the original assignee when their tickets are
77	reassigned.
78	FR-3: The system MAY suggest the best reassignment target based on workload.
79	```
80
81	### 6. Non-Functional Requirements
82
83	Address at minimum:
84	- Performance — Response time, throughput expectations
85	- Scale — Expected volume (users, data, requests)
86	- Security — Auth requirements, data sensitivity, compliance
87	- Accessibility — WCAG level, supported devices
88
89	### 7. Design Considerations (optional)
90
91	UX constraints, existing patterns to follow, key user flows. Reference wireframes or prototypes if they exist. Do NOT design the UI — describe the user outcomes.
92
93	### 8. Open Questions
94
95	List unresolved questions that could change scope or approach. For each:
96	- State the question
97	- Note who can answer it
98	- Flag the decision's impact (blocks implementation? changes scope?)
99
100	### 9. Timeline (optional)
101
102	If the user has provided timeline constraints, include rough milestones. Otherwise, note that engineering will estimate after reviewing the spec.
103
104	---
105
106	## Quality checklist
107
108	Before delivering a PRD, verify:
109
110	- [ ] Problem statement is based on user behavior, not assumed needs
111	- [ ] Every success metric has a baseline and target
112	- [ ] Out-of-scope section explicitly addresses likely scope creep areas
113	- [ ] Requirements use MUST/SHOULD/MAY consistently
114	- [ ] No UI design decisions are made (that's design's job)
115	- [ ] Open questions have owners and impact assessments
116	- [ ] The document can stand alone — someone not in the room could understand it
117
118	## Common mistakes to avoid
119
120	- Writing solutions, not problems. The problem statement should not contain the word "should" or describe a feature. It describes a pain.
121	- Vague success metrics. "Improve user satisfaction" is not a metric. "Increase NPS from 32 to 45 within 3 months" is.
122	- Empty out-of-scope sections. If nothing is out of scope, you haven't thought hard enough. Every feature has adjacent features that could creep in.
123	- Requirements that are actually design. "Add a dropdown menu with..." is design. "The user MUST be able to select from predefined options" is a requirement.
124

product-management

PRD Writing

Write clear, comprehensive Product Requirements Documents with problem statements, success metrics, scope boundaries, and actionable requirements.

prdrequirementsdocumentationproduct

prd-writing/

SKILL.md

Markdown

1
2	# PRD Writing
3
4	## Before you start
5
6	Gather the following information. If any is missing, ask the user before proceeding:
7
8	1. Problem statement — What user pain or business need are we addressing?
9	2. Target users — Which user segments are affected? How many?
10	3. Constraints — Timeline, budget, team size, technical limitations
11	4. Prior art — Has this been attempted before? What happened?
12	5. Stakeholders — Who needs to approve this? Who has opinions?
13
14	If the user only gives you a feature idea ("we need dark mode"), push back and ask for the problem ("what user need does dark mode serve?").
15
16	## PRD template
17
18	Use the following template. Every section is required unless explicitly marked optional.
19
20	---
21
22	### Title
23
24	`[Feature Name] — Product Requirements Document`
25
26	### 1. Problem Statement (2-3 sentences)
27
28	State the problem from the user's perspective. Include:
29	- Who is affected (specific user segment, not "users")
30	- What they're struggling with (observable behavior, not assumed feelings)
31	- How severe and frequent the problem is (data if available)
32
33	Good: "Enterprise customers with 50+ team members report spending 20+ minutes per week manually reassigning tickets when team members go on PTO, leading to SLA breaches in 12% of cases."
34
35	Bad: "Users want better ticket management."
36
37	### 2. Goals & Success Metrics
38
39	Define 2-4 measurable outcomes. Each must have:
40	- A metric name
41	- A current baseline (if known)
42	- A target value
43	- A measurement method
44
45	\| Metric \| Baseline \| Target \| How to measure \|
46	\|--------\|----------\|--------\|----------------\|
47	\| Time to reassign tickets \| 20 min/week \| < 2 min/week \| Avg from activity logs \|
48	\| SLA breach rate \| 12% \| < 3% \| Monthly SLA report \|
49
50	### 3. User Stories
51
52	Write 3-8 user stories in standard format:
53
54	> As a [user type], I want [action] so that [outcome].
55
56	Order by priority. Mark each as P0 (must have), P1 (should have), or P2 (nice to have).
57
58	### 4. Scope
59
60	In scope — List specific capabilities included in this work.
61
62	Out of scope — Explicitly list things that might be assumed but are NOT included. This section prevents scope creep and is as important as the in-scope list.
63
64	Future considerations — Things deliberately deferred to a later phase.
65
66	### 5. Functional Requirements
67
68	Number each requirement. Use RFC 2119 language:
69	- MUST — Non-negotiable for launch
70	- SHOULD — Expected but can be deferred with justification
71	- MAY — Optional enhancement
72
73	```
74	FR-1: The system MUST automatically reassign open tickets when a team member's
75	OOO status is detected via calendar integration.
76	FR-2: The system SHOULD notify the original assignee when their tickets are
77	reassigned.
78	FR-3: The system MAY suggest the best reassignment target based on workload.
79	```
80
81	### 6. Non-Functional Requirements
82
83	Address at minimum:
84	- Performance — Response time, throughput expectations
85	- Scale — Expected volume (users, data, requests)
86	- Security — Auth requirements, data sensitivity, compliance
87	- Accessibility — WCAG level, supported devices
88
89	### 7. Design Considerations (optional)
90
91	UX constraints, existing patterns to follow, key user flows. Reference wireframes or prototypes if they exist. Do NOT design the UI — describe the user outcomes.
92
93	### 8. Open Questions
94
95	List unresolved questions that could change scope or approach. For each:
96	- State the question
97	- Note who can answer it
98	- Flag the decision's impact (blocks implementation? changes scope?)
99
100	### 9. Timeline (optional)
101
102	If the user has provided timeline constraints, include rough milestones. Otherwise, note that engineering will estimate after reviewing the spec.
103
104	---
105
106	## Quality checklist
107
108	Before delivering a PRD, verify:
109
110	- [ ] Problem statement is based on user behavior, not assumed needs
111	- [ ] Every success metric has a baseline and target
112	- [ ] Out-of-scope section explicitly addresses likely scope creep areas
113	- [ ] Requirements use MUST/SHOULD/MAY consistently
114	- [ ] No UI design decisions are made (that's design's job)
115	- [ ] Open questions have owners and impact assessments
116	- [ ] The document can stand alone — someone not in the room could understand it
117
118	## Common mistakes to avoid
119
120	- Writing solutions, not problems. The problem statement should not contain the word "should" or describe a feature. It describes a pain.
121	- Vague success metrics. "Improve user satisfaction" is not a metric. "Increase NPS from 32 to 45 within 3 months" is.
122	- Empty out-of-scope sections. If nothing is out of scope, you haven't thought hard enough. Every feature has adjacent features that could creep in.
123	- Requirements that are actually design. "Add a dropdown menu with..." is design. "The user MUST be able to select from predefined options" is a requirement.
124

PRD Writing

Works well with agents

Works well with skills

PRD Writing

Works well with agents

Works well with skills