--- 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 ```markdown ## 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 ## 11. Open Questions & Risks - 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 ```markdown ## 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 ```gherkin ## 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 ```markdown 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:** 1. 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?" 2. Categorize responses: Basic, Performance, Delighter, Indifferent 3. 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 ``` --- ## Agile Requirements Management ### Backlog Structure ``` Initiatives — Large strategic bets (12-24 months) Example: "Expand to enterprise market" Epics — Major features (3-6 months) Example: "SSO and enterprise authentication" Stories — User-facing functionality (1-2 weeks) Example: "SAML login for enterprise users" Tasks — Technical implementation (1-3 days) Example: "Set up SAML provider integration" Bugs — Defects to fix (varies) Example: "Login fails on Safari 17" ``` ### Backlog Refinement ``` Cadence: Weekly, 1 hour, mid-sprint Activities: 1. Groom upcoming stories - Add acceptance criteria - Break down large stories - Clarify unknowns 2. Estimate effort - Planning poker or t-shirt sizes - Identify technical risks 3. Prioritize - Apply RICE/MoSCoW - Consider dependencies 4. Definition of Ready - [ ] User story is clear - [ ] Acceptance criteria defined - [ ] Dependencies identified - [ ] Designs available (if needed) - [ ] Estimated by team - [ ] No blocking questions ``` ### Requirements Traceability ``` For regulated industries (healthcare, finance): Requirement ID → User Story → Test Case → Implementation Example: REQ-AUTH-001: "System shall enforce 2FA for admin users" ↓ US-123: "As an admin, I want 2FA to secure my account" ↓ TEST-456: "Verify admin cannot login without 2FA code" ↓ PR-789: Implementation in auth-service Use tools: Jira, Azure DevOps, Modern Requirements ``` --- ## Writing Best Practices ### Be Specific and Quantifiable ``` ❌ Vague: "The app should be fast" ✓ Specific: "Page load time < 2s on 4G, < 500ms on WiFi (p95)" ❌ Vague: "The product should be lightweight" ✓ Specific: "Weight < 500g including battery and accessories" ❌ Vague: "Support many users" ✓ Specific: "Handle 10,000 concurrent users with 99.9% uptime" ``` ### Focus on Problem, Not Solution ``` ❌ Solution-focused: "Add a search bar to the navigation menu" ✓ Problem-focused: "Users can't find products quickly (exit rate 40% on catalog page). They need a way to filter 1000+ products by attributes." → This allows the team to explore multiple solutions: - Search bar - Smart filters - Category navigation - AI recommendations ``` ### Include Context and Rationale ``` For each decision, explain WHY: "We're building password reset via email (not SMS) because: - 95% of users have verified email (only 60% have phone) - Email is free, SMS costs $0.02 per message - Competitors (Stripe, GitHub) use email - SMS has security concerns (SIM swapping)" ``` ### Keep it Concise ``` Use short paragraphs, bullet points, tables ❌ Wall of text: "The user authentication system should support multiple authentication methods including email and password which is the default method that most users will use but we should also support social login via Google and GitHub which are commonly requested features and will reduce friction during signup and we should also consider adding two-factor authentication for security..." ✓ Structured: **Authentication Methods:** - Email + Password (default, 80% of users) - Social login (Google, GitHub) - Two-factor authentication (optional, security-conscious users) **Rationale:** - Reduce signup friction (social login) - Support security best practices (2FA) - Follow industry standards ``` --- ## Collaboration & Tools ### Modern PRD Tools | Tool | Best For | Integration | |------|----------|-------------| | Notion | Customizable templates, collaboration | Slack, GitHub | | Confluence | Enterprise, Jira integration | Jira, BitBucket | | Productboard | User feedback integration, roadmaps | Jira, Intercom | | Linear | Engineering-focused, fast workflow | GitHub, Slack | | Coda | Interactive docs, automation | 3000+ integrations | | Google Docs | Simple, universal access | Drive, Sheets | ### Version Control ``` ✓ Use versioning: v1.0, v1.1, v2.0 ✓ Track changes with comments ✓ Maintain changelog at top of doc ✓ Lock old versions (read-only) ✓ Link to source of truth (Figma, GitHub) Example Changelog: --- ## Changelog **v2.1** (2025-03-15) - Added SAML authentication requirement - Updated success metrics based on A/B test results **v2.0** (2025-03-01) - Simplified scope after engineering review - Removed SMS authentication (moved to v3) **v1.0** (2025-02-15) - Initial PRD --- ``` ### Stakeholder Review ``` Review Process: 1. Draft PRD (PM) 2. Technical feasibility review (Engineering) 3. Design review (Design) 4. Legal/compliance review (if needed) 5. Stakeholder sign-off (Leadership) 6. Publish and socialize Use RACI matrix: - Responsible: PM (writes PRD) - Accountable: Product Lead (final approval) - Consulted: Engineering, Design, Marketing - Informed: Leadership, Support, Sales ``` --- ## Checklist ```markdown ## PRD Quality Check ### Content - [ ] Problem clearly stated - [ ] Goals are measurable and quantifiable - [ ] Target users and personas defined - [ ] User stories follow INVEST criteria - [ ] Acceptance criteria use Given-When-Then - [ ] Out of scope explicitly listed - [ ] Success metrics defined (leading + lagging) ### Technical - [ ] Non-functional requirements included (performance, security) - [ ] Dependencies and integrations identified - [ ] API contracts defined (if applicable) - [ ] Data model changes documented - [ ] Technical risks and mitigations listed ### Design & UX - [ ] Link to design files (Figma, Sketch) - [ ] Accessibility requirements (WCAG 2.2 AA) - [ ] Mobile and desktop specs - [ ] Error states and edge cases designed ### Launch - [ ] Rollout strategy defined (phased, A/B test, feature flags) - [ ] Monitoring and alerts planned - [ ] Rollback plan documented - [ ] Documentation and training planned ### Stakeholders - [ ] Engineering reviewed and estimated - [ ] Design reviewed and approved - [ ] Legal/compliance reviewed (if needed) - [ ] Leadership approved - [ ] All open questions resolved or acknowledged ``` --- ## See Also - [reference/user-stories.md](reference/user-stories.md) — User story writing guide - [reference/prioritization.md](reference/prioritization.md) — Prioritization frameworks - [reference/acceptance-criteria.md](reference/acceptance-criteria.md) — BDD and acceptance criteria patterns - [templates/prd-template.md](templates/prd-template.md) — Copy-paste PRD template