Jobs to Be Done

---
name: jobs-to-be-done
description: Diagnose what "job" a customer is actually hiring a product, service, or workaround to do, using the Jobs-to-be-Done framework (Clayton Christensen's "progress in a specific circumstance," Bob Moesta's forces-of-progress and switch interview, Tony Ulwick's job statements and desired-outcome scoring). Use this whenever the user is trying to understand a problem before jumping to a solution, is confused about why customers churn, switch, or don't adopt something that looks objectively better, is segmenting users by demographics/persona and it isn't predicting behavior well, or is scoping a new use case and needs to know what progress the customer is actually trying to make. Not a fit once the problem is already well-understood and the question has shifted to prioritization (use focus-and-tradeoffs) or a go/no-go call (use decision-memo).
---

# Jobs to Be Done

People don't buy products — they hire something (a product, a service, a
workaround, even doing nothing) to make progress toward a specific goal
in a specific circumstance. The job is the progress being sought; the
product is just whatever gets hired to deliver it. Demographics and
personas often fail to predict behavior because two very different people
can be trying to make the exact same progress, and one person can hire
completely different things for different jobs in different moments of
their own life.

## The core move

Stop asking "who is the customer" and start asking "what progress are
they trying to make, and what's currently getting in the way of making
it." The circumstance matters more than the person — the same person
hires something different for the "get through a boring commute" job than
for the "feel like a good parent on a Saturday" job, even though it's the
same person both times.

## The four forces (Moesta)

When someone switches from an old solution (including "doing nothing") to
a new one, four forces are in tension:

- **Push** — dissatisfaction with the current situation strong enough to
  seek an alternative.
- **Pull** — the magnetism of the new solution, specifically how it
  promises to make the progress easier or better.
- **Anxiety** — uncertainty about the new solution (will it actually
  work, is it worth the risk, what if I look foolish adopting it).
- **Habit of the present** — the comfort and momentum of what's already
  being done, even if it's mediocre.

A switch happens when push + pull outweigh anxiety + habit. If adoption
is stalling, name which of the four is actually the blocker — increasing
pull (a better pitch) does nothing if the real blocker is anxiety, and
that's a very common mismatch: teams pour effort into making the pitch
better when the real problem is fear of switching.

## The switch interview (Moesta)

To find the forces at play, reconstruct the actual timeline of the
decision with someone who recently switched (or recently chose not to):
what was happening right before they started looking, what almost stopped
them, what tipped it, what they were worried about. Concrete recent
events beat abstract stated preferences — "walk me through the day you
decided to look for something else" surfaces more than "what do you look
for in a solution."

## Job statements and desired outcomes (Ulwick)

For a sharper, more structured version of the same idea:

- **Job statement**: verb + object + context, stripped of any reference
  to a specific solution. "Reduce time spent reconciling expense reports
  during month-end close," not "get a better expense tool."
- **Desired outcome statements**: "minimize/increase [metric] of [process
  step] when [context]" — specific and measurable, not "make it easier."
- **Opportunity = importance × (satisfaction gap)**: outcomes that are
  highly important but poorly satisfied by current options are where the
  real opportunity sits — not the outcomes people mention most often,
  which are usually just the ones already well served (and therefore top
  of mind).

## Functional, emotional, and social dimensions

The job usually isn't purely functional. Ask what emotional progress
("feel more in control," "feel confident/competent") and social progress
("feel or be seen as good at this") are bundled into the functional one —
missing these is a common reason a functionally-superior alternative
still loses to something that resonates more emotionally or socially.

## Common failure mode

Segmenting or designing around who the customer is (age, title, company
size) rather than what job they're hiring for, then being surprised when
the segment doesn't predict behavior. If demographic segmentation isn't
predicting adoption or churn, that's the signal to re-run this framework
instead of collecting more demographic detail.

## Output

Name the job in one job-statement sentence, identify which of the four
forces is actually the blocker (if this is about a stalled decision), and
flag whether the current segmentation approach is actually job-based or
just demographic. If this feeds into scoping a use case, hand off to
`outcome-hypothesis` with the job statement as the starting point rather
than a vague value proposition.