The Jobs to be Done Framework as a Method to Understand Demand

In the previous instalment of the Demand Series, I introduced you to a handful of useful ideas:

1. We discussed the notion that the skill of uncovering demand underpins the domains of sales, marketing and product. Great people in these domains all have some facility with this skill, independent of their tactical-level skills in each domain.
2. That the difficult bit of uncovering demand is the ability to detach from your product, service, or offering in order to see the struggle and context of the customer. This is easier said than done. Some people are not able to do this — in fact, it’s entirely possible for an above-average salesperson or marketer to be decent at their core skill of marketing tactics or sales, but forever be bottlenecked on their inability to detach from their product. These folks will never be great.
3. Finally, we introduced the technique I used to get good at the skill of demand, and also the technique that I still use to teach demand to new marketers. This technique is Amy Hoy and Alex Hillman’s Sales Safari, which very intelligently packages a number of core demand concepts in one simple technique.

The basic idea that we will exploit in this piece is this: let’s say that you’re decent at Sales Safari. Let’s say that you know:

• What pains your customers want to solve when they buy your product.
• Why they pick you over alternatives.
• What worldviews they have that make them more likely to pick your solution over others.

We are left with the following questions:

• Where do potential customers (with these pains and worldviews) hang out?
• How do we reach them?
• How do we identify how likely they are to buy, and how do we increase the likelihood that they will buy?
• How do we speed up the buyer’s journey — that is, the urgency with which such customers will reach out and go through our sales process?

Sales Safari, you should realise by now, has nothing to say about these questions. Sales Safari is a demand identification framework. It tells you who to target, why they buy, and gives you a rough idea of how to find and attract them. The classical, marketing name for what Sales Safari allows you to do is ‘segmentation’. The second set of questions, on the other hand, are related to how your best-fit customers buy. In order to get the answers to these specific questions, we’re going to need a different framework.

A Brief, Non-Confusing Intro to the Jobs to be Done Framework

The basic idea of the Jobs to be Done framework is simple:

Every significant purchase decision goes through the same buyer’s journey. A buyer progresses along the stages on that journey when a trigger point occurs at each stage. If you can uncover these trigger points, you can create sales and marketing processes (or modify product features) to accelerate customers along the purchasing journey. The goal of the JTBD framework is to give you a set of tools to uncover the full buyer’s journey, along with these trigger points.

Before we continue, there are two nit-picky details that I’ll need to cover.

First: there are actually two Jobs to be Done Frameworks. The phrase ‘Jobs to be Done’ or ‘JTBD’ tends to be attributed to legendary Harvard Business School Professor Clayton Christensen, who popularised it in his 2003 book The Innovator’s Solution. Christensen passed away in 2020.

Two separate groups have laid claim to influencing Christensen’s ideas ever since:

1. Jobs as Activities: a typology patented by Andrew Ulwick and his licensees.
2. Jobs as Progress: a theory promoted by Bob Moesta, Chris Spiek, and the ‘ReWired Group’.

I will not get into to the fight between these two groups. It is not important to our discussion today. I will only say that I am referring to the second theory — Jobs as Progress, as presented by Moesta, Spiek, and company. I will also say that I do not have a strong opinion on Ulwick’s theory, only that I do not find him useful (or believable) for the outcomes I desire. This means that I am open to changing my mind on him, but I’m mostly ignoring everything Ulwick-related for now, unless or until I find his ideas useful for some set of outcomes I care about.

Moesta and Spiek’s ideas, on the other hand, I’ve already tested, and I can confirm that it works.

I’m bringing up this difference only to warn you if you decide to go spelunking in the literature for follow-up materials. I’m going to give you a list of books at the end of this essay, in case you wish to read more. But if you’d like to go beyond my recommended reading list, it’s probably a good idea to familiarise yourself with the two very different approaches — so you don’t get confused. I recommend this comprehensive article by Alan Klement to that end (archive.is backup).

Second, there is a common folk-misunderstanding that we must tackle before we continue. That misunderstanding is that the JTBD framework is only about what ‘jobs’ your product does for the customer. Perhaps the misunderstanding persists because there is a very compelling story that Christensen tells about milkshakes.

It goes something like this:

