ARTICLE · Research

Jobs to Be Done: three different schools under one name

Boris Kaptelov · 02.08.2026 · 9 min

Someone at a meeting says, "we use JTBD." The reference is to the Jobs to Be Done framework — the idea of a job that a product is hired to do. Then it turns out that one participant means an eight-step job map with formalized success criteria, another means the four forces and a purchase timeline, and a third means the "When…, I want…, so that…" wording used in development task descriptions.

All three are right. At least three traditions coexist under this name. They share the image of hiring a product for a job and differ in everything else: in the unit of analysis, in the type of interview, in the form of the deliverable, and in the role of quantitative validation.

A practical point follows from this. The statement "this approach requires doing it this way," without naming the school, is methodologically empty. And if a team has assembled elements from all three traditions, that is a custom research design of their own, not the original standard — with all the consequences for what can be claimed from the result.

School one: progress in circumstances

The line of Christensen and his co-authors defines a job not as a product function and not as an isolated task, but as the progress a person or organization is trying to make in particular circumstances. Circumstances include the situation, constraints, prior events, and the social context.

Two consequences follow, and they are what made the approach popular. The same person hires different solutions for different jobs. The same product does different jobs in different situations. Segmenting by buyer attributes no longer explains choice.

This school distinguishes functional, social, and emotional dimensions. Functional is a practical change of state. Social is how the person wants to look in the eyes of others. Emotional is the desired inner state. These are not three independent jobs and not a mandatory exhaustive classification: in any concrete choice they are usually intertwined into a single complex of reasons.

The line's main contribution is the contrast between a correlational description of the buyer and a causal story of choice. Age, income, or company size may correlate with a purchase without explaining why the solution became necessary at that particular moment.

And here lies its main boundary. An interview reconstructs the presumed mechanism of choice. It does not prove causality in the sense in which an experiment establishes it.

School two: the job and measurable success criteria

Ulwick's approach, known as Outcome-Driven Innovation, formalizes the same idea far more rigorously.

The central unit is the core functional job of a specific job executor. The job executor is distinct from the buyer, the payer, the interface user, and the person who makes the organizational decision. In a corporate purchase these are usually different people, and the approach requires you to decide whose job you are studying.

The job is described independently of any solution, as a verb plus an object. It is then broken down into a job map: the article by Bettencourt and Ulwick proposes eight generalized steps — define, locate, prepare, confirm, execute, monitor, modify, conclude. This is a normative management model for decomposing activity, not an empirically established universal sequence of all human behavior.

For each step, desired outcomes are formulated — the criteria by which the executor judges success. They are recorded in a standardized, solution-independent form: minimize the time required to do something, minimize the likelihood of something. After that, importance and current satisfaction are measured quantitatively.

Here is a crucial point that gets lost in retellings. In this approach, interviews produce the list and the wording of the outcomes. The conclusion about which outcomes are widely underserved belongs to the quantitative stage. Without it, you have a job map and no priorities.

And one clarification against a common formulation. Desired outcomes are often described as the metrics by which users unconsciously evaluate the job. That claim is too strong. A desired-outcome statement is an analytically constructed description of a success criterion, derived from respondents' speech and experience. Its status as a conscious or unconscious internal metric is not separately established.

School three: reconstructing a real switch

The switch-interview practice associated with Moesta and Spiek studies neither an abstract need nor the full process of getting a job done, but a specific transition: a first purchase, a change of supplier, the replacement of a habitual solution, abandonment of a product, or keeping the status quo.

The interview is built as a backward reconstruction: from the moment of purchase back to the early events that made the previous situation unsatisfactory. The timeline usually includes the first thought, passive looking, events that intensified the dissatisfaction, active looking, comparison of alternatives, the decision, and the first post-purchase experience.

The four forces name the push of the current situation, the pull of the new solution, anxiety about the switch, and habit. The scheme resembles the academic push–pull–mooring model proposed by Bansal, Taylor, and St. James, but their origins and operationalizations differ, and similar vocabulary is no reason to treat them as one theory.

