Jobs to be done

This is the exact file agents read, including the credit header and licence notice. Save it as jobs-to-be-done/SKILL.md.

---
name: jobs-to-be-done
description: Model the job a customer hires a product to do, using whichever school fits the question: Clayton Christensen and Bob Moesta's forces-and-switch view for why people buy or leave, and Tony Ulwick's outcome-driven innovation for measuring unmet need. Carries the real rules and formats: a job as progress in a circumstance, not a demographic; the four forces of progress (push, pull, anxiety, habit) with the rule that a switch happens only when push plus pull beat anxiety plus habit; switch interviews that recruit people who changed in the last 30 days and rebuild the purchase timeline; three job-statement syntaxes (Ulwick desired outcome, Ulwick job statement, Klement job story) with checks that keep them solution-free; and Ulwick's opportunity algorithm, importance plus the gap between importance and satisfaction, with the score bands that mark a need underserved or overserved. Use it when someone says jobs to be done, JTBD, why do customers buy or churn, run a switch interview, write a job statement or job story, or find unmet needs. Do NOT use it to plan and run general discovery interviews (see customer-interviews), to choose which opportunity to build (see opportunity-solution-trees), or to invent jobs with no customer evidence.
licence: CC BY 4.0. Free to use and adapt with credit to Afeez Adebayo, linking afeezadebayo.com, https://www.linkedin.com/in/afeez-adebayo/ and the skill's download page at https://afeezadebayo.com/skills-md/product-management/product-discovery/jobs-to-be-done/.
---

# Jobs to be done

Jobs to be done is a way of seeing a product through the progress a customer is trying to make, rather than through the customer's demographics or the product's features. People do not buy a quarter-inch drill because they want a drill; they hire it to make a quarter-inch hole, and they will fire it the moment something makes the hole better. The job is stable even as the solutions that serve it change, which is why a job statement outlives a feature list.

The field has two schools that answer different questions, and the common mistake is to pick one by habit. Clayton Christensen and Bob Moesta's forces-and-switch school explains why a specific person bought, switched or churned, by reconstructing the moment of change and the forces around it. Tony Ulwick's outcome-driven innovation measures how well a market's needs are met, by breaking a job into steps and desired outcomes and surveying importance against satisfaction. This skill makes an AI agent choose the right school for the question, model the job, write statements in the correct format, and, for the outcome school, score where the real unmet need sits. It does not plan and run the interviews themselves; that is the customer-interviews skill. It does not choose which of several opportunities to build; that is opportunity-solution-trees. It supplies the understanding those decisions rest on.

## When to use this skill, and when not to

Use it when someone asks why customers buy or leave, what job a product is really hired for, how to run a switch interview, how to write a job statement or a job story, how to find unmet needs, or how to reposition around a job rather than a feature. Use it to turn raw interviews (gathered with the customer-interviews skill) into a job model, forces map or outcome set.

Do not use it to plan a round of generative interviews, write a screener or an interview guide, or synthesise notes in general; that is customer-interviews, and this skill assumes you already have, or will gather, that evidence. Do not use it to compare several opportunities and pick one to pursue; that is opportunity-solution-trees, which takes the jobs and outcomes this skill produces as its raw material. And do not use it to manufacture jobs from the team's imagination. A job model with no customer behind it is a set of assumptions in a nice format, which is the main way jobs-to-be-done work goes wrong.

## What the agent needs from you before starting

Ask for these before writing a job statement or a forces map. Do not proceed on assumptions.

1. The question you are answering. "Why are trial users not converting?" points to the forces-and-switch school. "Where is the biggest unmet need in our market?" points to the outcome school. If the question is unclear, settle it first; it decides the whole method.
2. The customer and the circumstance. One segment and the situation they are in, for example "a finance lead closing the monthly books", not "finance teams".
3. The evidence you have or can gather. For the switch school, interviews with people who recently bought, switched or churned. For the outcome school, a defined job you can break into steps, and access to enough users to survey on importance and satisfaction. If there is no evidence, say what to gather first and hand the interview design to the customer-interviews skill.
4. What the output will feed: positioning and messaging, a roadmap input, a survey instrument, or a competitive read. The use shapes which format to produce.

If the question or the evidence is missing, stop and ask. Do not invent quotes, outcomes, satisfaction scores or percentages to fill the gap.

## How to model a job, step by step

Follow these in order. Steps 4 and 5 are a fork: take the switch path or the outcome path depending on step 1, not both at once.