In his MBA course, Christensen shares the story of a fast-food restaurant chain that wanted to improve its milkshake sales. The company started by segmenting its market both by product (milkshakes) and by demographics (a marketer's profile of a typical milkshake drinker). Next, the marketing department asked people who fit the demographic to list the characteristics of an ideal milkshake (thick, thin, chunky, smooth, fruity, chocolaty, etc.). The would-be customers answered as honestly as they could, and the company responded to the feedback. But alas, milkshake sales did not improve.

The company then enlisted the help of one of Christensen's fellow researchers, who approached the situation by trying to deduce the “job” that customers were “hiring” a milkshake to do. First, he spent a full day in one of the chain's restaurants, carefully documenting who was buying milkshakes, when they bought them, and whether they drank them on the premises. He discovered that 40 percent of the milkshakes were purchased first thing in the morning, by commuters who ordered them to go.

The next morning, he returned to the restaurant and interviewed customers who left with milkshake in hand, asking them what job they had hired the milkshake to do. Christensen details the findings in a recent teaching note, “Integrating Around the Job to be Done.”

“Most of them, it turned out, bought [the milkshake] to do a similar job,” he writes. “They faced a long, boring commute and needed something to keep that extra hand busy and to make the commute more interesting. They weren't yet hungry, but knew that they'd be hungry by 10 a.m.; they wanted to consume something now that would stave off hunger until noon. And they faced constraints: They were in a hurry, they were wearing work clothes, and they had (at most) one free hand.”

The milkshake was hired in lieu of a bagel or doughnut because it was relatively tidy and appetite-quenching, and because trying to suck a thick liquid through a thin straw gave customers something to do with their boring commute. Understanding the job to be done, the company could then respond by creating a morning milkshake that was even thicker (to last through a long commute) and more interesting (with chunks of fruit) than its predecessor. The chain could also respond to a separate job that customers needed milkshakes to do: serve as a special treat for young children—without making the parents wait a half hour as the children tried to work the milkshake through a straw. In that case, a different, thinner milkshake was in order.

As a result, people believe that the JTBD framework is merely about divining what job it is that your product really solves for the customer. For instance, a handbag might be hired for the job of ‘portable storage for daily essentials’. But it is also, simultaneously, performing the ‘signal to other women that I am high status’ job — which is why folks pay luxury prices for a Birkin.

But this interpretation of the framework is mistaken.

I understand this misperception because it was something that I held, for years. I first encountered that milkshake story when I was a university student, more than 10 years ago. It’s stuck with me ever since. So imagine my surprise when I started digging into the JTBD framework properly and learnt that the milkshake story is just the tip of a more powerful toolkit.

To be fair, this misperception is not entirely wrong — the JTBD framework as presented by Christensen and Moesta can (and in fact was) used for this purpose. But the framework is more than that. The JTBD methodology gives you the tools for uncovering, identifying, and then manipulating the buyer’s journey. Uncovering such ‘jobs’ is merely part of the methodology. In truth, there are more levers you can use than just ‘modifying the product to better fit the job the customer “hired” the product to do.’

The Ideas That Make Up JTBD

There are a small handful of ideas that make up the JTBD framework. These ideas are:

• The timeline (aka buyer’s journey).
• The forces of progress (I think of these as the ‘four forces’, plus ‘the three sources of motivation’).
• The JTBD interview methodology (which we will demonstrate with a case).

Let’s go through them quickly.

The Timeline

The JTBD framework claims that every significant purchase is made the exact same way. Note that there are two exceptions to this, but we’ll talk about them in a second.

A typical buyer’s journey goes something like this:

• You have a first thought. There is some … pain, or need, that you have in your life, and you think “hmm, maybe I should look into solving this”.
• As a result of having that first thought, shortly afterwards you enter passive looking. This means that you’re not ready to buy, but you begin to notice solutions or products that might help you make progress on this need or pain.
• At some point, a trigger event occurs and you enter active looking. At this point you start to actively investigate various solutions or products to your problem. You begin to expand the notion of what a solution would look like but — importantly — you’re not making the purchase quite yet. You are fairly certain that you’re going to buy this product … soon. Some day. But not today.
• A trigger event occurs, and then you enter the deciding stage. This is where the buying decision is imminent. You have decided “ok, I’m DEFINITELY going to make this purchase, but which exact product am I going to buy?” Here you start debating — in a concrete way — possible tradeoffs.
• At the end of the deciding stage, you make a purchase.
• After the purchasing stage, you start consuming the product. This product or service should satisfy the need you have when you had your first thought. If this is a recurring revenue product, the consuming and satisfaction you get here will determine if you renew.