thinking-jobs-to-be-done — Claude Code skill: what to build

---
name: thinking-jobs-to-be-done
description: Deciding what to build or why adoption fails. Recover the progress users hire a solution for under a circumstance, then rank by outcome and competing workarounds.
disable-model-invocation: true
---

# Jobs to Be Done

Core rule: users hire solutions for progress in a situation. Prioritize the job, forces, outcome, and competing workaround—not the feature list.

## When to Use

- Choosing what to build, cut, or prioritize when user need is unclear
- Explaining low adoption of a shipped feature
- Mapping competition beyond same-category products (email, spreadsheets, manual work, non-consumption)
- Positioning or research when the progress sought is contested

Requires at least one evidence source: PRD/spec, tickets, support/sales notes, analytics/logs, or current product behavior. If none exist, name the research gap; do not invent quotes.

## When NOT to Use

- Pure execution once the job is known (bug fix, schema, CI, performance)—implement, do not rediscover the job
- Retro-justifying a decision already locked—framework theater
- Infrastructure/internal work with no end-user progress decision
- When the open question is only *how* to implement a settled job

## Procedure

1. **Name performers and circumstance.** Who hires a solution, in what trigger situation, how often, and with what stakes. Prefer primary performers with daily high-stakes jobs over rare secondary ones.
2. **State the job, not the solution.** Frame: `When [circumstance], I want to [progress], so I can [outcome]`. Reject solution-shaped statements ("use Slack", "add a dashboard"). Capture functional, emotional, and social dimensions only if evidence supports them.
3. **Map forces and switch.** From artifacts: what push made the old way fail, what pull the new progress offers, what anxiety blocks switching, what habit keeps the status quo. List what they hire today—including non-software and non-consumption.
4. **Define done and outcome metrics.** How the performer knows the job is finished. List outcomes to minimize and maximize (time-to-progress, rework, confidence, surprises). Prefer frequent, poorly served jobs over rare, adequately worked-around ones.
5. **Score candidates against the job.** For each feature/priority: which job step it serves, performer share, frequency, quality of alternatives. Promote high-frequency underserved dimensions; demote polished work for well-served or low-stakes jobs.
6. **Strongest countercase.** State the best case that the stated job is wrong (wrong performer, vanity metric, process-is-the-job, competition is actually non-consumption). If the countercase fits evidence better, revise the job before recommending build.
7. **Stop.** Stop when one primary job statement, competing set, and outcome metrics are evidence-backed enough to change a build/position decision—or when artifacts cannot answer and research is the only next step.

## Output

Produce a JTBD decision artifact:

```text
Job statement: When …, I want to …, so I can …
Performers: primary / secondary (frequency, stakes)
Forces: push / pull / anxiety / habit
Competition: direct | indirect | non-consumption
Outcomes: minimize […] ; maximize […]
Priority implication: build / cut / reposition — because job gap is …
Countercase checked: …
Evidence used / gaps: …
```

## Verification

- **Falsify:** If replacing the job statement with a feature name does not change the recommendation, you never left solution-space—rewrite the job from circumstance and progress.
- **Stop:** Do not keep mapping job steps once the ranking decision is stable.
- **Over-application guard:** Skip on pure implementation tasks and known jobs. Never fabricate user quotes or personas to fill missing evidence.