### Step 1. Pick the school for the question

If the question is about a decision a person made or will make, why they bought, switched or churned, what nearly stopped them, use the forces-and-switch school (steps 2, 3, 4). If the question is about the state of a market, which needs are important and poorly served across many customers, use the outcome-driven school (steps 2, 3, 5, 6). If someone wants both the story of the switch and a measured need map, run them in sequence, switch interviews first to find the job, then an outcome survey to size it. State which school you are using and why before going further.

### Step 2. Define the core functional job as progress in a circumstance

Name the job as the progress the customer wants, framed by the situation, with no product or solution in it. "Keep my team's shared files findable as the team grows" is a job; "use our search feature" is a solution. A job has a beginning, a middle and an end: it is a process the customer moves through, not a single action. Check the frame against two traps: it must not name a demographic (a job is not "what millennials want"), and it must not be a solution wearing a job's clothes (if there is only one way to do it, you have written a feature).

### Step 3. Write the job statement in the right format

Use the format that matches the school and the use, and keep every one solution-free:

- Ulwick job statement, for naming the core job: action verb + object of the action + contextual clarifier. Example: "Listen to music while commuting."
- Ulwick desired outcome statement, for measurable needs under the job: direction of improvement (minimise or increase) + unit of measure + object of control + contextual clarifier. Example: "Minimise the time it takes to get the songs in the desired order for listening." These are the statements you later score.
- Klement job story, for design and messaging: "When [situation], I want to [motivation], so I can [expected outcome]." It anchors on the situation, not a persona, which is what a traditional user story ("as a [persona], I want [feature]") misses.

Run each statement through a check: strip any technology or solution reference; confirm it would still be true if today's products vanished; confirm it names a verb and an object, not a feeling alone. Capture the functional job first, then add the emotional and social layers in step 7.

### Step 4. Switch path: run switch interviews and map the four forces

For the forces school, reconstruct real switches. Recruit people who changed within the last 30 days, ideally the last 14, because older stories harden into tidy rationalisations. Recruit three kinds: people who switched to you, people who switched away, and people who considered you and did not. Interview in pairs where you can, one person driving while the other listens for gaps, and plan for 45 to 60 minutes. Do not ask about the forces directly; rebuild the timeline, first thought, passive looking, a triggering event, active looking, deciding, purchase, first use, and let the forces surface from what happened. Then place what you heard into the four forces of progress:

- Push: the frustration with the old way that made the status quo intolerable.
- Pull: the attraction of the new option.
- Anxiety: the worry about whether the new option will work, which delays the switch.
- Habit: the comfort of the current way, even when it is poor.

Apply the rule: a switch happens only when push plus pull are strong enough to beat anxiety plus habit. A product wins by increasing push and pull and, just as importantly, by reducing anxiety (guarantees, social proof, low-commitment trials) and habit (migration help, defaults). Patterns for one job usually emerge across five to eight interviews; a read across several segments needs more.

### Step 5. Outcome path: build the job map and desired outcomes

For the outcome school, break the core functional job into its steps. Ulwick's universal job map runs: define, locate, prepare, confirm, execute, monitor, modify and conclude; use it as a checklist to find steps you would otherwise miss. For each step, write the desired outcomes customers use to judge success, in the direction-plus-metric-plus-object-plus-context format from step 3. A single job commonly yields many dozens of outcome statements across its steps; that is expected, because the outcome school trades the richness of a story for coverage of the whole job.

### Step 6. Outcome path: score opportunity from importance and satisfaction

Survey actual users of the job, not non-users, on two questions per desired outcome: how important it is, and how satisfied they are with how well they can achieve it today, each on the same scale. Then apply Ulwick's opportunity algorithm:

Opportunity = Importance + maximum of (Importance minus Satisfaction, or zero).

On a 1 to 10 scale, read the bands this way: a score of 10 is the break-even line where satisfaction matches importance; 10 to 12 is a modest opportunity worth watching but not leading with; 12 to 15 is a clear underserved need worth pursuing; above 15 is strongly underserved and rare. Below 10 the need is overserved, so adding more there wastes effort and may be a place to cut. The gap term never goes negative, so an unimportant, well-served outcome scores low and drops down the list. Treat these cut-offs as Ulwick's published guidance and verify the exact thresholds against his current writing before betting a roadmap on a borderline score.

### Step 7. Add the emotional and social layers

