Jobs to Be Done

The problem it solves

Product decisions usually start from a description of the customer, so the room fills up with segments, personas, job titles and firmographics, most of it accurate and very little of it predictive. Two people matching on role, budget and seniority will do completely different things on a Tuesday afternoon, and the description gives you no way of telling in advance which of them you have.

The visible cost is a roadmap assembled from feature requests, because the requests are the one thing in the room specific enough to act on. Each of them is a solution somebody has already designed, arriving without the reasoning that produced it, and a ranked list of those is a plan to build other people's first drafts.

The cost that stays hidden for longer is that the competitor set gets drawn around the category rather than around the customer. A healthy win rate against three named rivals is compatible with almost the whole market handling the problem in a spreadsheet, in a conversation, or by putting up with it, and the report that would show you this doesn't have a row for any of them.

The idea

Start from the progress somebody is trying to make in a particular situation, and treat whatever they use as something hired to make that progress. The unit is the job, and locating it in the situation rather than in the person is the move that does the work, because a situation recurs across people whose demographics have very little in common.

Take a manager trying to find out what's really going on in a team they don't sit in. That situation turns up in a fifty-person company and a fifty-thousand person one, for a first-time team lead and a director of twenty years, and each of them has already hired something for it.

Enlarge: The category you measure is a subset of the things already hired for the job, and the rest of them never appear in a win-loss report.

One job is named at the top, finding out what's really going on in a team you don't sit in. Below it a box holds six things already hired to do that job. A dashed box inside it encloses the top three, your tool, a rival tool and a status report, labelled the category you measure. The other three, a skip-level, asking a peer and doing nothing, sit outside it.

The category you measure is a subset of the things already hired for the job, and the rest of them never appear in a win-loss report.Close

The category you measure is a subset of the things already hired for the job, and the rest of them never appear in a win-loss report.

The first consequence is the redrawn competitor set. If that's the job, then the things competing for it are your dashboard, a rival's dashboard, the weekly status report, a skip-level lunch, a quiet word with a peer, and doing nothing at all. The last of those usually holds the largest share and turns up in no competitive analysis anywhere, which is why the framing is at its most useful against non-consumption rather than against rivals.

The second consequence is that a job statement has an altitude, and the two ends of the range fail in opposite directions.

Enlarge: Both ends of the range are common failures, and the theory has no rule for finding the usable band between them.

Both ends of the range are common failures, and the theory has no rule for finding the usable band between them.Close

Both ends of the range are common failures, and the theory has no rule for finding the usable band between them.

Pitched at the feature somebody asked for, the statement tells you what you already knew and quietly makes the request into the problem. Pitched at a life goal it excludes nothing, so a roadmap justified against it can contain anything. The usable band is where the statement rules some plausible proposals out while still admitting a competitor from outside your category, and finding that band is craft rather than method, which is one of the honest things to say about the framework.

The history is contested and worth knowing, because it changes how you read everything written about this. Tony Ulwick had been building an outcome-based innovation method through the 1990s, named it Outcome-Driven Innovation in 1999, and introduced the thinking to Clayton Christensen, who published the jobs framing in 2003 and stated it most clearly in a 2016 article. Outcome-Driven Innovation is Strategyn's registered mark for their own commercial methodology rather than a general name for this idea, and it's worth using it that way. The two strands have diverged since, so two people saying jobs to be done are often describing measurably different procedures, one producing a list of quantified outcomes to prioritise and the other producing an account of a switch and the forces around it.

How to use it

Interview people who switched recently, and ask about sequence rather than preference. What were you doing before, what happened on the day you started looking, what did you try first, who else was involved, what nearly stopped you. Stated preferences are unreliable in a way that's been demonstrated repeatedly, and the sequence of a switch somebody actually made is much harder to confabulate after the fact.

Write the job as a situation and a desired progress, then test the statement by naming a plausible proposal it rules out. If you can't name one, the statement is describing a mood and it will approve whatever was going to happen anyway.

List everything currently hired for that job, and put doing nothing on the list deliberately, because it's the entry most likely to be missing and most likely to be winning. For each one, write down what it does well enough to keep, since that's the bar a replacement has to clear and it's usually lower and stranger than a feature comparison suggests.

Then check the roadmap against the list rather than against the competitors. Work that improves your position against a rival dashboard while leaving the spreadsheet untouched is a decision about which fight to have, and it's better made deliberately than by default.

Where it breaks down

Every concept here has one. It is the section most summaries leave out.

The evidence is retrospective and thinner than the confidence around it. The theory is assembled from cases read backwards, and its most repeated example has no published data behind it that anyone has produced. There's no controlled evidence that running a jobs process produces better products than a competent alternative, and the literature that would settle it mostly doesn't exist.

A frame that explains any outcome afterwards predicts none of them beforehand. Once a purchase has happened you can always find a job behind it, and the account will be convincing, because you're fitting an explanation to a result you already have. The discipline that rescues it is converting the account into a prediction about accounts you haven't looked at yet, and that step is skipped almost everywhere it's taught.

Two schools share the name and hand you different artefacts. Ulwick's method produces quantified outcome statements to measure and rank; Christensen's produces a narrative of a switch and the forces pushing and pulling on it. Somebody telling you they do jobs to be done has told you very little about what they'll actually do, and consultancies on both sides describe the other as a misunderstanding.

There's commercial interest on all sides of it. Outcome-Driven Innovation is a paid methodology and a registered mark, jobs to be done is taught for money by several organisations, and the most confident writing about it is produced by people selling training in it. That isn't disqualifying and it does explain the absence of published negative results.

Altitude has no rule, and both failures are common. The theory says a job should be stable and solution-agnostic, and it gives no procedure for choosing how abstract to make it. In practice teams land too low and rebuild the feature request, or too high and produce a sentence that approves everything, and the defence available is judgement applied case by case.

It's a demand-side tool and gets applied to constraints that aren't demand. Where the binding problem is procurement, regulation, distribution, switching costs or a network effect, a well-researched job statement is accurate and changes nothing, and the framing offers no signal that you're in that case. It's particularly tempting in exactly those markets, because understanding the customer better is the more comfortable thing to be doing.

Interviewing switchers systematically undersamples the people who never bought. The method's own logic says non-consumption is where the opportunity is, and its main research technique reaches people who have already entered a buying process. Reaching the others is possible and it's harder, slower, and routinely dropped.

In one line

Ask what progress somebody is trying to make in a recurring situation and what they currently hire to make it, and the answer usually names competitors your category has never counted.