Guide
Jobs-to-be-Done, the framework, interviews & how to apply it
What JTBD really is, the four forces, the switch interview, and how to write JTBD questions that surface real customer motivation.
Jobs-to-be-Done (JTBD) is a theory of customer behavior popularized by Clayton Christensen and translated into a practical interview method by Bob Moesta and Chris Spiek. The thesis: people hire products to make progress in a specific situation, not because they match a demographic profile. Christensen's milkshake study is the canonical example, where morning shake buyers were hiring the drink to survive a long commute.
Personas describe who the customer is. Jobs describe why they showed up today. Only the second one tells you what to build.
The central idea#
A job is the progress a person is trying to make in a circumstance, with functional, emotional, and social dimensions. When the current way stops working, the customer fires it and hires something else. Your product is one candidate competing for that hire. Two consequences fall out of this. First, your competition is whatever the customer was using before, which is often a spreadsheet, a habit, or doing nothing. Second, the unit of analysis stops being "the user" and becomes "the moment of struggle." Demographics correlate weakly with that moment. Circumstances correlate strongly.
This is also why feature requests mislead. A request is a customer's guess at a solution. The job is the problem underneath the guess. Moesta calls this distinction the difference between asking what people want and reconstructing what they actually did.
The four forces#
Every switch is governed by four forces. Two push the customer toward your product, two hold them back. A switch happens only when push plus pull beats anxiety plus habit.
- Push of the current situation:
The pain with the existing solution. Strong push sounds concrete: "I lost two hours every Monday rebuilding the same report." Weak push sounds aspirational. Without push, nobody moves.
- Pull of the new solution:
The vision of a better life with the new product. Pull is rarely about features, it is about the identity or capability the customer expects to gain. "I wanted to be the kind of team that ships on Friday."
- Anxiety about the new solution:
Fear that the new thing will not work, will be too expensive, will embarrass the buyer, or will be hard to learn. Anxiety is invisible to most teams and is the single largest reason qualified buyers stall.
- Habit of the present:
The gravity of the current way, even when broken. Switching has real costs: data migration, retraining, telling a boss the last decision was wrong. Most teams underestimate habit by an order of magnitude.
The switch interview#
A switch interview reconstructs the timeline of a real purchase, in order, in the customer's words. It is a guided recollection, not a survey, and it works because human memory is sharper for sensory detail than for opinion.
Set the scene
Anchor the conversation on a specific recent purchase, ideally within the last 60 days. Ask where they were, what device they used, who else was in the room. Concrete sensory detail confirms real memory and exposes confabulation.
Find the first thought
Identify the moment the customer first sensed something needed to change. This is rarely the day they bought. It is often weeks earlier, a Tuesday afternoon, a comment from a colleague, a screenshot they saved.
Find the trigger
Pinpoint what tipped passive frustration into active search. Triggers are concrete events: a deadline missed, a price hike, a teammate quitting, a new project assigned. The trigger is the gap between "this is annoying" and "I am opening tabs right now."
Find the consideration set
Map every alternative they evaluated, including doing nothing, building it themselves, asking a friend, and hiring a contractor. The real competition is rarely the products you assume.
Find the deciding moment
Locate the exact moment of commitment. A demo, a pricing page, a peer endorsement, a free trial that worked on the first try. Identify the anxiety that got resolved right before the credit card came out.
Find the outcome
Ask what their week looks like now. Did the product deliver the progress they hired it for? What did they fire to hire you? What might they fire next?
Writing JTBD questions#
JTBD questions are forensic. They reconstruct events instead of asking for opinions, predictions, or preferences. Lead with verbs of memory.
- Walk me through the day you decided to switch.:
Anchors the respondent in a real timeline and forces them out of generalities.
- When was the first time you thought about solving this?:
Surfaces the first thought, usually weeks before purchase. The story begins there, not at checkout.
- What were you using before, and what made it stop working?:
Captures push and habit at once. The answer reveals what your product must be measurably better than to win the switch.
- What almost stopped you from buying?:
The most underused question in the kit. It surfaces anxiety, which is the lever you can pull on your pricing page tomorrow.
Notice what these questions avoid. They never ask "would you use" or "how important is" or "what features matter most." Hypothetical questions return fiction. JTBD only works on events the respondent actually lived through.
Common mistakes#
Treating JTBD as a substitute for personas. They are complements. Personas describe segments, jobs describe motivations. Use both. If forced to pick one, pick jobs, but do not pretend the other is irrelevant.
Asking hypothetical jobs. "Would you use a product that..." returns invention. Switch interviews only work on past events. If the respondent has not lived it, do not ask about it.
Ignoring the social and emotional dimensions. Functional progress like "save time" is the surface layer. The real reasons people switch usually involve identity, status, anxiety relief, or how they expect to be seen by a boss or a peer. If your interviews only surface functional jobs, you stopped too early. Probe for who the customer told about the purchase, and how they framed it.
Running JTBD at scale#
The hard part of JTBD has always been operational. A proper switch interview runs 60 to 90 minutes, requires a trained moderator, and the patterns only become visible after 15 to 20 of them. Most teams give up after three. If you want to run JTBD-style interviews at scale without booking dozens of calls, an AI-moderated tool like Diaform can run them asynchronously in 10 to 15 minutes per respondent, probing for the four forces and pulling out triggers, anxieties, and the consideration set across hundreds of conversations in parallel.
For the surrounding practice, see user interviews for moderation craft, customer discovery for the broader discovery loop, and user research for how JTBD fits alongside other methods.
One practical thought to close on. The first three switch interviews you run will feel awkward and yield thin material. The tenth will reframe a roadmap decision. The discipline is to keep going past the point where you think you already know the answer, because the patterns that change product strategy live in the moments customers describe with vocabulary you did not expect.