Whichever school you used, do not stop at the functional job; stopping there is the most common jobs-to-be-done mistake. Add the emotional job (how the customer wants to feel, or to avoid feeling) and the social job (how they want to be seen by others). Ground each in a real quote or observed behaviour from the evidence, never in an assumed feeling. These layers often explain anxiety and habit in the forces map and separate two products that serve the same functional job.

### Step 8. Validate and hand off

Check every job, force and outcome against its source. Mark anything from a single interview as unconfirmed. Then hand off by name: to opportunity-solution-trees to choose which need to pursue, or to a positioning or messaging task to turn the job story into copy. The model informs the decision; a human still owns the roadmap and any claim made to customers.

## Worked example

Question: "Why do trial teams of our note-taking app stop before inviting anyone?" This is about a decision, so the agent takes the switch path.

Core functional job: "Capture and find a team's shared knowledge as the team grows." The agent recruits six trial users who churned in the last three weeks and two who converted, and rebuilds each timeline.

Forces that surface: push, "notes were scattered across three tools and I kept losing decisions"; pull, "this looked like one place for everything"; anxiety, "I wasn't sure my team would actually move, and I'd look silly championing another tool"; habit, "we always just dropped things in the group chat." The rule reads clearly: pull and push were real, but anxiety (reputation risk of championing a tool the team ignores) and habit (the group chat) were stronger, so the switch stalled. The agent notes the lever is reducing that anxiety, not adding features.

The emotional job ("feel on top of things, not the person who lost the decision") and the social job ("be seen as the organised lead") both reinforce the anxiety, each tied to a verbatim quote. The agent writes the job story, "When I'm trying to get my team onto one source of truth, I want to prove it works before I ask them to move, so I can champion it without risking my credibility", and hands the problem set to opportunity-solution-trees. It does not decide the fix itself.

## Templates you can use verbatim

Job-statement formats:

```
Ulwick job statement:    <verb> <object> <contextual clarifier>
   e.g. "Listen to music while commuting."
Ulwick desired outcome:  <minimise|increase> the <unit of measure> <object of control> <context>
   e.g. "Minimise the time it takes to put songs in the right order for listening."
Klement job story:       When <situation>, I want to <motivation>, so I can <expected outcome>.
Check each: no solution or technology named; still true if today's products vanished; verb + object present.
```

Switch interview timeline (rebuild in order, do not ask about forces directly):

```
First thought  ->  passive looking  ->  triggering event  ->  active looking  ->  deciding  ->  purchase  ->  first use
For each stage, capture: what happened, exact words, who was involved, what nearly stopped them.
Then sort what you heard into: PUSH / PULL / ANXIETY / HABIT.
Rule: switch happens only when  Push + Pull  >  Anxiety + Habit.
Recruit: switched to you / away from you / considered but didn't; within 30 days (ideally 14); 45-60 min; in pairs.
```

Opportunity score (outcome school):

```
For each desired outcome, survey actual users (1-10):
  Importance (I), Satisfaction (S)
  Opportunity = I + max(I - S, 0)
Bands:  <10 overserved (consider cutting) | 10-12 modest | 12-15 underserved, pursue | >15 strongly underserved
Verify exact thresholds against Ulwick's current guidance before acting on a borderline score.
```

## Common mistakes and how to avoid them

1. Picking the school by habit. Running an outcome survey to answer "why did this person churn", or a single switch interview to answer "where is the market's biggest need", answers the wrong question well. Spot it when the method does not match the question in step 1. Fix by choosing the school from the question, not from what you last used.
2. A job that is really a solution or a demographic. "Use our dashboard" is a solution; "what small businesses want" is a demographic. Spot it when the job names a product or a person type. Fix by reframing to the progress in the circumstance, with a verb and an object and no solution.
3. Stopping at the functional job. The functional job alone cannot tell two competing products apart and misses the anxiety that blocks a switch. Spot it when there is no emotional or social layer. Fix by adding both, each tied to a real quote.
4. Fabricated outcomes and scores. Writing desired outcomes from imagination, or guessing importance and satisfaction, produces a tidy table with no truth in it. Spot it when a score has no survey behind it or a quote has no source. Fix by surveying actual users and tagging every input to evidence; where there is none, say so.
5. Asking customers for the job or the forces directly. "What job are you hiring us for?" and "what pushed you to switch?" invite rationalised, after-the-fact stories. Spot it in the guide. Fix by rebuilding the timeline of what actually happened and letting the job and forces emerge.

