JTBD Extractor

Extract structured Jobs-to-Be-Done from any user signal — interviews, feedback, support tickets, analytics, or intuition. Produces reusable job statements that anchor PRDs, experiments, and prioritization.

When to Use

• "What job does this feature serve?"
• "Help me define the user need"
• "Extract jobs from these interviews"
• "Why do users use our product?"
• Before writing a PRD or one-pager
• When debating whether a feature is worth building
• When aligning a team on user needs vs. feature requests

Job Statement Format

Core job:

When I [situation/trigger], I want to [motivation/action], so I can [desired outcome].

Emotional job:

I want to feel [emotion] when I [activity].

Social job:

I want to be seen as [perception] by [audience].

Process

1. Gather Inputs

Accept any user signal:

• Interview notes or transcripts (→ use with user-interview-synth)
• App store reviews (→ use with app-store-analyzer)
• Support tickets or NPS comments
• Usage data patterns ("users who do X tend to also do Y")
• Feature requests ("users keep asking for Z")
• The PM's own intuition ("I think users want...")

2. Extract Raw Jobs

For each signal, identify:

• The trigger — what situation prompted the user to act?
• The struggle — what's hard or unsatisfying about their current approach?
• The desired outcome — what does "done" look like for the user?
• The hiring criteria — what would make them "hire" a solution?

Look for language clues:

• "I need to..." / "I want to..." / "I wish I could..."
• "It's frustrating when..." / "I hate that..."
• "I usually end up..." (workaround = unmet job)
• "I switched from [X] because..." (switching = job not done well)

3. Structure the Jobs

Write each job in the standard format. Then layer on:

Functional dimension:

• What practical outcome are they trying to achieve?

Emotional dimension:

• How do they want to feel during and after?

Social dimension:

• How do they want to be perceived?

Context:

• When and where does this job arise?
• How frequently?
• What's the current "hire" (competing product or workaround)?

4. Validate and Rank

For each job:

• Importance — how critical is this to the user? (must-have vs. nice-to-have)
• Satisfaction — how well does our product serve this job today? (well-served vs. underserved)
• Opportunity score — Importance + (Importance - Satisfaction)
  • High importance + low satisfaction = biggest opportunity

5. Map to Product

Connect jobs to:

• Existing features that serve this job (how well?)
• Roadmap items that address this job
• Gaps where no feature or plan exists

Store in knowledge/customers/jobs.md for ongoing reference.

Output

## Jobs-to-Be-Done: [Context]

**Date:** YYYY-MM-DD
**Source:** [interviews / reviews / feedback / analytics]

### Job Map

| # | Job Statement | Type | Importance | Satisfaction | Opportunity |
|---|--------------|------|------------|-------------|-------------|
| 1 | When I [situation], I want to [motivation], so I can [outcome] | Functional | High/Med/Low | High/Med/Low | [score] |

### Top Underserved Jobs
1. **[Job]** — Importance: High, Satisfaction: Low
   - Current workaround: [what users do today]
   - Our gap: [what's missing in our product]
   - Opportunity: [what we could build]

### Well-Served Jobs (Protect)
- **[Job]** — users are happy; don't break this

### Emerging Jobs (Monitor)
- **[Job]** — early signal, not yet validated

### Recommendations
- [Which jobs to target in the next cycle]
- [Which jobs need more research]

Principles

• Jobs are stable, solutions change — "get from A to B" is the job; Uber is one solution
• Users hire products — every feature should serve an identifiable job
• Underserved > overserved — build where importance is high and satisfaction is low
• One job, one metric — if you can't measure whether the job got done, you can't improve it