| name | thinking-jobs-to-be-done |
| description | Deciding what to build or why a feature isn't adopted. Reframe from features to the "job" users hire the product for — the progress they seek — to prioritize and position. |
Jobs to Be Done
Overview
Jobs to Be Done (JTBD), developed by Clayton Christensen, reframes product thinking around the progress customers are trying to make in their lives. People don't buy products; they "hire" products to do a job. Understanding the job reveals what you're really competing against and what success looks like.
Core Principle: People don't want a quarter-inch drill. They don't even want a quarter-inch hole. They want to hang a picture of their family.
When to Use
- Product development and roadmapping
- Feature prioritization
- User research and interviews
- Competitive analysis
- Market positioning
- Understanding "surprising" competitors
- Debugging low adoption of features
Decision flow:
Building/improving a product?
→ Do you understand the job users hire it for? → no → DISCOVER THE JOB
→ Are features not being adopted? → yes → CHECK JOB ALIGNMENT
→ Surprising competitors winning? → yes → IDENTIFY THEIR JOB
When NOT to Use
- Skip for execution and infrastructure problems. If the task is "fix this bug," "make this query faster," "design this schema," "wire up CI" — the job is already known and the work is technical. JTBD adds nothing; route to debugging, theory-of-constraints, or architecture skills instead.
- Skip when the job is already well-established and the open question is purely how to build it, not whether/why.
- Don't use it to retro-justify a feature decision already made — that's framework theater. Use it before prioritization, to change the decision.
Trigger Card
When deciding what to build or why a feature isn't adopted:
- Identify the job — what progress is the user trying to make in a specific situation? Frame it as "When [situation], I want to [progress]."
- Map competing solutions — what do users currently hire to get this job done? Include non-software alternatives.
- Find the underserved job dimension — where do current solutions fall short? Build for that gap.
Skip if the job is already well-established and the question is purely how to build it. Don't use to retro-justify a decision already made.
Understanding Jobs
The Job Formula
When I [situation/trigger]
I want to [motivation/progress]
So I can [desired outcome/better state]
Example:
When I [finish a project milestone]
I want to [notify my team without disrupting their focus]
So I can [maintain team awareness while respecting their time]
Job: "Keep team informed asynchronously"
Not: "Use Slack" (that's a solution, not the job)
Job Dimensions
Every job has multiple dimensions:
| Dimension | Question | Example (Project Management Tool) |
|---|
| Functional | What task needs doing? | Track tasks, assign work, see progress |
| Emotional | How do I want to feel? | In control, not overwhelmed, confident |
| Social | How do I want to appear? | Organized, reliable, professional |
Job Context
Jobs are situation-specific:
Same person, different jobs:
Morning: "Help me triage what needs attention today"
→ Simple dashboard, prioritized list
Deep work: "Get out of my way, let me focus"
→ Minimal notifications, distraction-free
End of day: "Help me hand off cleanly so I can disconnect"
→ Status summary, async update capabilities
The JTBD Discovery Process
Step 1: Identify Job Performers
Who is "hiring" your product?
## Job Performers
Primary: Engineering managers
- Hire product for: tracking team delivery
- Frequency: daily
- Stakes: team performance visible to leadership
Secondary: Individual engineers
- Hire product for: knowing what to work on next
- Frequency: multiple times daily
- Stakes: personal productivity and recognition
Step 2: Derive the Job From Available Artifacts
You usually can't run live user interviews. Instead, reconstruct the job from the evidence already in front of you — the PRD, tickets, support transcripts, analytics, and the code itself. Read these and answer the interview questions from the artifacts:
## JTBD Evidence Sources (in priority order)
1. PRD / spec / design doc
- What problem statement and "success" definition does it state?
- What user motivation is asserted (and is it backed by evidence)?
2. Tickets / issues / support threads / sales notes
- What trigger made the user reach for this? ("When I…")
- What did they try before / complain about? (the switch + the pain)
- Recurring phrasings = the real job, in the user's words
3. Usage / analytics / logs
- Where do users actually go, and where do they drop off?
- Which flows get repeated (real job) vs. abandoned (stated but not real)?
4. The code / config itself
- What does the feature actually let a user accomplish today?
Then answer, from that evidence — NOT from a hypothetical interview:
- Trigger: what situation makes them reach for this?
- Progress sought: what better state are they after?
- Switch: what were they using before, and what was wrong with it?
- Done signal: how do they know the job is finished?
If the artifacts genuinely don't answer these, name the gap explicitly and
flag that user research is needed — do NOT invent quotes or fabricate a
persona to fill it.
Step 3: Analyze Competing Solutions
What else could do this job?
## Competition for "Keep team informed on project status"
Direct competitors:
- Other project management tools (Asana, Monday.com)
Indirect competitors (same job, different solution):
- Email updates
- Slack messages
- Weekly standup meetings
- Walking over to someone's desk
- Spreadsheets
Non-consumption:
- Just hope everyone knows
- Let things fall through cracks
Insight: We're not competing with other tools—we're competing
with "just send an email" and "bring it up in standup"
Step 4: Map Job Steps
Break the job into stages:
## Job Map: "Deliver working software on time"
1. Define: Understand what needs to be built
- Sub-jobs: Clarify requirements, estimate scope, identify risks
2. Plan: Organize how to build it
- Sub-jobs: Break into tasks, sequence work, allocate resources
3. Execute: Build the thing
- Sub-jobs: Track progress, remove blockers, adjust course
4. Validate: Confirm it works
- Sub-jobs: Test, get feedback, verify acceptance criteria
5. Deliver: Get it to users
- Sub-jobs: Deploy, communicate, monitor
Pain points cluster around: #2 (scope conflicts) and #3 (blocker visibility)
Step 5: Identify Outcome Metrics
What does success look like for the job?
## Desired Outcomes: "Deliver working software on time"
Minimize:
- Time spent on status reporting
- Surprises in sprint reviews
- Blocked time waiting for others
- Rework from misunderstood requirements
Maximize:
- Confidence in delivery timeline
- Clarity on priorities
- Team awareness of blockers
- Early warning of issues
JTBD Application Patterns
Feature Prioritization
## Feature Evaluation: Job Lens
Feature: Advanced reporting dashboard
Job it serves: "Demonstrate team value to leadership"
Job performers: ~10% of users (managers reporting up)
Job frequency: Monthly
Alternative solutions: Screenshots + slides (works fine)
Verdict: Low priority - job is infrequent, alternatives adequate
---
Feature: Blocker visibility alerts
Job it serves: "Remove obstacles before they delay delivery"
Job performers: ~60% of users (anyone managing work)
Job frequency: Daily
Alternative solutions: Manual check-ins (time-consuming, often missed)
Verdict: High priority - frequent job, poor alternatives
Competitive Analysis
## Competitive Analysis via JTBD
Our product: Developer documentation tool
Traditional competitive frame:
- Competitors: ReadMe, GitBook, Docusaurus
- Differentiation: Features, pricing, integrations
JTBD competitive frame:
Job: "Help developers integrate our API successfully"
Competitors for this job:
- Our own code examples (strongest competitor!)
- Stack Overflow answers
- Competitor's documentation
- Direct support from our team
- Just trying stuff until it works
Insight: Improving code examples in docs might beat any feature work
Low Adoption Debugging
## Why isn't Feature X being used?
Feature: Automated weekly report generation
Usage: 3% of target users
JTBD analysis:
Expected job: "Create status reports efficiently"
Actual job: "Demonstrate my judgment and insight to leadership"
Problem: Automated reports don't show judgment
The PROCESS of creating reports is part of the job
They want to curate, not automate
Solution: Change from "generate report" to "draft report for review"
Support the curation job, don't replace it
JTBD Template
# Jobs to Be Done Analysis: [Product/Feature]
## Job Performers
| Performer | Hire For | Frequency | Stakes |
|-----------|----------|-----------|--------|
| | | | |
## Primary Job
When I [situation/trigger]
I want to [motivation/progress]
So I can [desired outcome]
### Job Dimensions
- Functional: [What task]
- Emotional: [How feel]
- Social: [How appear]
## Job Map
1. [Stage]: [Sub-jobs]
2. [Stage]: [Sub-jobs]
...
## Competing Solutions
| Competitor | How it does the job | Where it falls short |
|------------|---------------------|---------------------|
| | | |
## Desired Outcomes
Minimize:
- [Negative outcome]
Maximize:
- [Positive outcome]
## Implications
- Feature should: [Insight]
- Feature shouldn't: [Insight]
- Position against: [True competitor]
Verification Checklist
Key Questions
- "What job is the user hiring this product to do?"
- "What progress are they trying to make?"
- "What are they switching from? (Including 'nothing')"
- "What are they giving up by using this?"
- "What does success look like for this job?"
- "What surprising competitors exist for this job?"
Christensen's Wisdom
"People don't want a quarter-inch drill bit. They want a quarter-inch hole."
Actually: They want to hang a picture. Actually: They want to enjoy their family photos. The deeper you go, the more insight you get into what "better" really means.
"The jobs that arise in people's lives are the fundamental causal driver behind everything."
Products don't fail because of features. They fail because they don't help people make progress on jobs they care about. Understand the job, and the features become obvious.
