← Blog

Jobs to be done: a researcher's guide

16 October 2026 · 5 min read

Illustration of the jobs to be done framework

Jobs to be done arrived with a milkshake story and a big promise: stop studying customers, start studying the progress they are trying to make. Somewhere between the Harvard lectures and a thousand product workshops, jobs to be done became two things at once, a genuinely useful research lens and a rich vein of consultant hype. It is worth separating them.

This is a researcher's guide to jobs to be done: what the framework actually claims, how the interviews behind it work, and the misuses that give it a bad name.

What jobs to be done actually claims

The core idea is simple. People do not buy products because of who they are; they hire products to make progress in a specific circumstance. When the product does the job well, they hire it again. When it does the job badly, they fire it and hire something else.

The famous illustration is the milkshake story Clayton Christensen liked to tell, drawn from consulting work for a fast food chain. The chain wanted to sell more milkshakes and had sliced its data by every customer attribute imaginable, to no effect. As the story goes, watching actual buyers revealed that many were morning commuters hiring the milkshake to make a long, boring drive more interesting and to hold off hunger until lunch. The milkshake's real competitors were not other milkshakes; they were bananas, bagels, and boredom. Once you see the job, the improvement ideas change completely: make it thicker, make it easier to manage one-handed, speed up the queue.

Three parts of the claim matter for researchers:

  • Circumstance beats attributes. The situation someone is in predicts behaviour better than their demographics. A struggling moment, not a persona, triggers the hire.
  • Jobs have layers. There is a functional job (get from A to B), an emotional job (feel in control), and a social job (look competent to my team). Products that nail the functional job can still get fired on the emotional or social ones.
  • Competition gets redefined. Your product competes with everything else that gets the job done, including spreadsheets, sticky notes, and doing nothing.

If you have read our piece on market research and UX research, you will notice jobs to be done sits right at the seam: it asks a market-sized question, why people buy, with the field methods of user research.

The switch interview

The signature jobs to be done method is the switch interview, developed by practitioners such as Bob Moesta. Instead of asking people what they want, you find people who recently switched, bought, cancelled, or churned, and reconstruct the true story of how that happened.

The style is documentary, not hypothetical. You anchor everything in real events: "Take me back to the first time you thought about changing. Where were you? What had just happened?" From there you walk the timeline that most switches follow: a first thought, a period of passive looking, a trigger that tips it into active looking, a deciding moment, and the first use. You are after specifics, the day, the trigger, who else was in the room, what almost stopped them. The same commitment to concrete, real events powers contextual inquiry, and for the same reason: people generalise badly about themselves but remember stories well.

Practical notes: recruit recent switchers, because memories of the timeline decay within weeks. Expect the useful material in the detours, the hesitations and workarounds. And resist the urge to pitch or probe on features; the interview is about their progress, not your product.

The four forces of progress

Jobs to be done offers a tidy model for why switches happen or stall, usually called the four forces. Two forces push toward change: the push of the current situation (frustration with what they have) and the pull of the new solution (the appeal of what could be). Two forces hold people back: anxiety about the new thing (will it work, will I look foolish) and the habit of the present (what they know, what already fits their routine). A switch happens when push plus pull outweighs anxiety plus habit.

This is the most quietly useful part of the framework, because it reframes adoption problems. Teams instinctively respond to slow uptake by adding pull, more features, more benefits messaging. The forces model points somewhere else first: adoption often stalls on anxiety and habit, and the highest-leverage work is reducing them, with better onboarding, reversibility, migration paths, and proof it works for people like me.

Where jobs to be done goes wrong

The misuses are as instructive as the method:

  1. Jobs so abstract they explain everything. "Help me feel in control of my life" is compatible with buying a calendar app, a gym membership, or a dog. A useful job statement is anchored in a circumstance and falsifiable.
  2. Workshop jobs. Teams brainstorm job statements in a conference room without interviewing a single switcher. Jobs to be done is a lens for evidence, not a substitute for collecting it.
  3. Personas with new labels. Renaming your segments as "jobs" changes the vocabulary and nothing else. The unit of analysis is the struggling moment, not the person.
  4. Framework wars. There are competing schools, Christensen's jobs-as-progress and Ulwick's outcome driven innovation with its quantified desired outcomes, and the arguments between them are mostly beside the point for working researchers. Take the interviewing discipline and the forces model; leave the theology.
  5. Applying it to everything. Jobs to be done explains why people adopt, switch, and churn. It has little to say about whether your checkout flow is confusing. Use the right tool.

A lens, not a religion

Treated as a lens, jobs to be done gives researchers real gifts: interviews anchored in true stories rather than speculation, a competitor list drawn from reality, and a model of adoption that takes anxiety and habit seriously. Treated as a religion, it produces abstract job statements and workshop theatre. Keep the discipline, skip the incense, and let the switchers tell you what actually happened.


People of Research is a community and newsletter for UX researchers, market researchers, and product people who want to know why customers really buy. Join us and get the good stuff in your inbox.

Join 7,500+ researchers, free

One email a week, a global community, and events near you. No noise, just the people and ideas that matter.