Two boundaries worth keeping in mind. The "first thought" is not an objective cause but the interviewee's reconstruction of the early moment when intent began to form, with all the limitations of memory. And the technique requires that a choice event exist: it works poorly for needs that have not yet led to a search, for entirely new categories with no analogue, and for routines with no noticeable switching.

The job story is a format, not a method

A separate note on the "When…, I want…, so that…" construction, which many consider the core of the approach.

It is not an original element of either Christensen's or Ulwick's work. The format emerged in product work at Intercom and was named the job story by Alan Klement. Its purpose is to compress research material into a description of situation, motivation, and expected outcome that is usable in design discussions.

Hence the main caution. A job story is not the job itself, not an interview transcript, and not a proven mechanism. Two equally well-formed sentences can be built on deep research or invented by a team in a meeting with no data behind them. The format carries no built-in standard of evidence and does not replace keeping the sources, the counterexamples, and the boundaries of applicability.

In practice, this means that next to every job story there should be a reference to what it was built from. Otherwise, six months later no one will be able to tell a finding from a guess.

Getting the level of the "job" right

A problem common to all the schools: the word "job" is used at different levels of abstraction, and both extremes are useless.

Too low turns the job into an action inside an existing product: "press the pay button." Too high turns it into a vague life goal: "be successful." The working level lies between the two — progress or an activity that keeps the context but does not lock in the means of getting it done.

Alongside this, four things need to be kept apart. A task is a discrete action or step. A desired outcome is a criterion for how well the job is done. A solution is a specific product, service, person, process, or a decision to do nothing. The job is what all of this is happening for.

What the approach delivers and what not to expect from it

It is a managerial frame of interpretation, and that is its strength, not a flaw: it poses a question that otherwise goes unasked and leads to findings that segmentation by buyer attributes never reaches. That is exactly why the approach has held up in practice for twenty years.

At the same time, no single standard for these interviews exists, and that is worth knowing before you take someone's result for a validated method. The review by Özal and Münch notes how limited the empirical literature is on how such interviews are actually conducted. The practical consequence: ask whoever runs the study which school they follow and what data it yields — because the school determines the result.

A separate word on numbers. The methodology authors' claims about innovation success rates and threshold improvements are data from a particular consulting practice. You may use them; you may not cite them as established patterns until the calculation methodology is published. We apply this rule to our own numbers as well.

And one shared boundary, identical for all three schools. In this logic, an in-depth interview can substantiate the existence and structure of a particular pattern of choice within the corpus studied. It does not establish the prevalence of the job, segment size, demand elasticity, purchase probability, or the causal effect of a future solution. For that, you need a quantitative, behavioral, or experimental design.

What to do with this

Three practical rules.

Choose the school for the task, not for its popularity. If you don't understand why people buy — the Christensen line. If you do, but need to set development priorities — Ulwick, plus the mandatory quantitative stage afterward. If there are real transitions to unpack — switch interviews.

Don't mix silently. Combining is possible and often useful. But then each stage keeps its own boundaries in the report: the timeline speaks to the mechanism of the switch, the job map to the decomposition, the survey to the priorities. A conclusion that merges them into one will inherit the weaknesses of all three.

Call things by their exact names. "Desired outcomes" is Ulwick's term, not automatically discovered psychological metrics. The approach's ability to lead to breakthrough products is a claimed advantage of the approach, not a guaranteed consequence of running interviews. How a conversation about the customer's real job actually works — and why the competitor is often not who you think it is — is the subject of a separate article.

If you need to choose a school for a specific task, that is precisely the first working conversation: we look at what decision you are making, whether you have transitions to unpack, and whether a quantitative stage is needed, and we assemble the design around that. Two to three weeks for the diagnostic, then a turnkey project if the scope calls for it.