| name | prd-master |
| description | PRD writing and product definition expert. Use when writing PRDs, user stories, acceptance criteria, or prioritizing features. Covers RICE/MoSCoW frameworks, agile requirements, and specification best practices. |
PRD Master
Core Principles
- Living Document — PRDs evolve throughout product lifecycle
- Stakeholder Collaboration — Early involvement prevents late rework
- Measurable Goals — Replace vague with quantifiable targets
- Focused yet Flexible — Lean structure enables adaptation
- Problem-First — Define the problem before jumping to solutions
- User-Centered — Ground decisions in user research and data
Hard Rules (Must Follow)
These rules are mandatory. Violating them means the skill is not working correctly.
No Vague Metrics
All metrics and requirements must be quantifiable. Vague descriptions are forbidden.
❌ FORBIDDEN:
- "The app should be fast"
- "Support many users"
- "Good user experience"
- "The system should be reliable"
- "Easy to use interface"
✅ REQUIRED:
- "Page load time < 2s on 4G, < 500ms on WiFi (P95)"
- "Support 10,000 concurrent users with 99.9% uptime"
- "NPS > 50, Task completion rate > 85%"
- "99.9% availability, MTTR < 1 hour"
- "User can complete checkout in < 3 clicks"
Problem Before Solution
Never propose a solution without clearly defining the problem first.
❌ FORBIDDEN:
"We should add a search bar to the navigation"
✅ REQUIRED:
"Problem: Users can't find products quickly (40% exit rate on catalog).
They need a way to filter 1000+ products by attributes.
Proposed solutions: search bar, smart filters, AI recommendations."
INVEST-Compliant Stories
All user stories must pass the INVEST criteria checklist.
❌ FORBIDDEN:
- Dependent stories that can't be delivered independently
- Stories without acceptance criteria
- Stories too large to complete in one sprint
- Stories without clear user value
✅ REQUIRED:
- [ ] Independent — Can be delivered alone
- [ ] Negotiable — Details can be discussed
- [ ] Valuable — Clear user/business value
- [ ] Estimable — Team can estimate effort
- [ ] Small — Fits in one sprint
- [ ] Testable — Has acceptance criteria
Quick Reference
When to Use What
| Scenario | Approach | Tool/Framework |
|---|
| Feature prioritization | Scoring model | RICE, ICE |
| Release planning | Must/Should/Could/Won't | MoSCoW |
| Customer satisfaction | Delight vs basics | Kano Model |
| Sprint planning | User stories + BDD | Given-When-Then |
| Complex requirements | Traditional PRD | Full template |
| Agile iteration | Lean requirements | User stories + acceptance criteria |
PRD Structure
Essential Components
## 1. Executive Summary
- Problem statement (2-3 sentences)
- Proposed solution (1-2 sentences)
- Success metrics (3-5 key metrics)
## 2. Context & Background
- Why now? Market opportunity or user pain
- Strategic alignment with company goals
- What happens if we don't build this?
## 3. Goals & Success Metrics
- Business objectives (revenue, retention, growth)
- User objectives (satisfaction, engagement)
- Success criteria (quantifiable targets)
## 4. Target Users & Personas
- Primary users (who benefits most?)
- Secondary users (indirect beneficiaries)
- User needs, pain points, motivations
- Jobs to be done
## 5. User Stories & Use Cases
- Core user flows
- Edge cases and error scenarios
- Integration with existing features
## 6. Requirements
- Functional requirements (what it does)
- Non-functional requirements (performance, security)
- Acceptance criteria (how we verify)
## 7. Out of Scope
- What we're explicitly NOT building
- Future considerations for later phases
## 8. Design & UX
- Link to design files (Figma, etc.)
- Key design decisions
- Accessibility requirements (WCAG 2.2 AA)
## 9. Technical Considerations
- Architecture overview
- Dependencies and integrations
- Data model changes
- API contracts
## 10. Rollout & Launch Plan
- Phased rollout strategy
- Feature flags and A/B tests
Monitoring and alerts
Rollback plan
Unknowns requiring research
Technical risks and mitigations
Dependencies on other teams
User Story Writing
Standard Format
As a [persona/role],
I want to [action/goal],
So that [benefit/value].
The Three C's
Card — Brief description on index card
→ Captures essence, not details
→ Placeholder for conversation
Conversation — Discussion between team members
→ Explore edge cases
→ Clarify assumptions
→ Uncover hidden requirements
Confirmation — Acceptance criteria
→ Defines "done"
→ Testable conditions
→ Given-When-Then format
INVEST Criteria
Independent — Story stands alone, minimal dependencies
Negotiable — Details emerge through conversation
Valuable — Delivers value to users or business
Estimable — Team can estimate effort
Small — Completable within one sprint
Testable — Clear acceptance criteria
Examples
## Good User Stories
### Feature: Password Reset
As a user who forgot my password,
I want to reset it via email,
So that I can regain access to my account without contacting support.
**Acceptance Criteria:**
- Given I'm on the login page
- When I click "Forgot Password"
- Then I see a form requesting my email address
- Given I've entered my registered email
- When I submit the form
- Then I receive a password reset link within 2 minutes
- Given I click the reset link within 24 hours
- When I set a new password (min 8 chars, 1 number, 1 symbol)
- Then I'm logged in automatically
### Feature: Bulk Upload
As a content manager,
I want to upload multiple products via CSV,
So that I can save time compared to manual entry.
**Acceptance Criteria:**
- Given I'm on the products page
- When I click "Bulk Upload" and select a CSV file
- Then the system validates the file format (max 10MB, .csv only)
- Given the CSV has 1000 rows
- When I start the upload
- Then I see a progress bar showing completion percentage
- Given the upload completes
- When I view the results
- Then I see: success count, error count, downloadable error report
Common Mistakes
❌ Too technical
"As a user, I want the API to return a 200 status code"
→ Focus on user benefit, not implementation
❌ Too vague
"As a user, I want the system to be fast"
→ Define measurable performance targets
❌ Missing the "so that"
"As a user, I want to filter products by price"
→ Add the value: "so that I can find items within my budget"
❌ Too large (Epic)
"As a user, I want a complete e-commerce checkout experience"
→ Break into smaller stories: cart, address, payment, confirmation
Acceptance Criteria
Given-When-Then (BDD Format)
Given [precondition/context]
When [action/trigger]
Then [expected outcome]
And [additional context/outcome]
Best Practices
✓ Keep scenarios focused (one behavior per scenario)
✓ Maintain clear separation of Given/When/Then
✓ Avoid UI-specific details (test behavior, not implementation)
✓ Make criteria testable and measurable
✓ Include both happy path and edge cases
✓ Use real user interactions, not hypothetical
Examples
## E-commerce Checkout
Scenario: Successful payment with saved card
Given I have items in my cart
And I'm logged in with a saved payment method
When I click "Place Order"
Then I see an order confirmation page
And I receive a confirmation email within 2 minutes
And my cart is emptied
Scenario: Payment declined
Given I'm at the payment step
When I submit payment and the card is declined
Then I see an error message: "Payment declined. Please try another card."
And I remain on the payment page
And my cart items are preserved
Scenario: Session timeout during checkout
Given I've been idle for 30 minutes
When I attempt to place an order
Then I'm redirected to login
And my cart items are preserved after re-authentication
## Search Feature
Scenario: Search with results
Given I'm on the homepage
When I search for "laptop"
Then I see results within 500ms
And results are ranked by relevance
And I see result count: "Showing 1-20 of 156 results"
Scenario: Search with no results
Given I'm on the search page
When I search for "xyznonexistent"
Then I see "No results found for 'xyznonexistent'"
And I see search suggestions or alternative queries
Alternative Format: Checklist
For simpler features, use a checklist:
## File Upload Acceptance Criteria
- [ ] Supports formats: PDF, DOCX, XLSX (max 10MB each)
- [ ] Shows upload progress bar
- [ ] Displays file name and size after upload
- [ ] Allows removal of uploaded files
- [ ] Shows error message for unsupported formats
- [ ] Shows error message for files exceeding size limit
- [ ] Scans files for malware before processing
- [ ] Works on mobile (iOS Safari, Android Chrome)
Prioritization Frameworks
RICE Scoring
RICE Score = (Reach × Impact × Confidence) / Effort
Reach — How many users affected per time period?
(users/quarter, transactions/month)
Impact — How much does it improve their experience?
3 = Massive, 2 = High, 1 = Medium, 0.5 = Low, 0.25 = Minimal
Confidence — How certain are we?
100% = High data, 80% = Medium, 50% = Low
Effort — Person-months required
(engineering + design + PM time)
Example:
| Feature | Reach | Impact | Confidence | Effort | RICE Score |
|---|
| Password reset | 5000/month | 3 | 100% | 1 | 15,000 |
| Dark mode | 10000/month | 0.5 | 80% | 2 | 2,000 |
| Export to PDF | 500/month | 2 | 50% | 0.5 | 1,000 |
When to use: Managing many ideas, need quantitative comparison, have user data.
ICE Scoring
ICE Score = (Impact + Confidence + Ease) / 3
Impact — 1-10: How much business/user value?
Confidence — 1-10: How certain are we?
Ease — 1-10: How easy to implement? (10 = very easy)
Example:
| Feature | Impact | Confidence | Ease | ICE Score |
|---|
| One-click login | 9 | 8 | 6 | 7.7 |
| AI recommendations | 10 | 5 | 3 | 6.0 |
| Email notifications | 6 | 9 | 9 | 8.0 |
When to use: Quick prioritization, weekly grooming, growth experiments, speed over precision.
MoSCoW Method
Must Have — Critical for launch, non-negotiable
Without this, the product fails
Should Have — Important but not vital
Painful to omit, but workarounds exist
Could Have — Nice to have, "vitamins not painkillers"
Include if time/resources allow
Won't Have — Explicitly out of scope
Defer to future releases
Example: MVP E-commerce Site
| Must Have | Should Have | Could Have | Won't Have |
|---|
| Product listing | Product reviews | Wishlist | AR try-on |
| Shopping cart | Related products | Gift wrapping | Live chat |
| Checkout | Order tracking | Discount codes | Loyalty program |
| Payment (Stripe) | Email receipts | Social sharing | Mobile app |
| User accounts | Guest checkout | Product comparison | Subscriptions |
When to use: Sprint planning, MVP scoping, release boundaries, stakeholder alignment.
Kano Model
Basic Needs — Must-haves, assumed by users
Absence = dissatisfaction, presence = neutral
Example: Website loads, checkout works
Performance — More is better, linear satisfaction
Example: Faster page load, more payment options
Delighters — Unexpected features that wow
Absence = neutral, presence = delight
Example: Free shipping, personalized recommendations
Indifferent — Users don't care either way
Example: Animated logo, theme customization
When to use: Customer-driven decisions, balancing basics vs innovation, UX improvements.
Process:
- Survey users with paired questions:
- "How would you feel if we HAD feature X?"
- "How would you feel if we DIDN'T have feature X?"
- Categorize responses: Basic, Performance, Delighter, Indifferent
- Prioritize: Cover basics first, then performance, then delighters
Hybrid Approach
Best practice: Combine frameworks
1. Use MoSCoW to define release scope
→ Separate must-haves from nice-to-haves
2. Use RICE to rank must-haves
→ Sequence within release based on impact
3. Use Kano to ensure balance
→ Don't over-invest in basics, under-invest in delight
Example:
- All "Must Have" items → Score with RICE → Build in RICE order
- Validate with Kano → Ensure we have delighters, not just basics
Extended Reference
Detailed material starting at ## Agile Requirements Management has been moved to reference/extended.md to keep this skill concise. Load that reference when the task requires the moved examples, command catalogs, checklists, platform details, or implementation templates.
