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

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

Converted and distributed by TomeVault — claim your Tome and manage your conversions.