Jobs to Be Done skill for Claude Code

JTBD work is done well when the job is stated without any product or solution in it, it is backed by real switching stories rather than opinions, the forces that block switching are known as well as the ones that drive it, and the findings change a concrete decision: what to build, whom to target, what to say, or what to stop doing.

Ground rules

• A job is the progress a person is trying to make in a circumstance. It is stable over time and independent of any product. “Use our dashboard” is not a job; “know which shipments will be late before the customer does” is.
• Evidence comes from what people did, not what they say they want. Interview about a specific past switch, never about hypothetical futures.
• The competition is whatever people hire for the job today, including spreadsheets, an intern, a consultant, or doing nothing.
• Pick one school per project and say which: switch / progress (Christensen, Moesta: why people change, forces, timeline; best for positioning, messaging, adoption) or outcome-driven (Ulwick, ODI: job maps and measurable outcomes; best for prioritising features in a known market). Mixing vocabularies confuses the team.
• JTBD is a lens, not a replacement for usability testing, analytics, or experiments.

Choose the method

Decision to make	Method	Output
Why do people buy, switch to, or churn from us?	Switch interviews	Timeline, forces, job statements per segment
How should we position and message?	Switch interviews + competing solutions	Job-based positioning, struggling moments, triggers
Which parts of the job are poorly served?	Job map + outcome statements	Map of steps with outcomes
Which outcomes to prioritise, with numbers?	Outcome survey + opportunity scoring	Ranked underserved outcomes by segment
Is a new market worth entering?	Job map of the core job across current solutions	Where all current solutions struggle

For general discovery (opportunity solution trees, assumption tests), use product-discovery; for synthesising existing transcripts into themes, use user-research-synthesis.

Workflow

- [ ] 1. Name the decision the research must inform and the school you will use
- [ ] 2. Define the job executor and draft a hypothesis job (solution-free)
- [ ] 3. Recruit recent switchers (to, away, and non-switchers who looked)
- [ ] 4. Run switch interviews and/or job-map interviews
- [ ] 5. Code forces or outcomes per interview; cluster across interviews
- [ ] 6. Write final job statements with evidence counts
- [ ] 7. Translate into opportunities, positioning, and specific decisions

Job statements

Formats; pick one and use it consistently:

Job (core functional): <verb> + <object> + <contextual clarifier>
  "Get paid for completed client work"            (not "send invoices in our app")

Job story (switch school): When <situation>, I want to <motivation>, so I can <expected outcome>.
  "When a client pays late, I want to chase it without souring the relationship,
   so I can keep cash steady and keep the client."

Quality checks for a job statement:

Check	Fails	Passes
Solution-free	“Track time with a mobile app”	“Know how many billable hours I worked this week”
Stable over decades	“Post on Instagram”	“Keep customers thinking of my shop”
Has a circumstance	“Manage money”	“When income varies month to month, cover fixed bills”
Executor is clear	“Users want reporting”	“Ops manager at a 40-person e-commerce firm”
Includes the why	“Export CSV”	“…so I can show leadership the numbers before they ask”

Also capture emotional and social dimensions (“look in control in front of the COO”) and related jobs (the jobs before and after the core one). These often explain choices that features cannot.

Switch interviews and the four forces

Reconstruct the timeline from first thought to purchase, then code four forces:

Force	Direction	Question that surfaces it
Push of the situation	Toward change	“What was going wrong? What happened that day?”
Pull of the new solution	Toward change	“What did you picture being different after?”
Anxiety of the new	Against change	“What worried you about switching? What almost stopped you?”
Habit of the present	Against change	“What did you like about the old way? What did you have to give up?”

A switch happens only when push plus pull outweigh anxiety plus habit. Most teams invest only in pull (features); many losses are caused by unaddressed anxiety (migration risk, looking foolish, team adoption) and habit.

For the full script, timeline stages, and the per-interview coding card, read references/switch-interview-guide.md before planning or running interviews.

Job maps (outcome-driven school)

Map the core job as steps the executor goes through, independent of any solution. Ulwick and Bettencourt’s universal job map has eight steps:

Define → Locate → Prepare → Confirm → Execute → Monitor → Modify → Conclude
Example job: "Prepare a monthly financial close" (finance controller)
Define:   determine which accounts and entities are in scope this month
Locate:   gather bank statements, invoices, payroll reports
Prepare:  reconcile and categorise transactions
Confirm:  verify balances tie out before posting
Execute:  post journal entries and close the period
Monitor:  check for late adjustments and variances
Modify:   correct errors and re-run reports
Conclude: lock the period and distribute reports

Not every job uses all eight steps and some repeat; the map is a checklist for missed steps, not a template to force-fit.

Outcome statements

For each step, collect desired outcomes as measurable statements:

<direction> + <metric> + <object of control> + <contextual clarifier>
Minimize the time it takes to match bank transactions to invoices when amounts differ slightly
Minimize the likelihood of posting an entry to the wrong period

Rules: direction is minimise (occasionally maximise), metric is time, likelihood, or number; no solutions, no adjectives like “easy” or “intuitive”; one outcome per statement.

Opportunity scoring

Survey a representative sample of job executors on each outcome: importance and current satisfaction, typically on a 5-point scale. Convert each to the share rating 4 or 5 (top-two-box), scaled 0 to 10, then:

Opportunity = Importance + max(Importance - Satisfaction, 0)

High importance with low satisfaction marks underserved outcomes (build here); low importance with high satisfaction marks overserved ones (room for simpler, cheaper offerings). Rank relatively within the study and look for segments that score differently; the segment split is often the most useful finding.

From findings to decisions

Finding	Decision it should drive
Strong push, weak pull	Messaging should name the struggling moment; the product is not yet clearly better
Anxiety blocks trials	Reduce risk: migration help, free import, guarantees, references from similar customers
Habit blocks adoption	Make the switch small: keep familiar formats, import existing work, incremental rollout
Event 1 / Event 2 patterns	Time sales and marketing to the trigger (new hire, audit, quarter-end)
Competing solution is non-consumption	Market to people doing nothing; compare against the manual way, not competitors
Underserved outcomes cluster in one step	Roadmap theme for that step; success metric is the outcome statement
Overserved outcomes	Simplify, unbundle, or offer a lower tier

Positioning built on the job:

For <executor> who <struggling moment / push>, <product> is the <frame of reference>
that <progress made>. Unlike <what they hire today>, it <the difference that resolves anxiety or habit>.

Common misuses

• Job statements that are features in disguise: “Get AI summaries of meetings.” Ask “why?” until the product disappears.
• Personas renamed as jobs: demographics do not cause purchases; circumstances do.
• Asking customers what their job is: they answer with features. Infer the job from the switching story.
• Too broad: “Be more productive” cannot guide a decision. Too narrow: “Click export”. Aim for a job an executor would recognise and a team could design for.
• Only interviewing happy customers: switchers away and people who looked but stayed explain the forces against you.
• Counting mentions instead of people: one talkative participant is still one data point.
• Research with no decision attached: if no finding could change the plan, do not run it.
• Treating outcome survey scores as precise: small samples and mixed segments give noisy rankings; report sample size per segment.

Verification

• Every job statement passes the quality table (solution-free, circumstance, executor, why).
• Each job and force cluster lists the number of distinct interviews supporting it, with quote references.
• Forces against switching (anxiety, habit) are recorded for every interview.
• Outcome statements follow the direction-metric-object-clarifier format with no solutions.
• Each finding maps to a named decision or open question; unsupported claims are cut.

Output contract

# JTBD findings: <product / segment> — <dates>
Decision informed: <...>   School: switch | outcome-driven   Interviews: <n by segment>

## Jobs (ranked by evidence)
### Job 1: <statement>  (<n> of <N> interviews)
- Executor and circumstance:
- Emotional / social dimensions:
- Competing solutions hired today:
- Forces: push / pull / anxiety / habit (with quote refs)
- Triggers: Event 1 / Event 2 patterns

## Job map and underserved outcomes (if outcome-driven)
| Step | Outcome statement | Importance | Satisfaction | Opportunity | n |

## Implications
| Finding | Decision / recommendation | Owner |

## Open questions and next research