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.
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/thinking-jobs-to-be-done
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
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.
📊 Stats
Stars863
Forks126
LanguageJavaScript
LicenseMIT
📦 Ships with thinking-skills
</> SKILL.md
thinking-jobs-to-be-done.SKILL.md
---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
```
- **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:
1. **Identify the job** — what progress is the user trying to make in a specific situation? Frame it as "When [situation], I want to [progress]."
2. **Map competing solutions** — what do users currently hire to get this job done? Include non-software alternatives.
3. **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?
```markdown
## 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*:
```markdown
## 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?
```markdown
## 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"
- [ ] Identified job performers (who hires the product)
- [ ] Articulated job in When/Want/So format
- [ ] Considered functional, emotional, and social dimensions
- [ ] Mapped job steps
- [ ] Identified all competing solutions (including non-consumption)
- [ ] Defined measurable desired outcomes
- [ ] Features traced to specific jobs
## 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.
