--- 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 ``` --- ## Extended Reference Detailed material starting at `## Agile Requirements Management` has been moved to [`reference/extended.md`](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.