product-prd-requirements-gathering

Research methods, stakeholder interviews, prioritization frameworks, and requirements synthesis for PRDs

PRD Requirements Gathering

Scope: Comprehensive techniques for discovering, validating, and prioritizing product requirements Lines: ~340 Last Updated: 2025-10-25 Format Version: 1.0 (Atomic)

When to Use This Skill

Activate this skill when:

Core Concepts

Concept 1: Jobs to Be Done Framework

Core Principle: Users don't want products; they "hire" products to get jobs done.

JTBD Interview Structure:

Example Questions:

Concept 2: Research Synthesis Process

Data Collection:

Synthesis Steps:

  1. Transcribe and Tag: Label quotes by theme (usability, performance, feature requests)
  2. Identify Patterns: Look for repeated pain points across 3+ users
  3. Prioritize Insights: Weight by frequency, severity, and alignment with strategy
  4. Extract Requirements: Translate insights into "system must do X because Y"

Concept 3: Prioritization Frameworks

RICE Scoring:

MoSCoW Method:

Kano Model:

Patterns

Pattern 1: User Interview Question Design

When to use:

## User Interview Script Template

### Opening (5 min)
"Thanks for joining! We're trying to understand how people currently [accomplish goal].
No right answers - just want to learn about your experience."

### Context Questions (10 min)
- "Tell me about your role and how [domain] fits into your day."
- "How often do you [perform task]?"
- "Walk me through the last time you needed to [accomplish goal]."

### Pain Point Discovery (15 min)
- "What's most frustrating about [current process]?"
- "What workarounds have you created?"
- "What would you change if you had a magic wand?"
- "What almost made you stop using [current solution]?"

### Jobs to Be Done (15 min)
- "What were you hoping to accomplish when you started using [product]?"
- "What did you try before [product]? Why did you switch?"
- "How do you know when you've succeeded at [task]?"
- "What would make this 10x better?"

### Closing (5 min)
- "Anything else we should know?"
- "Can we follow up if we have questions?"

Key Practices:

Pattern 2: Stakeholder Interview Template

Use case: Understanding technical constraints, business goals, and cross-functional dependencies

## Stakeholder Interview Guide

### Engineering Lead
- "What are our biggest technical constraints for [area]?"
- "What would make this project risky from an eng perspective?"
- "What dependencies or integrations do we need to consider?"
- "What's the maintenance burden of different approaches?"

### Design Lead
- "What design patterns have worked well for [similar use case]?"
- "What accessibility requirements do we need to meet?"
- "What user research exists on [topic]?"
- "What are the visual/interaction constraints?"

### Sales/CS
- "What features do prospects ask for most?"
- "What causes deals to stall or users to churn?"
- "What competitive features are we losing to?"
- "What would make your job significantly easier?"

### Leadership
- "How does this align with our annual goals?"
- "What's the business case (revenue, retention, cost savings)?"
- "What timeline are we targeting?"
- "What's the acceptable scope/timeline trade-off?"

Pattern 3: Competitive Analysis Matrix

When to use:

## Competitive Feature Matrix

| Feature | Us | Competitor A | Competitor B | Competitor C | Market Gap? |
|---------|-------|--------------|--------------|--------------|-------------|
| Real-time collaboration | ❌ | ✅ Premium | ✅ All plans | ❌ | Opportunity |
| API access | ✅ Enterprise | ✅ All plans | ❌ | ✅ Pro+ | Competitive |
| Mobile app | ✅ Basic | ✅ Full-featured | ✅ Limited | ❌ | Parity |
| Reporting | ✅ Advanced | ❌ | ✅ Basic | ✅ Basic | Advantage |

## Analysis Notes
- **Opportunity**: Real-time collab is table stakes for Competitors A&B; we're behind
- **Differentiation**: Our reporting is more advanced; lean into this strength
- **Market Gap**: No competitor offers automated workflow templates (white space!)

## Prioritization Implication
1. **Must Have**: Real-time collaboration (basic parity)
2. **Should Have**: Enhanced reporting dashboard (leverage advantage)
3. **Could Have**: Automated templates (differentiation play)

Pattern 4: RICE Prioritization Worksheet

Use case: Scoring and ranking feature requests objectively

## RICE Scoring Template

| Feature | Reach (users/qtr) | Impact (0.25-3) | Confidence (%) | Effort (PM) | RICE Score |
|---------|-------------------|-----------------|----------------|-------------|------------|
| Real-time collab | 5,000 | 2.0 | 80% | 6 | 1,333 |
| API rate limits | 500 | 0.5 | 100% | 1 | 250 |
| Dark mode | 8,000 | 0.5 | 90% | 2 | 1,800 |
| Export PDF | 3,000 | 1.0 | 100% | 1 | 3,000 |

