“Jobs to be done” (JTBD) is one of many approaches for articulating insights about your users or customers. It’s a framework that is most useful when you’re still defining the problem your product or service needs to solve. Like personas, defining “jobs” helps teams or organizations focus on meeting real needs.

A customer “job” is a process that someone undertakes to reach some objective. A job can be functional, emotional, or social. A job’s also complex. There’s often a main job, but every job may comprise many smaller jobs.

“[Jobs] say nothing about how an organization or team meets a need; they seek only to clarify or align around what the need actually is. ”

They’re multi-faceted, but stable. Jobs don’t change much over time, meaning they provide a useful “fixed point” for innovation and design. And, they’re solution agnostic. That’s what makes them valuable. Jobs should be future-proof and open up many avenues of solution design. They say nothing about how an organization or team meets a need; they seek only to clarify or align around what the need actually is.

But many people find JTBD confusing. This is mostly due to acrimony between practitioners rather than complexity in the method itself. To put it simply, there are a couple of different philosophies about JTBD and the proponents each can be quite vocal about which way is correct.

That’s too bad. As Emerson says, “a foolish consistency is the hobgoblin of little minds.” A kind of rigid adherence to orthodoxy in the name of being more correct doesn’t help anyone.

The good news is that if you don’t get sucked into the debate, both approaches have something to offer as a tool for uncovering user needs.

There are five key points:

  1. JTBD as a framework assumes that nobody actually wants your product. They want to achieve an outcome or objective.

  2. A job is a process that someone undertakes to achieve that outcome. Your product can help with this.

  3. Jobs can be multi-faceted. Main jobs can comprise many subordinate jobs. They can be functional, but also emotional or social.

  4. Customer segments are best defined by shared needs and desired outcomes, not demographics.

  5. JTBD does not specify solutions. It’s about capturing needs.

Okay. Now, some more detail.

Why jobs to be done?

People look at jobs-to-be-done as an alternative to personas. One problem with personas is that they are short on context. They’ll go into deep (sometimes excruciating) detail on demographic information, but lack anything on causality. That is, they don’t say much about the motivation behind the user or customer’s search for a new solution to their problem. To put it another way, they don’t tell a story. They might define pain points, challenges, or needs, but they don’t identify a crisis point or any inherent tension.

This lack of context can lead to misunderstanding and confusion within teams. When our brains are faced with facts absent of context, we fill it in ourselves. As Alan Klement points out, this can lead to unstated differences in understanding between teams. Each member of the team might fill in those narrative gaps differently. As a result, one team can have multiple divergent interpretations of even one persona.

JTBD flips this and brings motivation to the fore. Klement talks about the “consideration set,” or the different factors that someone considers when making a decision about which solution to “hire” to complete their job. These factors, Klement argues, are usually far more relevant when designing something than a user’s age (or photograph, or hobbies…) JTBD, then, de-emphasizes demographics in favour of context of need.

Job stories versus user stories

JTBD is also sometimes positioned as an alternative to user stories. This isn’t exactly the case. JTBD is usually is part of discovery work, whereas user stories are more about implementation. You could easily apply a JTBD methodology and then user stories down the road when you’re organizing the work a development team needs to do. But, when you’re transitioning between the discovery phase and the design phase, “job stories” can help to maintain a focus on user needs.

In contrast to a user story, which puts the emphasis on the persona interacting with a solution, the job story puts the emphasis on the situation.

So, a user story is written like this:

As a working parent, I want to order take-out so I can spend time with my kids instead of cooking.

A job story looks like this:

When I get home from a long day at work, I want to minimize the effort required to get a meal on the table so I can spend time with my kids instead of cooking.

The revised sentence foregrounds the situation and context rather than the actor. Job stories can get quite specific about this by adding a lot more qualifiers. For example:

When I get home from a long day of work, and I’m tired and feel pressured to put food on the table, I want to minimize the effort required to prepare a meal so I can spend time with my kids instead of cooking.

This layers in rich detail that can help facilitate empathy with the actor described in the story. And, there’s virtually no limit to the amount of detail you can layer in here. If your research tells you that your audience has as a subordinate job related to making that meal healthy, you can weave that in. Or, you might have learned that the main stressor is actually around deciding what to put on the table. If these are important aspects of the consideration set, they can and should be included in your documentation.

But again, note that these say little about the solution. They assume that there’s still some design that needs to take place around what the solution looks like. As the solution is refined and specified, you may still need to think in user stories if that’s what your development team works best with.

The debate over JTBD

So why are so many people so confused about JTBD?