## Quality bar: check the output against this before handing it over

- The school (forces-and-switch or outcome-driven) is chosen from the question and stated, with a reason.
- The core job is progress in a circumstance, with no solution or demographic in it, and it has a beginning, middle and end.
- Every statement uses the correct format for its purpose and passes the solution-free check.
- Switch work recruits recent switchers (within about 30 days) across all three switch types and rebuilds the timeline rather than asking about forces directly.
- Outcome work breaks the job into steps, writes outcomes in the direction-metric-object-context format, and scores them with Importance + max(Importance - Satisfaction, 0) against the stated bands.
- Functional, emotional and social layers are all present, each tied to a quote or observed behaviour.
- No job, force, outcome, quote or score is invented; single-source items are marked unconfirmed; borderline thresholds are flagged to verify.
- The output hands off to opportunity-solution-trees or a positioning task by name rather than deciding the roadmap.

## Guardrails

- Irreversible actions need a human. Launching a survey to customers, emailing recruits, or publishing positioning built on a job all reach real people. Draft them and ask for explicit confirmation before they go out.
- Never fabricate. If there is no evidence, the honest output is "we cannot model this job yet; here are the switch interviews or the outcome survey to run first", not invented forces, outcomes or percentages.
- Protect personal data. Switch interviews and surveys hold names, employers and buying detail. Refer to people by anonymised labels, do not paste raw transcripts or contact details into prompts or third-party tools, and keep survey responses where they already live.
- Mind the cost. Switch interviews and outcome surveys take real customer time, and a full outcome survey can be a large effort; run the smaller switch study first when the question is about a decision, and reserve the survey for when you need to size a market.
- Stay in scope. This skill models the job; it does not plan and run the interviews (customer-interviews) or choose which opportunity to build (opportunity-solution-trees). Hand off to those skills by name.

## Tool-specific appendix

The method above is tool-agnostic: a job statement, a forces map and an outcome table hold on paper or in any document. For switch interviews, the recording and note tools in the customer-interviews appendix apply, with the same consent and privacy rules. For outcome surveys (Typeform, Qualtrics, SurveyMonkey, or similar), ask the importance and satisfaction questions on one consistent scale, survey actual users of the job, and export the raw responses before scoring rather than trusting a built-in average. For a forces or outcome board (a whiteboard, FigJam, Miro, or a dedicated tool), keep one force map per job and tag each outcome to the job step it belongs to. Whatever the tool, the rules in the steps above do not change; the tool only decides where the model is stored.

## Sources

- Clayton Christensen, Taddy Hall, Karen Dillon and David Duncan, "Know Your Customers' Jobs to Be Done", Harvard Business Review, and Christensen's milkshake framing (job as progress; hire and fire). Last verified 12 November 2026.
- ReWired Group / jobstobedone.org, "Switch" and "Learn" (job as progress in a circumstance; the four forces; jobs are not found through surveys but by interviewing recent switchers). Last verified 12 November 2026.
- Bob Moesta, demand-side selling and switch interviewing; koji.so, "Switch Interviews" (recruit within 30 days, ideally 14; three switch types; 45-60 minutes; pair interviewing; rebuild the timeline before the forces). Last verified 12 November 2026.
- Tony Ulwick, Strategyn, "Customer Needs Through a Jobs-to-be-Done Lens" and the Intercom interview (job as a process of steps; the desired outcome statement format; outcomes free of solutions; a survey of 100-150 outcomes; unmet need as important and unsatisfied). Last verified 12 November 2026.
- Tony Ulwick, Outcome-Driven Innovation, the universal job map (define, locate, prepare, confirm, execute, monitor, modify, conclude) and the opportunity algorithm with its score bands. Verify exact thresholds against current Strategyn material before acting on a borderline score. Last verified 12 November 2026.
- Alan Klement and Intercom, the job story format "When [situation], I want to [motivation], so I can [expected outcome]", and its contrast with the user story. Last verified 12 November 2026.
- Dean Peters jobs-to-be-done skill and the jtbd-workshop skill, reviewed for structure and gaps (missing statement syntax, the score band gap at 10-11, functional-only jobs). Last verified 12 November 2026.

---
1.0.0, 12 November 2026: first release. Use, adapt and share this skill under CC BY 4.0: credit Afeez Adebayo, link afeezadebayo.com and the skill's download page. This is decision-support guidance, not a substitute for talking to your own customers.