Prd Master

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

---

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

## 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

## 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:

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:

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

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` to keep this skill concise. Load that reference when the task requires the moved examples, command catalogs, checklists, platform details, or implementation templates.

Acceptance Criteria Patterns

Overview

Acceptance criteria define the conditions that a feature must satisfy to be considered complete. They serve as a contract between the product team and development team, ensuring shared understanding of what "done" means.

---

Why Acceptance Criteria Matter

Benefits

For Product Managers:
✓ Clear definition of scope
✓ Prevents scope creep
✓ Basis for feature acceptance
✓ Requirements traceability

For Developers:
✓ Clear implementation guidance
✓ Testable conditions
✓ Reduces ambiguity
✓ Enables TDD/BDD

For QA:
✓ Test case foundation
✓ Coverage checklist
✓ Edge case identification
✓ Automation scenarios

For Stakeholders:
✓ Shared understanding
✓ Transparent progress
✓ Realistic expectations

---

Given-When-Then Format (BDD)

Structure:

Given [precondition/context]
When [action/trigger]
Then [expected outcome]

And [additional context/outcome]
But [exception/constraint]

Core Principles

Given: Preconditions

Purpose: Set the stage, establish context

What to include:

• User state (logged in, has items in cart)
• System state (database populated, API available)
• Environmental conditions (mobile device, slow connection)

Tips:

✓ Focus on relevant preconditions only
✓ Use real, concrete scenarios
✗ Don't include unnecessary context
✗ Don't describe how to set up the state

Examples:

✓ Given I'm logged in as a premium user
✓ Given I have 3 items in my shopping cart
✓ Given the product "Laptop Pro" is out of stock
✓ Given I'm on a mobile device with 3G connection

✗ Given I navigate to the login page, enter my credentials, click submit
   (Too detailed, this is the setup, not the precondition)

When: Action/Trigger

Purpose: Describe the user action or system event

What to include:

• Single, specific action
• User interaction (click, submit, swipe)
• System event (timeout, webhook received)

Tips:

✓ One action per When clause
✓ Use active voice
✗ Don't describe multiple actions
✗ Don't include implementation details

Examples:

✓ When I click "Add to Cart"
✓ When I submit the payment form
✓ When the session expires after 30 minutes
✓ When I swipe left on the notification

✗ When I click the blue button in the top-right corner
   (Too UI-specific, what if design changes?)

✗ When I click "Search" and enter "laptop" and press enter
   (Too many actions, split into separate scenarios)

Then: Expected Outcome

Purpose: Define observable results

What to include:

• What the user sees/experiences
• System state changes
• Messages, notifications, navigation
• Performance criteria

Tips:

✓ Make it testable and measurable
✓ Focus on user-observable outcomes
✗ Don't specify internal implementation
✗ Don't be vague or subjective

Examples:

✓ Then I see "Item added to cart" confirmation
✓ Then my cart count increases by 1
✓ Then I'm redirected to the checkout page
✓ Then the page loads within 2 seconds

✗ Then the database is updated
   (Internal detail, not user-observable)

✗ Then the user has a good experience
   (Too vague, not testable)

Complete Examples

Example 1: Login

Scenario: Successful login with valid credentials
  Given I'm on the login page
  And I'm not currently logged in
  When I enter email "user@example.com"
  And I enter password "SecurePass123"
  And I click "Login"
  Then I'm redirected to my dashboard
  And I see "Welcome back, John!"
  And the session persists for 30 days

Scenario: Failed login with invalid password
  Given I'm on the login page
  When I enter email "user@example.com"
  And I enter an incorrect password
  And I click "Login"
  Then I remain on the login page
  And I see error message "Invalid email or password"
  And the password field is cleared
  And my account is not locked (< 5 failed attempts)

Scenario: Account lockout after multiple failed attempts
  Given I have failed to login 4 times in the last hour
  When I enter incorrect password again
  And I click "Login"
  Then I see error message "Account locked for 1 hour due to multiple failed attempts"
  And I see link "Reset password"
  And the login form is disabled

Example 2: E-commerce Checkout

Scenario: Successful payment with credit card
  Given I have 3 items in my cart totaling $150
  And I'm logged in with a saved shipping address
  When I click "Proceed to Checkout"
  And I select "Credit Card" as payment method
  And I enter valid credit card details
  And I click "Place Order"
  Then I see order confirmation page with order number
  And I receive confirmation email within 2 minutes
  And my cart is emptied
  And my credit card is charged $150
  And order status is "Processing"

Scenario: Payment declined
  Given I'm at the payment step with $150 order
  When I enter credit card details
  And I click "Place Order"
  And the payment is declined by the bank
  Then I remain on the payment page
  And I see error "Payment declined. Please try another card or payment method."
  And my cart items are preserved
  And no charge is made
  And no order is created

Scenario: Session timeout during checkout
  Given I'm at the payment step
  And I've been idle for 30 minutes
  When I click "Place Order"
  Then I'm redirected to login page
  And I see message "Your session expired. Please log in to continue."
  And my cart items are preserved
  And I'm redirected back to checkout after successful login

Example 3: Search Functionality

Scenario: Search with results
  Given I'm on the homepage
  And the product database has 1000+ products
  When I enter "laptop" in the search box
  And I press Enter
  Then I see search results page within 500ms
  And I see "Showing 1-20 of 156 results for 'laptop'"
  And results are sorted by relevance (default)
  And each result shows: image, title, price, rating

Scenario: Search with no results
  Given I'm on the search page
  When I search for "xyznonexistent12345"
  Then I see "No results found for 'xyznonexistent12345'"
  And I see "Try different keywords or check spelling"
  And I see suggested popular searches
  And I don't see any product results

Scenario: Search with filters applied
  Given I've searched for "laptop"
  And I see 156 results
  When I select price range "$500-$1000"
  And I select brand "Dell"
  Then results update without page reload
  And I see "Showing 1-12 of 32 results"
  And all results match both filters
  And selected filters are highlighted

---

The "Three Amigos" Practice

Participants:

• Product Owner (business perspective)
• Developer (technical perspective)
• Tester (quality perspective)

Process:

1. Review user story together
2. Discuss scenarios and examples
3. Identify edge cases
4. Write acceptance criteria collaboratively
5. Confirm shared understanding

Benefits:
✓ Catches ambiguities early
✓ Multiple perspectives ensure completeness
✓ Shared ownership of quality
✓ Reduces rework

Example Session:

Story: Password Reset

Product Owner: "Users should be able to reset password via email"

Developer: "What if the email doesn't exist in our system?"
→ Add scenario for invalid email

Tester: "What if they click the reset link after 24 hours?"
→ Add scenario for expired link

Developer: "What about rate limiting? Can they request 100 resets?"
→ Add scenario for rate limiting (max 3 per hour)

Tester: "What if they're already logged in?"
→ Add scenario for logged-in state

Product Owner: "Do we require specific password complexity?"
→ Add criteria for password requirements

Result: 5 scenarios covering happy path + edge cases

---

Best Practices

1. Keep Scenarios Focused

❌ Complex scenario with multiple behaviors:
Given I'm logged in
When I add item to cart
And I update quantity to 3
And I remove another item
And I apply discount code
And I proceed to checkout
Then... [complex validation]

✓ Split into focused scenarios:

Scenario 1: Add item to cart
Scenario 2: Update item quantity
Scenario 3: Remove item from cart
Scenario 4: Apply discount code
Scenario 5: Checkout with discount

Why: Easier to test, debug, and maintain

2. Maintain Clear Separation of Given/When/Then

❌ Blurred separation:
Given I'm on the login page
When I enter credentials and click login
Then I'm logged in

✓ Clear separation:
Given I'm on the login page
When I enter valid credentials
And I click "Login"
Then I'm redirected to dashboard
And I see "Welcome back, [Name]"
And session cookie is set for 30 days

Why: Clearer intent, better for automation, easier to understand

3. Avoid UI-Specific Details

❌ Too UI-specific:
Then I see a blue button labeled "Submit" in the bottom-right corner
And there's a spinner icon when loading
And the font is 16px Helvetica

✓ Behavior-focused:
Then I see confirmation "Order placed successfully"
And I can download invoice as PDF
And order appears in "Order History"

Why: UI can change, behavior should remain stable

4. Include Edge Cases and Error Scenarios

Don't just test the happy path!

For any feature, consider:
✓ Success case (happy path)
✓ Validation errors
✓ Network failures
✓ Timeouts
✓ Permission issues
✓ Concurrent users
✓ Edge inputs (empty, max length, special characters)

Example: File Upload

Scenario: Successful file upload
  Given I'm on the upload page
  When I select a PDF file (2MB)
  And I click "Upload"
  Then I see upload progress bar
  And I see "Upload complete" within 5 seconds
  And file appears in my documents list

Scenario: Upload file exceeding size limit
  Given I'm on the upload page
  When I select a file larger than 10MB
  And I click "Upload"
  Then I see error "File too large. Maximum size is 10MB."
  And the file is not uploaded
  And I remain on the upload page

Scenario: Upload unsupported file type
  Given I'm on the upload page
  When I select an .exe file
  And I click "Upload"
  Then I see error "Unsupported file type. Please upload PDF, DOCX, or XLSX."
  And the file is not uploaded

Scenario: Upload fails due to network error
  Given I'm uploading a file
  When the network connection is lost mid-upload
  Then I see error "Upload failed. Please check your connection and try again."
  And I can retry the upload
  And the partial upload is cleaned up

Scenario: Malware detected in uploaded file
  Given I'm uploading a file
  When the file is scanned and malware is detected
  Then I see error "This file contains malware and cannot be uploaded."
  And the file is quarantined
  And security team is notified

5. Make Criteria Measurable and Testable

❌ Vague:
Then the page loads quickly
Then the user has a good experience
Then the design looks nice

✓ Measurable:
Then the page loads within 2 seconds (p95)
Then I see search results with >90% relevance
Then all elements pass WCAG 2.2 AA contrast requirements

6. Use Real Data and Examples

❌ Abstract:
Given I have some items in my cart
When I checkout
Then I see the total price

✓ Concrete:
Given I have 2 "Laptop Pro" ($999 each) in my cart
And I have 1 "Mouse" ($29) in my cart
When I proceed to checkout
Then I see subtotal: $2,027
And I see tax (8%): $162.16
And I see total: $2,189.16

Why: Concrete examples are easier to verify and automate

7. Cover Multiple User Roles

Different users may have different acceptance criteria:

Scenario: Admin can delete any comment
  Given I'm logged in as an admin
  When I view any user's comment
  Then I see "Delete" button
  And I can delete the comment
  And the user is notified

Scenario: Regular user can only delete own comments
  Given I'm logged in as a regular user
  When I view my own comment
  Then I see "Delete" button
  But when I view another user's comment
  Then I don't see "Delete" button

---

Alternative Formats

Rule-Oriented Format

For complex business rules, use a table:

Feature: Shipping Cost Calculation

| Order Total | Shipping Method | Destination | Shipping Cost |
|-------------|-----------------|-------------|---------------|
| $0-$25      | Standard        | US          | $5.99         |
| $0-$25      | Express         | US          | $12.99        |
| $25-$100    | Standard        | US          | $3.99         |
| $25-$100    | Express         | US          | $9.99         |
| $100+       | Standard        | US          | Free          |
| $100+       | Express         | US          | $6.99         |
| Any         | Any             | International| $19.99       |

Scenario: Calculate shipping for $30 order
  Given I have $30 worth of items in cart
  And I'm shipping to US address
  When I select "Standard Shipping"
  Then I see shipping cost: $3.99

Checklist Format

For simpler features, a checklist may be sufficient:

## File Upload Acceptance Criteria

### Functional
- [ ] Supports file types: PDF, DOCX, XLSX
- [ ] Maximum file size: 10MB
- [ ] Shows upload progress bar (0-100%)
- [ ] Displays file name and size after upload
- [ ] Allows removing uploaded files before submission
- [ ] Scans files for malware before processing

### Validation & Errors
- [ ] Shows error for unsupported file types
- [ ] Shows error for files exceeding size limit
- [ ] Shows error for network failures with retry option
- [ ] Clears partially uploaded files on error

### Performance
- [ ] Upload completes within 10 seconds for 10MB file (WiFi)
- [ ] Supports multiple file uploads (up to 5 at once)

### Security
- [ ] Files are scanned for viruses/malware
- [ ] Files are stored with randomized names
- [ ] Only authenticated users can upload
- [ ] Files are encrypted at rest

### Accessibility
- [ ] Keyboard accessible (tab navigation, enter to select)
- [ ] Screen reader announces upload progress
- [ ] Error messages are read by screen readers
- [ ] Works with browser accessibility tools

### Cross-browser/Device
- [ ] Works on Chrome, Firefox, Safari, Edge (latest 2 versions)
- [ ] Works on iOS Safari and Android Chrome
- [ ] Responsive design (mobile, tablet, desktop)

---

BDD Tools & Automation

Gherkin Syntax

Gherkin is the language used for BDD scenarios:

Feature: User Login
  As a registered user
  I want to log in to my account
  So that I can access my personalized dashboard

  Background:
    Given the application is running
    And the database is seeded with test users

  Scenario: Successful login
    Given I'm on the login page
    When I enter username "john@example.com"
    And I enter password "SecurePass123"
    And I click "Login"
    Then I should see "Welcome back, John!"
    And I should be on the dashboard page

  Scenario Outline: Login with invalid credentials
    Given I'm on the login page
    When I enter username "<username>"
    And I enter password "<password>"
    And I click "Login"
    Then I should see error "<error_message>"

    Examples:
      | username            | password      | error_message              |
      | invalid@example.com | SecurePass123 | Invalid email or password  |
      | john@example.com    | wrongpass     | Invalid email or password  |
      |                     | SecurePass123 | Email is required          |
      | john@example.com    |               | Password is required       |

Automation Tools

Example: Cucumber.js

// features/login.feature
Feature: User Login

  Scenario: Successful login
    Given I'm on the login page
    When I enter email "user@example.com"
    And I enter password "SecurePass123"
    And I click "Login"
    Then I should see "Welcome back"

// features/step_definitions/login.steps.js
const { Given, When, Then } = require('@cucumber/cucumber');
const { expect } = require('chai');

Given('I\'m on the login page', async function() {
  await this.page.goto('https://example.com/login');
});

When('I enter email {string}', async function(email) {
  await this.page.fill('input[name="email"]', email);
});

When('I enter password {string}', async function(password) {
  await this.page.fill('input[name="password"]', password);
});

When('I click {string}', async function(buttonText) {
  await this.page.click(`button:has-text("${buttonText}")`);
});

Then('I should see {string}', async function(text) {
  const content = await this.page.textContent('body');
  expect(content).to.include(text);
});

---

When NOT to Use Given-When-Then

GWT is not always the right format:

1. System-Level Requirements

❌ Given the system is deployed
When the server receives 10,000 requests/second
Then response time is < 100ms

✓ Better format:
Performance requirement: System must handle 10,000 req/s with p95 latency < 100ms

2. Non-Functional Requirements

❌ Given the user uploads a file
When malware is detected
Then the file is quarantined

✓ Better format:
Security requirement: All uploaded files must be scanned for malware before storage

3. Simple UI/UX Constraints

❌ Given I'm viewing a button
When the button is focused
Then it has a 2px blue outline

✓ Better format:
Accessibility: All interactive elements must have visible focus indicator (WCAG 2.2)

4. Technical Implementation Details

❌ Given the database is initialized
When a user record is created
Then it's stored in the users table with encrypted password

✓ Better format:
Technical requirement: User passwords must be hashed using bcrypt (cost factor 12)

---

Templates

Basic Template

Scenario: [Descriptive name]
  Given [precondition]
  When [action]
  Then [expected result]

Extended Template

Scenario: [Descriptive name]
  Given [precondition 1]
  And [precondition 2]
  When [action 1]
  And [action 2]
  Then [expected result 1]
  And [expected result 2]
  But [exception or constraint]

Scenario Outline Template

Scenario Outline: [Descriptive name with variable]
  Given [precondition with <variable>]
  When [action with <variable>]
  Then [expected result with <variable>]

  Examples:
    | variable1 | variable2 | variable3 |
    | value1    | value2    | value3    |
    | value4    | value5    | value6    |

---

Checklist

## Acceptance Criteria Quality Check

### Format & Structure
- [ ] Uses Given-When-Then format (or appropriate alternative)
- [ ] Clear separation of precondition, action, outcome
- [ ] One behavior per scenario
- [ ] Concrete examples, not abstract descriptions

### Coverage
- [ ] Happy path covered
- [ ] Error scenarios covered
- [ ] Edge cases identified
- [ ] Different user roles considered
- [ ] Performance criteria specified (if applicable)
- [ ] Security requirements included (if applicable)

### Clarity
- [ ] Testable and measurable
- [ ] No UI-specific implementation details
- [ ] Uses real data and examples
- [ ] Understandable by all team members
- [ ] No ambiguous language

### Technical
- [ ] Can be automated
- [ ] No blurred Given/When/Then boundaries
- [ ] Realistic scenarios (grounded in actual use)
- [ ] Linked to user story
- [ ] Reviewed by Three Amigos (PO, Dev, QA)

---

Common Pitfalls

1. Implementation in Acceptance Criteria

❌ Then the API returns HTTP 200 with JSON payload containing user_id

✓ Then I see my profile information displayed correctly

2. Too Many Steps

❌ When I click A, then B, then C, then D, then E...

✓ Break into multiple scenarios

3. Vague Outcomes

❌ Then the user is happy
❌ Then it works correctly

✓ Then I see confirmation message "Order placed successfully"
✓ Then the order appears in "Order History" with status "Processing"

4. Missing Error Cases

❌ Only writing happy path

✓ Include: validation errors, timeouts, permission denied, etc.

5. Coupling to Current UI

❌ Then I see a modal dialog with a blue "OK" button

✓ Then I see confirmation dialog with option to proceed or cancel

---

See Also

• reference/user-stories.md — User story writing guide
• templates/prd-template.md — Complete PRD template
• BDD documentation: https://cucumber.io/docs/bdd/
• Gherkin syntax: https://cucumber.io/docs/gherkin/

prd-master Extended Reference

This file preserves detailed material moved out of SKILL.md for progressive disclosure. Load it only when the current task needs the specific examples, commands, templates, or checklists below.

Moved content starts at: ## Agile Requirements Management.

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

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

## 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 — User story writing guide
• reference/prioritization.md — Prioritization frameworks
• reference/acceptance-criteria.md — BDD and acceptance criteria patterns
• templates/prd-template.md — Copy-paste PRD template

Prioritization Frameworks

Overview

Product prioritization is the process of determining the relative importance of features, projects, or initiatives to decide what to build next. Different frameworks suit different contexts, team sizes, and decision types.

---

Framework Comparison

---

RICE Framework

Developed by: Intercom

Formula:

RICE Score = (Reach × Impact × Confidence) / Effort

Components

Reach

Definition: How many people will this affect within a given time period?

Measurement:

• Users per quarter
• Transactions per month
• Pageviews per week

Example:

Feature: Password reset email
Reach = 5,000 users/quarter (estimated forgot password requests)

Feature: Dark mode
Reach = 50,000 users/quarter (all active users)

Feature: Export to PDF
Reach = 500 users/quarter (power users only)

Tips:

• Use real data from analytics when possible
• For new features, estimate conservatively
• Define time period consistently (per quarter recommended)

Impact

Definition: How much will this improve the outcome per person affected?

Scale:

3     = Massive impact
2     = High impact
1     = Medium impact
0.5   = Low impact
0.25  = Minimal impact

Examples:

Massive (3):
- Core product functionality (can't use product without it)
- Major conversion improvement (50%+ increase)
- Critical security fix

High (2):
- Significant UX improvement
- Notable performance increase (2x faster)
- Important compliance requirement

Medium (1):
- Moderate convenience improvement
- Incremental feature enhancement
- Nice-to-have functionality

Low (0.5):
- Small polish
- Minor optimization
- Rarely used edge case

Minimal (0.25):
- Cosmetic change
- Vanity metric improvement
- Internal tooling nice-to-have

Tips:

• Focus on user/business value, not effort
• Consider both immediate and long-term impact
• Be honest about incremental vs transformative changes

Confidence

Definition: How confident are you in your estimates?

Scale:

100%  = High confidence (strong data, validated assumptions)
80%   = Medium confidence (some data, reasonable estimates)
50%   = Low confidence (hypotheses, gut feel)

Examples:

High (100%):
- Feature request from 1000+ users
- A/B test showed 30% improvement
- Competitor has this and it's highly rated
- We have analytics data supporting need

Medium (80%):
- Feedback from 50+ users
- Industry best practice
- Small pilot test showed promise
- Reasonable assumptions based on similar features

Low (50%):
- Speculative new market
- Unvalidated hypothesis
- No clear precedent
- Gut feeling from stakeholders

Tips:

• Lower confidence for uncertain reach or impact
• Never use confidence to inflate weak ideas
• If confidence < 50%, consider research spike first

Effort

Definition: Total time investment from all team members

Measurement:

• Person-months (1 person working full-time for 1 month)
• Include: engineering, design, PM, QA, marketing

Examples:

0.5 person-months:
- Simple UI change, no backend work
- Adding a new field to existing form
- Basic content update

1 person-month:
- Small feature with frontend + backend
- Integration with existing API
- New dashboard page

2 person-months:
- Medium feature across multiple components
- New integration requiring coordination
- Performance optimization project

4+ person-months:
- Major new feature area
- Platform migration
- Multi-team coordination required

Tips:

• Include all roles (not just engineering)
• Account for testing, docs, deployment
• Round up for uncertainty
• Break down if >6 person-months

Example Calculation

Feature: One-click Reorder

Reach: 10,000 customers/quarter
  → Active customers who have ordered before
  → Analytics show 40% reorder within 3 months

Impact: 2 (High)
  → Significantly reduces friction for repeat purchases
  → Expected to increase reorder rate by 25%
  → Competitive feature (Amazon has it)

Confidence: 80%
  → Customer survey showed strong interest (n=200)
  → We have data on reorder frequency
  → Implementation is straightforward (similar to "Add to Cart")

Effort: 1.5 person-months
  → 1 month engineering (frontend + backend)
  → 0.25 month design
  → 0.25 month PM + QA

RICE Score = (10,000 × 2 × 0.8) / 1.5 = 10,667

RICE Scoring Table

When to Use RICE

✓ Managing a large backlog (50+ features)
✓ Need quantitative comparison across diverse features
✓ Have access to user analytics and data
✓ Want to reduce bias in prioritization
✓ Building data-driven prioritization culture

✗ Very early stage (no usage data)
✗ Need immediate decision (too slow)
✗ Features are incomparable (different products/markets)

---

ICE Framework

Developed by: Sean Ellis (Growth Hacking)

Formula:

ICE Score = (Impact + Confidence + Ease) / 3

Components

Impact (1-10)

How much will this move the needle on your goals?

10: Game-changer, 10x improvement
8-9: Major improvement, 2-5x better
6-7: Significant improvement, 50-100% better
4-5: Moderate improvement, 20-50% better
2-3: Small improvement, 5-20% better
1: Minimal improvement, <5% better

Confidence (1-10)

How sure are you this will work?

10: Proven (we've done this before, or competitor has)
8-9: Strong evidence (user research, A/B test results)
6-7: Good indicators (analytics, customer feedback)
4-5: Educated guess (industry best practices)
2-3: Hypothesis (logical but unproven)
1: Wild guess (pure speculation)

Ease (1-10)

How easy is this to implement?

10: Trivial (config change, < 1 day)
8-9: Very easy (< 1 week, no dependencies)
6-7: Easy (1-2 weeks, minor coordination)
4-5: Moderate (2-4 weeks, some complexity)
2-3: Difficult (1-2 months, coordination needed)
1: Very difficult (3+ months, major effort)

Example Calculation

Experiment: Add testimonials to pricing page

Impact: 7
  → Could increase conversions by 30-50%
  → Testimonials proven to build trust
  → Pricing page is high-traffic (10k/month)

Confidence: 8
  → We have customer testimonials ready
  → Competitor analysis shows this works
  → Social proof is well-documented tactic

Ease: 9
  → Just need to add HTML/CSS
  → Testimonials already collected
  → No backend work needed
  → Can ship in 2 days

ICE Score = (7 + 8 + 9) / 3 = 8.0

ICE Scoring Table

When to Use ICE

✓ Growth experiments and A/B tests
✓ Weekly backlog grooming
✓ Quick prioritization decisions
✓ Limited data available
✓ Speed matters more than precision
✓ Small, scrappy teams

✗ Complex, multi-year projects
✗ Need precise cost analysis
✗ Regulatory/compliance decisions

---

MoSCoW Method

Developed by: Dai Clegg (Oracle)

Acronym:

M = Must Have
S = Should Have
C = Could Have
W = Won't Have (this time)

Categories

Must Have

Definition: Non-negotiable requirements. Without these, the product fails or cannot launch.

Questions to ask:

• Can we launch without this?
• What's the impact if we don't include it?
• Is this a legal/regulatory requirement?
• Does this deliver core value proposition?

Examples:

E-commerce MVP:
✓ Product catalog
✓ Shopping cart
✓ Checkout and payment
✓ Order confirmation
✓ User authentication

Reason: Can't run an e-commerce site without these

Warning: Resist putting everything here. Typically 60% of features at most.

Should Have

Definition: Important but not vital. Painful to omit, but workarounds exist.

Questions to ask:

• Is there a workaround if we skip this?
• Can we deliver value without it?
• Does this significantly improve the experience?

Examples:

E-commerce MVP:
✓ Product reviews
✓ Order tracking
✓ Email receipts
✓ Related product recommendations
✓ Wishlist

Reason: Valuable but not critical for launch. Can add in Phase 2.

Typical allocation: ~20% of features

Could Have

Definition: Nice to have. "Vitamins, not painkillers." Include only if time/resources allow.

Questions to ask:

• Does this delight users but isn't expected?
• Can we easily add this later?
• Is this more about "nice" than "necessary"?

Examples:

E-commerce MVP:
✓ Gift wrapping option
✓ Product comparison tool
✓ Social media sharing
✓ Save for later
✓ Advanced filters

Reason: Enhances experience but not expected in MVP

Typical allocation: ~10% of features

Won't Have

Definition: Explicitly out of scope for this release. Defer to future.

Questions to ask:

• Is this a future enhancement?
• Does this belong in a different product?
• Is this too ambitious for current timeline?

Examples:

E-commerce MVP:
✗ Augmented reality try-on
✗ Live chat support
✗ Loyalty points program
✗ Subscription boxes
✗ Mobile app (web-only for MVP)
✗ International shipping

Reason: Too complex for MVP, but potentially valuable later

Purpose: Setting expectations, preventing scope creep

MoSCoW Template

## MVP: E-commerce Platform

### Must Have (Critical for Launch)
- [ ] User registration and login
- [ ] Product catalog with search
- [ ] Shopping cart functionality
- [ ] Checkout flow (address, payment)
- [ ] Order confirmation and email
- [ ] Basic admin panel for product management
- [ ] Payment processing (Stripe)
- [ ] SSL and basic security

**Launch Blocker:** Cannot ship without these

### Should Have (Important but Not Critical)
- [ ] Product reviews and ratings
- [ ] Order history
- [ ] Order tracking integration
- [ ] Guest checkout (no account needed)
- [ ] Product image zoom
- [ ] Email marketing integration
- [ ] Discount codes

**Justification:** Significantly improve experience, but MVP functional without

### Could Have (Nice to Have)
- [ ] Wishlist functionality
- [ ] Product comparison
- [ ] Social sharing
- [ ] Gift wrapping options
- [ ] Advanced search filters (brand, price range, etc.)
- [ ] Save addresses for faster checkout
- [ ] Product recommendations

**Justification:** Polish features, can add post-launch based on feedback

### Won't Have (Future Phases)
- [ ] Mobile app (web responsive only)
- [ ] Live chat support
- [ ] Loyalty/rewards program
- [ ] Subscription/recurring orders
- [ ] AR virtual try-on
- [ ] International shipping (US only for MVP)
- [ ] Multi-language support

**Justification:** Out of scope for initial launch, revisit in Q3-Q4

When to Use MoSCoW

✓ Sprint planning
✓ MVP scoping
✓ Release planning
✓ Stakeholder alignment (manage expectations)
✓ Time-boxed projects with fixed deadlines
✓ When you need clear go/no-go decisions

✗ Too many features to categorize (use RICE instead)
✗ Need quantitative prioritization
✗ All features feel critical (forces hard choices)

MoSCoW Best Practices

1. Timebox the release
   "This is our 3-month MVP timeline"

2. Set percentages
   Max 60% Must, 20% Should, 20% Could

3. Be ruthless with "Must Have"
   If you can launch without it, it's not a Must

4. Document "Won't Have" clearly
   Prevents re-litigation and scope creep

5. Revisit after each release
   Today's "Won't Have" might be tomorrow's "Must Have"

---

Kano Model

Developed by: Noriaki Kano (1984)

Purpose: Categorize features by their effect on customer satisfaction

Categories

                    Satisfaction
                         ↑
                         |
        Delighters       |
              ___---'''  |
         _---''          |
    _---'                |
___/_____________________|___________________→ Implementation
                         |    ___---'''
                         |_---''  Performance
                     _---'
                 _---
             _---'     Basic Needs

Basic Needs (Must-Haves)

Characteristics:

• Assumed by users, not explicitly requested
• Absence = dissatisfaction
• Presence = neutral (expected)
• Threshold: must meet minimum standard

Examples:

Website:
- Site loads (doesn't crash)
- Checkout works
- Secure payment processing
- Mobile responsive

Hotel:
- Clean room
- Hot water
- WiFi
- Safe environment

Car:
- Brakes work
- Doors lock
- Engine starts

Implication: Must deliver these, but investing beyond minimum doesn't increase satisfaction.

Performance Needs (Satisfiers)

Characteristics:

• More is better (linear relationship)
• Absence = dissatisfaction
• Presence = satisfaction
• Competitive differentiator

Examples:

Website:
- Page load speed (faster = better)
- Product selection (more = better)
- Payment options (more = better)
- Customer service response time (faster = better)

Hotel:
- Room size (bigger = better)
- Breakfast options (more = better)
- Check-in speed (faster = better)

Car:
- Fuel efficiency (better MPG = better)
- Cargo space (more = better)
- Horsepower (more = better)

Implication: Invest strategically. Balance cost vs satisfaction gain.

Delighters (Exciters)

Characteristics:

• Unexpected features that wow
• Absence = neutral (not expected)
• Presence = high satisfaction
• Novelty fades over time (becomes performance/basic)

Examples:

Website:
- Free shipping
- Personalized recommendations
- Surprise discount at checkout
- Proactive support (before you ask)

Hotel:
- Welcome drink
- Room upgrade
- Handwritten note
- Local recommendations

Car:
- Heated steering wheel
- Panoramic sunroof
- Self-parking
- Massage seats

Implication: Creates competitive advantage and brand loyalty. But expensive to maintain as they become expected.

Indifferent

Characteristics:

• Users don't care either way
• No impact on satisfaction

Examples:

Website:
- Animated logo
- Excessive theme customization
- Social media share count
- Company history timeline

Hotel:
- Hotel mascot
- Corporate mission statement in room
- Lobby art installation

Car:
- Engine sound customization
- Ambient lighting (for many users)

Implication: Don't invest resources here. Remove or deprioritize.

Kano Survey Method

Question Pairs:

For each feature, ask two questions:

Functional (feature present):
"How would you feel if we HAD [feature]?"

Dysfunctional (feature absent):
"How would you feel if we DIDN'T have [feature]?"

Answer choices:
1. I like it
2. I expect it
3. I'm neutral
4. I can tolerate it
5. I dislike it

Mapping Responses:

Example Survey:

Feature: Free 2-day shipping

Q1 (Functional): How would you feel if we offered free 2-day shipping?
User response: "I like it"

Q2 (Dysfunctional): How would you feel if we DIDN'T offer free 2-day shipping?
User response: "I expect it"

Result: Performance feature (linear satisfaction)

---

Feature: Handwritten thank-you note with order

Q1 (Functional): How would you feel if you received a handwritten thank-you note?
User response: "I like it"

Q2 (Dysfunctional): How would you feel if you didn't receive one?
User response: "I'm neutral"

Result: Delighter (unexpected, creates delight)

Using Kano for Prioritization

1. Basic Needs
   Priority: Must deliver (P0)
   Investment: Minimum viable

   ✓ Ensure all basic needs met
   ✗ Don't over-invest beyond threshold

2. Performance Needs
   Priority: Competitive parity (P1)
   Investment: Strategic, data-driven

   ✓ Match or exceed competitors
   ✓ Measure ROI (satisfaction gain vs cost)

3. Delighters
   Priority: Differentiation (P2)
   Investment: Selective, high-impact

   ✓ Choose 2-3 signature delighters
   ✓ Monitor as they become expected over time
   ⚠ Delighters fade → Performance → Basic

4. Indifferent
   Priority: Remove or defer (P3)
   Investment: None

   ✓ Eliminate to reduce complexity
   ✓ Free up resources for delighters

When to Use Kano

✓ Customer-driven product decisions
✓ Balancing must-haves vs innovation
✓ UX improvements
✓ Competitive differentiation strategy
✓ Long-term roadmap planning

✗ Early MVP (insufficient users to survey)
✗ Urgent decisions (too slow)
✗ Internal tools (different stakeholders)

---

Value vs Effort Matrix

Format: 2x2 matrix

        High Value
            ↑
     Quick Wins │ Major Projects
    (Do First)  │  (Plan Carefully)
    ────────────┼────────────────→ High Effort
     Fill-Ins   │  Money Pits
    (Do Later)  │  (Avoid)
            ↓
        Low Value

Quadrants

Quick Wins (High Value, Low Effort)

Priority: Do immediately Examples:

• Fix critical bug
• Add missing "Forgot Password" link
• Enable Google Analytics
• Simple UI copy improvements

Strategy: Ship fast, measure impact

Major Projects (High Value, High Effort)

Priority: Plan carefully, allocate resources Examples:

• Build new product line
• Platform migration
• Redesign checkout flow
• International expansion

Strategy: Break into phases, validate assumptions, long-term commitment

Fill-Ins (Low Value, Low Effort)

Priority: Do when capacity available Examples:

• Update footer links
• Add tooltips
• Minor visual polish
• Internal tooling improvements

Strategy: Good for onboarding new team members, downtime between projects

Money Pits (Low Value, High Effort)

Priority: Avoid or deprioritize Examples:

• Over-engineered solutions
• Gold-plating existing features
• Rarely requested features
• Vanity projects

Strategy: Eliminate, or find ways to reduce effort

Example Matrix

Feature Mapping:

Quick Wins:
- Add "Save for Later" button (2 days, high request)
- Fix slow product search (3 days, impacts 80% users)
- Email order confirmations (1 week, expected feature)

Major Projects:
- Mobile app (6 months, 40% of traffic is mobile)
- Recommendation engine (3 months, proven to increase AOV)
- International shipping (4 months, TAM expansion)

Fill-Ins:
- Dark mode (1 week, 10% request rate)
- Social media sharing (3 days, low usage expected)
- Advanced filters (1 week, power users only)

Money Pits:
- Custom product configurator (3 months, <5% use case)
- Gamification (2 months, unproven value)
- AR try-on (4 months, insufficient hardware adoption)

When to Use Value vs Effort

✓ Visual communication with stakeholders
✓ Quick prioritization exercises
✓ Workshops and brainstorming
✓ Portfolio management (balance quick wins vs big bets)

✗ Precise quantitative comparison
✗ Many similar features (hard to plot)
✗ Complex multi-dimensional decisions

---

Cost of Delay (CD3)

Purpose: Quantify the cost of not shipping a feature

Formula:

CD3 Score = (User Value + Time Value + Risk Reduction) / Duration

Where:
- User Value: Impact on users (1-10)
- Time Value: Time sensitivity (1-10)
- Risk Reduction: Reduces business risk (1-10)
- Duration: Time to implement (months)

When to Use

✓ Time-sensitive features (compliance deadlines, seasonal)
✓ Opportunity cost matters
✓ Trade-offs between speed and quality

Example:
Feature A: Low urgency, build in 3 months
Feature B: High urgency (competitor launched), build in 1 month

Even if A has higher value, B's time sensitivity may make it higher priority.

---

Weighted Scoring

Purpose: Custom multi-criteria prioritization

Setup

1. Define criteria (3-7 factors)
   Example:
   - User value (0-10)
   - Business value (0-10)
   - Strategic alignment (0-10)
   - Technical feasibility (0-10)
   - Effort (0-10, inverted)

2. Assign weights (must sum to 100%)
   Example:
   - User value: 30%
   - Business value: 30%
   - Strategic alignment: 20%
   - Technical feasibility: 10%
   - Effort: 10%

3. Score each feature
   Weighted Score = Σ (Score × Weight)

Example

When to Use

✓ Complex decisions with multiple stakeholders
✓ Need to balance competing priorities
✓ Custom criteria (beyond standard frameworks)
✓ Transparent decision-making process

✗ Simple decisions (overkill)
✗ Fast-moving environments (too slow)

---

Combining Frameworks

Recommended Hybrid Approach

1. Use MoSCoW to define release scope
   → Separate must-haves from nice-to-haves
   → Set clear boundaries

2. Use RICE to rank must-haves
   → Quantitative comparison within release
   → Data-driven sequencing

3. Use ICE for quick experiments
   → Weekly grooming of growth backlog
   → Fast iteration cycle

4. Use Kano to validate balance
   → Ensure we have basics, performance, delighters
   → Don't over-invest in basics
   → Include some wow factors

Example:
- All "Must Have" → Score with RICE → Build in RICE order
- "Should Have" → Use ICE for quick wins
- Validate with Kano → Are we delighting users or just checking boxes?

---

Best Practices

1. Be Consistent

✓ Use same framework for comparable items
✓ Define metrics clearly upfront
✓ Document assumptions

✗ Don't mix frameworks arbitrarily
✗ Don't change scoring mid-process

2. Update Regularly

Prioritization is not one-time:
- Weekly: Groom backlog, add new items
- Monthly: Re-score top priorities
- Quarterly: Revisit framework, adjust weights

3. Include Stakeholders

✓ PM leads, but doesn't decide alone
✓ Engineering estimates effort
✓ Design validates user value
✓ Leadership confirms strategic alignment
✓ Customers validate through research

4. Accept Imperfection

"All models are wrong, but some are useful"

✓ Frameworks guide decisions, don't make them
✓ Use judgment for ties or edge cases
✓ Be transparent about trade-offs

5. Document Decisions

For each prioritized feature:
- Score/category
- Rationale
- Assumptions
- Date decided
- Who decided

This creates accountability and learning for future decisions.

---

Checklist

## Prioritization Process

### Preparation
- [ ] Define decision scope (what are we prioritizing?)
- [ ] Choose appropriate framework(s)
- [ ] Gather necessary data (analytics, user research)
- [ ] Identify stakeholders for input

### Execution
- [ ] Score or categorize each feature
- [ ] Document assumptions and rationale
- [ ] Review for bias or gaps
- [ ] Validate with stakeholders

### Output
- [ ] Ranked or categorized backlog
- [ ] Clear next steps (what to build first)
- [ ] Documented trade-offs
- [ ] Communicated to team

### Review
- [ ] Schedule regular re-prioritization
- [ ] Track accuracy of estimates
- [ ] Adjust framework if needed
- [ ] Learn from outcomes

User Story Writing Guide

Overview

User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability. They follow the format:

As a [persona/role],
I want to [action/goal],
So that [benefit/value].

User stories are intentionally brief because they're meant to spark detailed discussions between the development team, product owner, and stakeholders.

---

The Three C's Framework

1. Card

The "Card" represents the physical or digital card containing the user story statement. Originally, Agile teams wrote stories on index cards to emphasize their simplicity and portability.

Purpose:

• Placeholder for conversation
• Quick reference during planning
• Easy to reorganize and prioritize

Example Card:

As a returning customer,
I want one-click reordering of past purchases,
So that I can save time on frequent orders.

2. Conversation

The "Conversation" is the most critical element. User stories are brief because detailed requirements emerge through discussion.

Key conversations:

• Why is this valuable to users?
• What are the edge cases?
• What are the technical constraints?
• How does this integrate with existing features?
• What happens when things go wrong?

Example Discussion Points:

Story: One-click reordering

Questions to discuss:
- Q: How far back in order history can users reorder?
- A: Last 12 months, up to 100 most recent orders

- Q: What if an item is out of stock?
- A: Show substitution suggestions or remove from cart with notification

- Q: Do we modify quantities or use original order exactly?
- A: Use original, but allow editing before checkout

- Q: How do we handle price changes?
- A: Show current price, indicate if different from original order

3. Confirmation

The "Confirmation" involves the acceptance criteria that define when a story is complete.

Format: Given-When-Then (see acceptance-criteria.md)

Example:

Acceptance Criteria:

Given I'm viewing my order history
When I click "Reorder" on a past order
Then all available items are added to my cart
And out-of-stock items show substitution suggestions
And I see a summary: "12 items added, 2 unavailable"

Given items in my cart from reorder
When I proceed to checkout
Then I see current prices (with indicators if changed)
And I can edit quantities before payment

---

INVEST Criteria

Good user stories follow INVEST principles:

Independent

Stories should stand alone with minimal dependencies on other stories.

❌ Dependent:
Story 1: "Create user profile database table"
Story 2: "Add user profile UI" (depends on Story 1)

✓ Independent:
"As a user, I want to create and edit my profile"
(Implementation details emerge in conversation)

Negotiable

Details are flexible and emerge through conversation. Stories are not rigid contracts.

❌ Too prescriptive:
"As a user, I want a blue button in the top-right corner that opens
a modal dialog with a form containing Name, Email, and Bio fields
limited to 500 characters with a Save button that calls POST /api/profile"

✓ Negotiable:
"As a user, I want to update my profile information (name, email, bio)
so that others can learn about me"

→ UI design and implementation details are discussed later

Valuable

Every story must deliver value to users or the business.

❌ No clear value:
"As a developer, I want to refactor the authentication module"

✓ Valuable:
"As a user, I want faster login (< 2s) so I can access my account quickly"

Note: Technical work is valid but frame it in terms of user/business value

Estimable

The team must be able to estimate the effort required.

❌ Too vague to estimate:
"As a user, I want the system to be intelligent"

✓ Estimable:
"As a user, I want product recommendations based on my browsing history"

If story is not estimable:
- Break it down into smaller stories
- Do a spike/research story first
- Clarify unknowns through conversation

Small

Stories should be completable within one sprint (typically 1-2 weeks).

❌ Too large (Epic):
"As a customer, I want a complete e-commerce checkout experience"

✓ Small stories:
- "As a customer, I want to add items to my shopping cart"
- "As a customer, I want to enter shipping address"
- "As a customer, I want to select payment method"
- "As a customer, I want to review order before purchase"
- "As a customer, I want to receive order confirmation"

Testable

Clear acceptance criteria make stories testable.

❌ Not testable:
"As a user, I want a good search experience"

✓ Testable:
"As a user, I want search results within 500ms
with at least 90% relevance for common queries"

Acceptance criteria:
- Given I search for "laptop"
- When results load
- Then I see results within 500ms (p95)
- And top 5 results match "laptop" category

---

User Story Templates

Standard Template

As a [persona/role],
I want to [action/goal],
So that [benefit/value].

Job-to-be-Done Template

When [situation],
I want to [action],
So I can [outcome].

Example:

When I'm shopping for gifts during the holidays,
I want to filter by price range and recipient age,
So I can quickly find appropriate gifts within budget.

Feature-Driven Template

In order to [benefit],
As a [persona/role],
I want [action/goal].

Example:

In order to reduce cart abandonment,
As a product manager,
I want to offer guest checkout without account creation.

---

Examples by Domain

E-commerce

Story: Guest Checkout
As a first-time visitor,
I want to checkout without creating an account,
So that I can complete my purchase quickly.

Acceptance Criteria:
- Given I have items in cart and I'm not logged in
- When I click "Checkout"
- Then I see option: "Continue as Guest" or "Login"
- And I can complete purchase with just email, shipping, payment
- And I receive confirmation email with order tracking

---

Story: Wishlist
As a registered user,
I want to save items to a wishlist,
So that I can purchase them later or share with others.

Acceptance Criteria:
- Given I'm viewing a product
- When I click "Add to Wishlist" (heart icon)
- Then the item is saved to my wishlist
- And I can view all wishlist items on dedicated page
- And I can share wishlist via unique URL
- And I can move items from wishlist to cart

SaaS Application

Story: SSO Integration
As an enterprise admin,
I want to enable Single Sign-On via SAML,
So that my team can access the app using company credentials.

Acceptance Criteria:
- Given I'm an account admin
- When I navigate to Settings > Authentication
- Then I can upload SAML metadata XML or enter IdP URL
- And I can test connection before enabling
- And I can require SSO for all team members
- And users see "Login with SSO" option on login page

---

Story: Usage Analytics
As a team lead,
I want to see which features my team uses most,
So that I can optimize workflows and training.

Acceptance Criteria:
- Given I'm on the Analytics dashboard
- When I select date range (last 7/30/90 days)
- Then I see top 10 features by usage count
- And I see per-user activity breakdown
- And I can export data as CSV

Mobile App

Story: Offline Mode
As a mobile user with unreliable connectivity,
I want to access recent content offline,
So that I can work without internet.

Acceptance Criteria:
- Given I've viewed content while online
- When I lose internet connection
- Then I can still access last 50 viewed items
- And I see indicator: "Offline mode - showing cached content"
- And my edits sync automatically when connection restored

---

Story: Push Notifications
As a user who wants to stay updated,
I want to receive push notifications for important events,
So that I don't miss time-sensitive information.

Acceptance Criteria:
- Given I've enabled notifications in settings
- When a relevant event occurs (message, mention, deadline)
- Then I receive push notification on my device
- And tapping notification opens relevant screen
- And I can customize notification types in settings

---

Breaking Down Epics

Epic Decomposition Process

1. Identify the Epic
   "Enable marketplace for third-party sellers"

2. List major capabilities
   - Seller registration and verification
   - Product listing management
   - Order fulfillment
   - Payment processing
   - Seller analytics

3. Break into user stories
   For each capability, write stories from different perspectives

4. Prioritize using MoSCoW or RICE
   Determine which stories are MVP vs future phases

Example: Marketplace Epic

Epic: Enable Marketplace for Third-Party Sellers

Must Have (MVP):
- As a seller, I want to register and verify my business
- As a seller, I want to list products with photos and descriptions
- As a buyer, I want to see which products are from third-party sellers
- As a seller, I want to receive notification of new orders
- As a buyer, I want to contact sellers with questions
- As a seller, I want to receive payment for fulfilled orders
- As platform admin, I want to review and approve new sellers

Should Have (Phase 2):
- As a seller, I want to bulk upload products via CSV
- As a seller, I want analytics on views and sales
- As a buyer, I want to filter by seller rating
- As a seller, I want to offer promotions and discounts
- As platform admin, I want to charge commission on sales

Could Have (Phase 3):
- As a seller, I want to integrate inventory with my existing system
- As a seller, I want to A/B test product descriptions
- As a buyer, I want to follow favorite sellers
- As a seller, I want automated repricing based on competition

Won't Have (Future):
- As a seller, I want to open a physical storefront
- Integration with international payment processors

---

User Story Mapping

User story mapping helps visualize the user journey and identify all necessary stories.

Structure

┌─────────────────────────────────────────────────────────────┐
│                    User Activities (Top Row)                 │
├──────────────┬──────────────┬──────────────┬────────────────┤
│   Discover   │   Evaluate   │   Purchase   │   Use/Support  │
├──────────────┼──────────────┼──────────────┼────────────────┤
│              │              │              │                │
│  Stories     │  Stories     │  Stories     │   Stories      │
│  (vertical)  │  (vertical)  │  (vertical)  │   (vertical)   │
│              │              │              │                │
│  ↓ MVP       │  ↓ MVP       │  ↓ MVP       │   ↓ MVP        │
│  ↓ Phase 2   │  ↓ Phase 2   │  ↓ Phase 2   │   ↓ Phase 2    │
│  ↓ Phase 3   │  ↓ Phase 3   │  ↓ Phase 3   │   ↓ Phase 3    │
└──────────────┴──────────────┴──────────────┴────────────────┘

Horizontal: User journey (left to right)
Vertical: Priority (top = MVP, bottom = nice-to-have)

Example: Online Course Platform

Activity: Discover
MVP:
- Browse course catalog
- Search by keyword
- Filter by category
Phase 2:
- Personalized recommendations
- Course previews (video)
Phase 3:
- AI-powered course suggestions

Activity: Evaluate
MVP:
- View course details
- Read course reviews
- See instructor bio
Phase 2:
- Compare courses side-by-side
- Preview first lesson free
Phase 3:
- AI-generated course summaries

Activity: Purchase
MVP:
- Add course to cart
- Checkout with credit card
- Receive confirmation email
Phase 2:
- Apply discount codes
- Gift courses to others
Phase 3:
- Subscription bundles
- Corporate/team purchases

Activity: Learn
MVP:
- Watch video lessons
- Track progress
- Download course materials
Phase 2:
- Take quizzes
- Certificate of completion
- Discussion forums
Phase 3:
- Live Q&A sessions
- Peer code review
- Offline mobile app

---

Common Mistakes

1. Too Technical

❌ "As a developer, I want to implement OAuth2 with JWT tokens"

✓ "As a user, I want to login securely without remembering multiple passwords,
   so I can access my account from any device"

Why: Focus on user value, not implementation details

2. Too Vague

❌ "As a user, I want the system to be fast"

✓ "As a user, I want search results to load within 500ms,
   so I can quickly find products without waiting"

Why: Vague stories aren't testable or estimable

3. Missing the "So That"

❌ "As a user, I want to filter products by price range"

✓ "As a budget-conscious shopper, I want to filter products by price range,
   so I only see items I can afford"

Why: The benefit clarifies the value and helps prioritization

4. Multiple Stories in One

❌ "As a user, I want to create an account, update my profile,
    change my password, and delete my account"

✓ Split into 4 stories:
- "As a new user, I want to create an account with email and password"
- "As a user, I want to update my profile information (name, bio, photo)"
- "As a user, I want to change my password for security"
- "As a user, I want to delete my account and all associated data"

Why: Smaller stories are easier to estimate, test, and complete

5. Implementation over Outcome

❌ "As a user, I want a dropdown menu in the navigation bar"

✓ "As a user, I want to easily navigate to different product categories,
   so I can browse relevant items"

Why: Let the team determine the best implementation (dropdown, mega menu, sidebar, etc.)

---

User Story Workflow

1. Ideation

Sources:
- User research and interviews
- Customer support tickets
- Product analytics
- Competitive analysis
- Stakeholder requests
- Technical improvements

Capture in product backlog (unsorted)

2. Elaboration

During backlog refinement:
- Write user story in standard format
- Add context and rationale
- Identify acceptance criteria (draft)
- Attach design mockups (if available)
- List dependencies

3. Estimation

Team estimates effort:
- Planning poker (Fibonacci: 1, 2, 3, 5, 8, 13)
- T-shirt sizes (S, M, L, XL)
- Ideal days/hours

If estimate is too high → break down further
If too uncertain → create research spike

4. Prioritization

Apply prioritization framework:
- RICE scoring
- MoSCoW categorization
- Business value vs effort matrix

Move to sprint backlog when ready

5. Implementation

During sprint:
- Developer picks story from sprint backlog
- Discusses details with PM/designer
- Implements functionality
- Writes automated tests
- Creates pull request

Definition of Done:
- [ ] Code complete and reviewed
- [ ] Unit tests written (>80% coverage)
- [ ] Acceptance criteria verified
- [ ] No critical bugs
- [ ] Documentation updated
- [ ] Deployed to staging

6. Acceptance

Product owner verifies:
- All acceptance criteria met
- Edge cases handled
- Performance acceptable
- Accessible (WCAG 2.2 AA)

If approved → mark as Done
If issues found → create bug stories

---

Tools for User Stories

---

Best Practices

1. Write from User Perspective

✓ "As a customer, I want..."
✓ "As a seller, I want..."
✓ "As an admin, I want..."

Avoid:
✗ "The system shall..."
✗ "As a developer, I want..." (unless building dev tools)

2. Focus on One Persona per Story

❌ "As a buyer or seller, I want to message each other"

✓ Split into two perspectives:
- "As a buyer, I want to message the seller with questions about a product"
- "As a seller, I want to respond to buyer messages to increase sales"

3. Avoid UI Specifications

❌ "As a user, I want a red button labeled 'Submit' in the bottom-right corner"

✓ "As a user, I want to easily submit my form and receive confirmation"

Let design determine the UI implementation

4. Include Acceptance Criteria Early

Don't wait until sprint planning to add acceptance criteria.
Draft them during backlog refinement so the team can estimate accurately.

Basic draft is OK, details emerge during implementation.

5. Keep the Backlog Groomed

Regular refinement (weekly):
- Remove obsolete stories
- Break down large stories
- Update priorities
- Add missing acceptance criteria
- Clarify ambiguities

Goal: 2-3 sprints of refined stories ready to pull

6. Link to Supporting Artifacts

Attach to user story:
- Design mockups (Figma, Sketch)
- User research findings
- Analytics data
- Technical specs
- API documentation
- Related PRD sections

---

Checklist

## User Story Quality Check

### Format
- [ ] Follows "As a / I want / So that" format
- [ ] Written from user perspective (not system/developer)
- [ ] Includes clear benefit/value in "so that" clause

### INVEST Criteria
- [ ] Independent: Minimal dependencies
- [ ] Negotiable: Details flexible, not prescriptive
- [ ] Valuable: Clear user or business value
- [ ] Estimable: Team can estimate effort
- [ ] Small: Completable in one sprint
- [ ] Testable: Has acceptance criteria

### Acceptance Criteria
- [ ] Uses Given-When-Then format
- [ ] Covers happy path
- [ ] Includes error scenarios
- [ ] Defines edge cases
- [ ] Measurable and testable

### Supporting Information
- [ ] Context and rationale provided
- [ ] Link to designs (if available)
- [ ] Dependencies identified
- [ ] Estimated by team
- [ ] Prioritized in backlog

PRD: [Product/Feature Name]

Status: Draft | In Review | Approved Version: 1.0 Last Updated: YYYY-MM-DD Author: [Name] Stakeholders: [Engineering Lead, Design Lead, etc.]

---

Changelog

---

Executive Summary

Problem Statement

[In 2-3 sentences, describe the problem you're solving. What pain point are users experiencing? What opportunity are we missing?]

Example:

Users abandon their carts 40% of the time because checkout requires account creation. Competitors offer guest checkout and have 25% lower cart abandonment. We're losing an estimated $2M in annual revenue due to this friction.

Proposed Solution

[In 1-2 sentences, describe your solution at a high level]

Example:

Enable guest checkout that allows users to complete purchases with just email, shipping address, and payment information—no account required. After purchase, optionally convert guest checkout to account with one-click.

Success Metrics

[3-5 key metrics that define success]

Example:

• Reduce cart abandonment from 40% to 30% within 3 months
• Increase conversion rate by 15%
• 50% of guest checkout users convert to accounts within 30 days
• Maintain <2s checkout completion time (p95)

---

Context & Background

Why Now?

[What makes this the right time to build this?]

Example:

• Competitor analysis shows 8/10 top e-commerce sites offer guest checkout
• User research (n=150) showed account creation as #1 friction point
• Mobile traffic increased to 60% (mobile users resist creating accounts)
• Q4 holiday season approaching (high cart volume)

Strategic Alignment

[How does this support company goals?]

Example:

• Aligns with 2025 goal: Increase revenue by 25%
• Supports "frictionless commerce" product vision
• Enables mobile-first strategy (mobile users prefer guest checkout)

What Happens If We Don't Build This?

[Consequences of not shipping this feature]

Example:

• Continued revenue loss (~$500k/quarter)
• Competitive disadvantage vs. Amazon, Shopify competitors
• Negative user reviews citing checkout friction
• Mobile conversion gap continues to widen

---

Goals & Success Metrics

Business Goals

[Quantifiable business objectives]

Example:

• Revenue: Increase completed transactions by 10,000/month ($2M incremental revenue)
• Conversion: Improve checkout conversion from 60% to 75%
• Customer Acquisition: Reduce cost-per-acquisition by 20% (lower friction = higher conversion)

User Goals

[What users will be able to accomplish]

Example:

• Complete purchase in under 2 minutes without creating account
• Save time on first purchase (no form duplication)
• Maintain privacy (optional account creation)

Success Criteria

[How we'll measure success—include baseline, target, and timeline]

Leading Indicators (track weekly):

• Number of guest checkouts initiated
• Guest checkout completion rate
• Time to complete checkout
• Error rate during checkout

Lagging Indicators (track monthly):

• Overall revenue impact
• Customer lifetime value (CLV) comparison: guest vs account
• Support ticket volume related to checkout

---

Target Users & Personas

Primary Users

Persona 1: First-Time Mobile Shopper

Demographics:

• Age: 25-35
• Device: Mobile (70% iOS, 30% Android)
• Context: Shopping on-the-go, during commute

Pain Points:

• Doesn't want to create account for unknown brand
• Small mobile keyboard makes form-filling frustrating
• Skeptical of sharing personal info with new sites
• Needs fast checkout (limited time)

Goals:

• Complete purchase in <2 minutes
• Minimal form fields
• Trust that their data is secure

Quote:

"I just want to buy this thing without creating another account I'll never use again."

Persona 2: Gift Purchaser

Demographics:

• Age: 30-50
• Device: Desktop or mobile
• Context: Buying gift for someone else

Pain Points:

• Doesn't want separate account for one-time gift
• Needs to ship to different address than billing
• Often in a hurry (last-minute gifts)

Goals:

• Quick checkout without commitment
• Easy gift note addition
• Ship to recipient address

Quote:

"Why do I need an account? I'm just buying a birthday gift."

Secondary Users

Persona 3: Privacy-Conscious Shopper

Demographics:

• Age: 25-45
• Device: Any
• Context: Values privacy and data minimization

Pain Points:

• Resents mandatory account creation
• Worried about data breaches and spam
• Wants minimal data sharing

Goals:

• Purchase without revealing unnecessary personal data
• Option to stay anonymous
• Control over marketing communications

---

User Stories & Use Cases

Epic: Guest Checkout

Must-Have Stories (MVP)

Story 1: Guest Checkout Option

As a first-time shopper,
I want to checkout without creating an account,
So that I can complete my purchase quickly.

Acceptance Criteria:
Given I have items in my cart and I'm not logged in
When I click "Checkout"
Then I see two options: "Continue as Guest" and "Login/Signup"
And the "Continue as Guest" option is visually prominent

Given I select "Continue as Guest"
When I proceed to checkout
Then I only need to provide: email, shipping address, payment info
And I don't see password or account creation fields
And I can complete checkout in <2 minutes

Story 2: Guest Checkout Flow

As a guest user,
I want a streamlined checkout experience,
So that I can purchase quickly without unnecessary steps.

Acceptance Criteria:
Given I'm checking out as guest
When I enter my email
Then the system validates email format
And checks if email exists (without revealing if account exists for security)

Given I've entered my shipping address
When I proceed to payment
Then my address is saved for this session only
And I can edit address before final confirmation

Given I've completed payment
When order is confirmed
Then I receive order confirmation email
And I can track order via email link (no login required)

Story 3: Optional Account Conversion

As a guest who completed checkout,
I want the option to create an account,
So that I can track my order and shop faster next time.

Acceptance Criteria:
Given I've completed guest checkout
When I land on order confirmation page
Then I see optional prompt: "Create account to track orders and save info"
And the prompt is non-intrusive (can be dismissed)

Given I click "Create Account"
When I enter just a password
Then an account is created with my guest checkout info
And I'm automatically logged in
And my order is associated with my new account

Should-Have Stories (Phase 2)

Story 4: Guest Order Tracking

As a guest purchaser,
I want to track my order without logging in,
So that I can know when my package arrives.

Acceptance Criteria:
Given I completed guest checkout
When I receive confirmation email with tracking link
Then I can click link to view order status
And I can see: order items, shipping status, estimated delivery
And I don't need to login or create account

Story 5: Saved Guest Data

As a repeat guest shopper,
I want my info pre-filled on return,
So that checkout is even faster next time.

Acceptance Criteria:
Given I've checked out as guest before (same device/browser)
When I return and add items to cart
Then my email and shipping address are pre-filled (if I opt-in to cookies)
And I can edit any pre-filled information
And I'm still not required to create account

---

Requirements

Functional Requirements

1. Guest Checkout Flow

FR-1.1: System shall provide "Continue as Guest" option at checkout for non-logged-in users

FR-1.2: Guest checkout shall collect only essential information:

• Email address (required, validated)
• Shipping address (required, validated via address API)
• Payment information (required, processed via Stripe)
• Phone number (optional, for delivery updates)

FR-1.3: System shall validate all input fields with inline error messages

FR-1.4: Guest checkout shall complete in ≤3 steps: 1. Email + Shipping 2. Payment 3. Review + Confirm

FR-1.5: System shall send order confirmation email to guest users within 2 minutes

2. Account Conversion

FR-2.1: System shall offer optional account creation after successful guest checkout

FR-2.2: Account conversion shall require only password (email + order info already captured)

FR-2.3: System shall associate guest order with newly created account

FR-2.4: System shall not spam or pressure users to create account

3. Order Tracking

FR-3.1: System shall generate unique, secure order tracking link for guest orders

FR-3.2: Order tracking page shall not require authentication

FR-3.3: Tracking link shall expire after 90 days

4. Data Handling

FR-4.1: Guest data shall be stored with same security standards as account users

FR-4.2: System shall comply with GDPR, CCPA for guest users (right to deletion, data export)

FR-4.3: Guest email addresses shall not be automatically added to marketing lists (requires opt-in)

Non-Functional Requirements

Performance

NFR-1.1: Checkout completion time shall be <2 seconds per step (p95 latency)

NFR-1.2: System shall handle 10,000 concurrent guest checkouts

NFR-1.3: Payment processing shall complete within 5 seconds (p95)

Security

NFR-2.1: All guest data shall be encrypted at rest (AES-256)

NFR-2.2: All guest data transmission shall use TLS 1.3

NFR-2.3: Order tracking links shall use cryptographically secure tokens (256-bit)

NFR-2.4: System shall implement rate limiting: max 5 checkout attempts per IP per hour

NFR-2.5: Guest checkout shall comply with PCI DSS (payment handled by Stripe)

Accessibility

NFR-3.1: Guest checkout flow shall meet WCAG 2.2 AA standards

NFR-3.2: All form fields shall have proper labels and ARIA attributes

NFR-3.3: Checkout shall be fully keyboard navigable

NFR-3.4: Error messages shall be announced to screen readers

Usability

NFR-4.1: Guest checkout shall work on all modern browsers (Chrome, Safari, Firefox, Edge - latest 2 versions)

NFR-4.2: Guest checkout shall be responsive (mobile, tablet, desktop)

NFR-4.3: Form fields shall support autofill (address, payment)

NFR-4.4: Mobile keyboard types shall match input (email keyboard for email field, numeric for zip)

---

Out of Scope

Explicitly NOT included in this release:

• ❌ Social login for guest users (deferred to Q3)
• ❌ Apple Pay / Google Pay integration (separate PRD)
• ❌ International shipping for guest checkout (US only for MVP)
• ❌ Guest wishlist or saved items (requires account)
• ❌ Guest returns/exchanges (requires account creation)
• ❌ Gift cards for guest checkout (Phase 2)
• ❌ Subscription products for guests (requires account)

Rationale: Focus on core guest checkout flow first. Additional payment methods and features based on adoption data.

---

Design & User Experience

Design Files

[Link to Figma/Sketch files]

Example:

• Guest Checkout Flow - Figma
• Mobile Responsive Designs
• Error States & Validation

Key Design Decisions

1. Checkout Option Presentation

• Two equal-weight buttons: "Continue as Guest" | "Login"
• Guest option on left (Western reading order = priority)
• No dark patterns (e.g., "Skip" or diminutive language)

2. Progress Indicator

• Show 3-step progress: "Shipping" → "Payment" → "Review"
• Allows users to gauge time commitment

3. Form Design

• One column layout (reduces cognitive load)
• Labels above fields (better for mobile)
• Inline validation on blur
• Clear, actionable error messages

4. Trust Signals

• SSL lock icon visible
• "Secure Checkout" badge
• Payment logos (Visa, MC, Amex)
• Privacy policy link

Accessibility Requirements

• ✅ WCAG 2.2 AA compliance
• ✅ Minimum touch target: 44x44px
• ✅ Color contrast ratio ≥4.5:1 for text
• ✅ Focus indicators visible (2px outline)
• ✅ Form labels properly associated with inputs
• ✅ Error messages linked via aria-describedby
• ✅ Screen reader tested (NVDA, VoiceOver)

Mobile Considerations

• Simplified form (fewer fields on mobile)
• Autofill support for faster entry
• Sticky CTA button (always visible)
• Optimized keyboard types (email, number, tel)
• Large touch targets (min 44x44px)

---

Technical Considerations

Architecture Overview

┌─────────────┐
│   Frontend  │
│  (React)    │
└──────┬──────┘
       │
       │ REST API
       ▼
┌─────────────────┐
│   Backend API   │
│  (Node.js)      │
└────┬───────┬────┘
     │       │
     │       └──────► Stripe API (payment)
     │
     ▼
┌────────────┐
│ PostgreSQL │
│  Database  │
└────────────┘

Data Model Changes

New Table: `guest_orders`

CREATE TABLE guest_orders (
  id UUID PRIMARY KEY,
  email VARCHAR(255) NOT NULL,
  tracking_token VARCHAR(64) UNIQUE NOT NULL,
  shipping_address JSONB NOT NULL,
  order_total DECIMAL(10,2) NOT NULL,
  stripe_payment_intent_id VARCHAR(255),
  status VARCHAR(50) NOT NULL,
  created_at TIMESTAMP NOT NULL,
  expires_at TIMESTAMP NOT NULL,
  converted_to_account_id UUID REFERENCES users(id),
  INDEX idx_email (email),
  INDEX idx_tracking_token (tracking_token),
  INDEX idx_created_at (created_at)
);

Modified Table: `orders`

ALTER TABLE orders ADD COLUMN guest_order_id UUID REFERENCES guest_orders(id);
ALTER TABLE orders ADD COLUMN is_guest BOOLEAN DEFAULT FALSE;

API Endpoints

New Endpoints:

POST   /api/v1/checkout/guest
  → Initiate guest checkout
  Body: { email, cart_id }
  Response: { checkout_session_id, expires_at }

POST   /api/v1/checkout/guest/:session_id/shipping
  → Submit shipping info
  Body: { address, phone }
  Response: { shipping_options, tax, total }

POST   /api/v1/checkout/guest/:session_id/payment
  → Submit payment
  Body: { stripe_payment_method_id }
  Response: { order_id, tracking_token }

GET    /api/v1/orders/track/:tracking_token
  → Track guest order (no auth)
  Response: { order_details, shipping_status }

POST   /api/v1/guest-orders/:id/convert
  → Convert guest order to account
  Body: { password }
  Response: { user_id, auth_token }

Dependencies & Integrations

Technical Risks & Mitigations

Risk 1: Guest data security

• Mitigation: Use same encryption, access controls as account users
• Mitigation: Regular security audits, penetration testing
• Mitigation: Implement rate limiting to prevent abuse

Risk 2: Duplicate accounts (same email)

• Mitigation: Check for existing email on account conversion
• Mitigation: Offer account merge flow if email exists
• Mitigation: Show warning: "An account with this email exists. Login instead?"

Risk 3: Guest order fraud

• Mitigation: Stripe fraud detection
• Mitigation: Velocity checks (max 3 orders per email per day)
• Mitigation: Require email verification for high-value orders (>$500)

Risk 4: Session management complexity

• Mitigation: Use Redis for session storage (fast, scalable)
• Mitigation: Clear expiration policy (30-minute session timeout)
• Mitigation: Comprehensive session cleanup job

---

Rollout & Launch Plan

Phased Rollout Strategy

Phase 1: Internal Testing (Week 1-2)

• Deploy to staging environment
• Internal team testing (QA, PM, Engineering)
• Fix critical bugs

Phase 2: Beta (Week 3-4)

• Release to 10% of US traffic (feature flag)
• Monitor key metrics daily
• Collect user feedback via Hotjar
• A/B test: Control (account required) vs Treatment (guest checkout)

Phase 3: Gradual Rollout (Week 5-8)

• Increase to 25% → 50% → 75% → 100%
• Monitor error rates, conversion rates
• Pause rollout if error rate >2% or conversion drops

Phase 4: Full Launch (Week 9+)

• 100% of traffic
• Announce feature (blog post, social media)
• Monitor support tickets

Feature Flags

// Feature flag configuration
{
  "guest_checkout_enabled": {
    "production": true,
    "staging": true,
    "development": true
  },
  "guest_checkout_rollout_percentage": {
    "production": 100,  // Start at 10, increase gradually
    "staging": 100,
    "development": 100
  },
  "guest_to_account_conversion": {
    "production": true,
    "staging": true,
    "development": true
  }
}

Monitoring & Alerts

Key Metrics to Monitor:

Dashboards:

• Real-time guest checkout funnel (Grafana)
• Error logs (Sentry)
• Payment processing (Stripe dashboard)
• User behavior (Google Analytics, Mixpanel)

Rollback Plan

Trigger Conditions:

• Error rate >5%
• Critical security vulnerability discovered
• Payment processing failure >10%
• Negative business impact (conversion drop >15%)

Rollback Process: 1. Set feature flag guest_checkout_enabled to false 2. Users automatically redirected to old checkout flow 3. In-flight guest checkouts allowed to complete 4. Incident post-mortem within 24 hours 5. Fix issues in staging before re-enabling

Success Criteria for Full Launch

Before moving to 100% rollout:

• ✅ Error rate <1%
• ✅ Guest checkout completion rate >70%
• ✅ Overall conversion rate improved by ≥10%
• ✅ No critical bugs in backlog
• ✅ Support team trained on guest checkout
• ✅ Documentation published

---

Open Questions & Risks

Open Questions

Q1: Should we allow guest checkout for high-value orders (>$1000)?

• Status: ⏳ Pending decision from Finance team
• Options:

a) No limit (trust Stripe fraud detection) b) Require email verification for orders >$500 c) Require phone verification for orders >$1000

• Decision deadline: 2 weeks before launch
• Owner: Finance Lead + PM

Q2: How long should we retain guest order data?

• Status: ⏳ Pending Legal review
• Options:

a) 90 days (for returns/support) b) 1 year (for analytics) c) Indefinitely (until user requests deletion)

• Decision deadline: Before beta launch
• Owner: Legal + Data Privacy team

Q3: Should guest users receive marketing emails?

• Status: 🟢 Resolved - No, unless explicit opt-in
• Decision: Respect anti-spam laws, require double opt-in for marketing
• Owner: Marketing Lead

Risks

---

Stakeholder Sign-Off

---

Appendix

Competitive Analysis

Insight: All major competitors offer guest checkout. It's table stakes, not a differentiator.

User Research Summary

Method: User interviews (n=50) + Survey (n=500)

Key Findings:

• 68% prefer guest checkout for first purchase with unknown brand
• 42% eventually create account if first experience is positive
• Account creation is #1 cited reason for cart abandonment (38%)
• Mobile users especially resistant to account creation (72%)

Quotes:

"I hate creating accounts. I use guest checkout whenever possible."

— Sarah, 29, frequent online shopper

"If I like the product and service, I'll create an account later. Don't force me upfront."

— Mike, 35, occasional buyer

Analytics Data

Cart Abandonment Analysis (Last 90 Days):

• Total carts created: 250,000
• Carts that reached checkout: 150,000 (60%)
• Abandoned at checkout: 60,000 (40%)
• Reason (exit survey): 65% cited "Don't want to create account"

Estimated Revenue Impact:

• Abandoned cart value: $6M
• If 50% of those complete as guest: +$3M revenue
• Conservative estimate (30% conversion): +$1.8M revenue

Related Documents

• Checkout Redesign - Figma
• User Research Report - Guest Checkout
• Technical Spec - Backend Implementation
• Security Review - Guest Data Handling

---

Document History

This PRD is a living document. Update version number and changelog for significant changes.

Review Schedule:

• Weekly during development
• Monthly post-launch (first 3 months)
• Quarterly thereafter

Feedback: Contact [Product Manager Name] at pm@company.com