Well, now we’re getting into a bit of a debate. There are several schools of thought about JTBD. Each one has its advocates, some of whom are quite vocal about their approach being the one, true way. It’s a bit of a turf war. And then there are skeptics of the model—including some big talking heads—who muddy the water a bit, too, by (rightly or wrongly) conflating JTBD with other approaches or techniques they’ve seen before.

I’ve mentioned Alan Klement already, so let’s start with him. Klement understands a job as being about progress. He wants to know what motivated somebody to seek a new solution in the first place.

“A human being can imagine a better way of life, or a more fully evolved state of being. When they begin to take steps toward that vision of self, they have a job to be done.”

For Klement, it’s not because they want to do anything in particular; it’s because they want to be something. A human being can imagine a better way of life, or a more fully evolved state of being. When they begin to take steps toward that vision of self, they have a job to be done. There’s a huge emotional component of desire.

It’s a bit philosophical. I suspect Klement’s a fan of, or at least is influenced by, Marshal McLuhan. McLuhan defined technology as an extension of human capability. Every technological innovation we create extends our body (or mind) beyond its physical limitations.

To be clear, I love being philosophical about design and technology. But, I can get that for some people this sounds impractical. Klement leaves a lot of white space. Klement says that innovation isn’t about providing new ways to perform tasks; it’s about eliminating the tasks altogether.

More than likely, a lot of people reading this—and maybe a lot of people reading or following Klement on Twitter—don’t have that’s required to work in that territory. They’re dealing with constraints that are imposed by their industry, their market, their employer, or the living product they’re working on. In that situation, this much leg room can feel uncomfortable. It’s like asking someone to build a Lego car from a 10,000 foot view, and only using the red bricks. But it’s also alluring, because that’s a pretty nice perspective to have! But if you try to adopt it and you’re not able to work at that level of abstraction, it can create a deep sense of frustration.

That’s why if someone asks me about JTBD, I’m more likely to point them to Anthony Ulwick.

Ulwick has been developing his approach to JTBD for decades now as part of his “outcome-driven innovation” framework. Instead of focusing as Klement does on the deep emotional longing that someone has for a better state of being, Ulwick emphasizes the outcome by which the customer or user measures success.

Like Klement’s version of a job, this should be something that is stable and constant. It’s goal that someone wants to achieve—but a concrete result. For Ulwick, something like “cut a straight line” is a job. It’s a bit less abstract than Klement’s model.

For Ulwick, a job is never isolated or self-contained. Typically, it’s attached to a number of associated jobs. These can include emotional or social jobs. For instance, a core functional job might be to maintain the health of your teeth. But, under that are related jobs such as minimizing your discomfort while doing so, or appearing more attractive to others.

Therein lies the opportunity. You can define a market segment based on clusters of related jobs. And, if you can find a segment whose jobs are under-served, you have uncovered a space ripe for innovation and a way to differentiate your product from your competitors who may also solve for the same main job.

Conclusion and further reading

Klement and Ulwick share a lot in common—maybe more than either one would care to admit. But ultimately, it’s not useful to get bogged down in semantics or orthodoxy.

What is valuable is to think of JTBD as a valuable tool in your kit. It’s a powerful approach to discovering your customers’ or users’ unmet needs, and provides language to help articulate those needs in a way that can help a team align around designing a valuable solution. I don’t think it’s accurate to pit JTBD against personas, or against user stories; in fact, JTBD is doing different work and complement those other techniques quite nicely.

If you’re interested in learning more, I highly recommend Jim Kalbach’s book The Jobs to be Done Playbook. It’s a practical guide to the framework, offering a set of actionable “plays” that can be used to implement the JTBD framework. These include interview guides, techniques for writing effective job statements, and survey methodologies for prioritizing among different jobs. Kalbach also usefully cuts through the cruft around whose JTBD methodology is “correct.”

If you do want to wade into that debate, here’s Alan Klement’s take on the “two—very—different interpretations” of JTBD, and here’s Anthony Ulwick’s rebuttal and critique of Klement.

If you’re more interested in Klement’s approach, you can read his book When Coffee and Kale Compete. He’s also written an essay on how to replace the user story with the job story, and replacing personas with characters. I do like his take on consideration sets, which can help provoke thought around the kinds of trade-offs your users are likely to make.

Jim Kalbach and Anthony Ulwick hosted a streamed discussion digging into their perspectives on JTBD. It’s a rich conversation that addresses a lot of specific questions people have. Ulwick’s also identified what he sees as the core tenets of JTBD and looks at how needs can act as a “constant” in the innovation equation. He’s also written a useful guide to mapping customer jobs.