## Scoring Definitions
**Reach**: Unique users affected per quarter (use analytics or estimates)
**Impact**:
  - 3 = Massive (core workflow, 3x better)
  - 2 = High (significant improvement, 2x better)
  - 1 = Medium (noticeable improvement)
  - 0.5 = Low (nice-to-have)
  - 0.25 = Minimal (tiny improvement)

**Confidence**:
  - 100% = High certainty on all estimates
  - 80% = Medium confidence
  - 50% = Low confidence (use for ideas needing research)

**Effort**: Person-months (eng + design + PM time)

## Priority Ranking
1. Export PDF (score: 3,000) - Quick win, high impact
2. Dark mode (score: 1,800) - High reach, low effort
3. Real-time collab (score: 1,333) - Critical but expensive
4. API rate limits (score: 250) - Low reach, low impact

Pattern 5: MoSCoW Categorization

Use case: Creating clear scope boundaries for MVP vs future iterations

## MoSCoW Prioritization

### Must Have (Launch Blockers)
- User authentication (can't ship without it)
- Data encryption at rest (compliance requirement)
- Basic reporting dashboard (core value prop)
- Mobile responsive design (50% of traffic is mobile)

**Validation**: Would we cancel launch without this? If yes → Must Have.

### Should Have (Important but Not Critical)
- CSV export (workaround: manual copy-paste exists)
- Advanced filtering (nice-to-have, but search works)
- Email notifications (can use in-app for v1)

**Validation**: Is there a reasonable workaround? If yes → Should Have.

### Could Have (If Time Permits)
- Dark mode (aesthetic preference, not functional need)
- Keyboard shortcuts (power users would love it)
- Bulk operations (currently do one-by-one)

**Validation**: Would users notice if missing? If no → Could Have.

### Won't Have (Explicitly Out of Scope)
- Real-time collaboration (defer to Q2 based on eng complexity)
- Mobile native app (web-first strategy, evaluate later)
- Integration with Salesforce (only 10% of users requested)

**Validation**: Have we decided to explicitly defer? If yes → Won't Have.

Pattern 6: Research Synthesis Affinity Mapping

Use case: Organizing qualitative insights from 10+ user interviews

## Affinity Mapping Process

### Step 1: Extract Quotes
Read transcripts and pull verbatim user quotes:
- "I spend 2 hours a day copying data between systems" - User 3
- "The export feature crashes on large datasets" - User 7
- "I wish I could share reports with my team" - User 2
- "Loading times make me dread using this" - User 5

### Step 2: Group by Theme
**Performance Issues** (4 mentions):
- "Loading times make me dread using this" - User 5
- "Export crashes on large datasets" - User 7
- "Search takes forever" - User 12
- "Page hangs when I filter" - User 9

**Data Export/Integration** (6 mentions):
- "I spend 2 hours a day copying data" - User 3
- "Export feature crashes" - User 7
- "Need API access" - User 1
- "Can't automate reporting" - User 8

**Collaboration** (3 mentions):
- "I wish I could share reports" - User 2
- "No way to comment on data" - User 6
- "Team visibility is missing" - User 11

### Step 3: Prioritize by Frequency + Severity
1. **Data Export/Integration**: 6 mentions, blocks workflows → High priority
2. **Performance**: 4 mentions, causes daily pain → High priority
3. **Collaboration**: 3 mentions, workaround exists (email) → Medium priority

### Step 4: Translate to Requirements
**Data Export Pain** → Requirement:
- FR1: System must support CSV/JSON export for datasets up to 1M rows
- NFR1: Exports must complete in <30 seconds for 100k rows
- FR2: System must provide REST API for programmatic data access

Pattern 7: Validation Metrics Planning

Use case: Defining how you'll measure if requirements solve the problem

## Validation Metrics Template

### Problem: Users spend 2+ hours/day on manual data exports
**Hypothesis**: API access will reduce manual export time by 80%

**Leading Indicators** (measure during beta):
- API adoption rate: 30% of users within 30 days
- Support tickets re: exports: Decrease by 50%
- Time spent on export tasks: Measured via time-tracking survey

**Lagging Indicators** (measure post-launch):
- User productivity score (survey): Increase from 6/10 to 8/10
- Retention rate: Increase by 5 percentage points
- NPS for export feature: >40

**Measurement Plan**:
- Instrument API usage analytics (track calls, unique users, errors)
- Send survey at day 7, day 30, day 90 post-API access
- Tag support tickets related to exports for trend analysis

Pattern 8: Bias Mitigation Checklist

Use case: Ensuring research quality and avoiding confirmation bias

## Research Quality Checklist

### Sample Bias
- [ ] Interviewed users across segments (new, power, churned)
- [ ] Included non-users or lost deals (understand why they left)
- [ ] Avoided only interviewing friendly/engaged users
- [ ] Ensured geographic/demographic diversity if relevant

### Confirmation Bias
- [ ] Asked open-ended questions (not "Would you like X?")
- [ ] Recorded contradictory evidence (users who don't have problem)
- [ ] Avoided leading questions that imply "right" answer
- [ ] Tested alternative hypotheses (maybe problem isn't what we think)

### Recency Bias
- [ ] Looked at long-term trends (6+ months analytics)
- [ ] Didn't over-weight most recent user complaints
- [ ] Validated "urgent" requests with historical data

### Interpretation Bias
- [ ] Used verbatim quotes (not paraphrased interpretations)
- [ ] Had second person review synthesis for accuracy
- [ ] Separated observations from conclusions

Quick Reference

Interview Question Types

Question Type | Example | Purpose
--------------|---------|--------
Behavioral | "Walk me through last time you..." | Concrete stories, not hypotheticals
Pain Point | "What's most frustrating about...?" | Discover problems
Workaround | "How do you currently solve...?" | Understand severity (more hacks = worse pain)
Comparative | "What did you try before X?" | Competitive context
Outcome | "How do you know when you've succeeded?" | Success criteria
Hypothetical | "What would make this 10x better?" | Future state vision

Prioritization Framework Comparison

Framework | Best For | Output
----------|----------|-------
RICE | Scoring features objectively | Ranked list by score
MoSCoW | Defining MVP scope | Must/Should/Could/Won't buckets
Kano | Understanding user perception | Basic/Performance/Delight categories
Value vs Effort | Quick 2x2 prioritization | Quadrant matrix
Impact/Feasibility | Strategic planning | High-impact, feasible initiatives

Key Guidelines

✅ DO: Interview 5-10 users minimum for patterns to emerge
✅ DO: Record and transcribe interviews for accurate quotes
✅ DO: Validate quantitative data with qualitative insights
✅ DO: Involve stakeholders early to surface constraints
✅ DO: Document assumptions and confidence levels

❌ DON'T: Trust single user's feature request as universal need
❌ DON'T: Ask "Would you use X?" (users always say yes)
❌ DON'T: Skip talking to users who churned or chose competitors
❌ DON'T: Prioritize based on who shouted loudest
❌ DON'T: Confuse correlation with causation in data

Anti-Patterns

Critical Violations

❌ Confirmation Bias in Interviews: Only asking questions that validate your hypothesis

# ❌ NEVER:
"We're thinking of building a real-time chat feature. Would you use that?"
[User, wanting to be helpful: "Sure, that sounds nice!"]

# ✅ CORRECT:
"When you need quick answers, how do you currently get help?"
[User: "Honestly, I just email support and wait. It's annoying but works."]
"How urgent are those questions typically?"
[User: "Not very - I can wait a day usually."]
→ Insight: Real-time chat may not be high priority

❌ Single-Source Requirements: Building features based on one loud customer ✅ Correct approach: Validate request with 5+ users, check analytics for frequency

Common Mistakes

❌ Asking "Would You Use X?": Users always say yes to hypothetical features

# ❌ Don't:
"We could add a dark mode. Would you use it?"
[User: "Yeah, sure!" → Doesn't mean they actually would]

# ✅ Correct:
"How often do you work at night or in low-light environments?"
"Have you enabled dark mode in other apps? Which ones?"
"Does light mode in our app cause any issues for you?"
→ Behavioral evidence > Hypothetical interest

❌ Ignoring Churned Users: Only interviewing happy current users ✅ Better: Interview lost deals and churned users to understand failures

❌ Skipping Quantitative Validation: Assuming 3 user complaints = universal problem ✅ Better: Check analytics - is this 3 users or 3,000 affected?

❌ Feature Request Collection, Not Problem Discovery: "What features do you want?" ✅ Better: "What's hardest about [workflow]? Walk me through it."

Related Skills

Last Updated: 2025-10-25 Format Version: 1.0 (Atomic)