Skip to content
InsideUX Design

UX glossary

Jobs to be Done

Jobs to be Done is a way of thinking that asks what task people want to get done with a product and what progress they’re trying to make in their situation. It focuses on context and motivation rather than traits like age or job title.

Imagine it’s 7:30 in the morning and you’re at the hardware store buying a drill. You don’t actually want a drill. You want to get a shelf up on the wall so the boxes in the hallway finally disappear. The drill is just the means. If a good adhesive hook were just as sturdy, you’d buy that instead.

Explained simply

Jobs to be Done, or JTBD for short, is a way of thinking that asks exactly this question: What task does a person want to get done, and what progress are they trying to make in their situation? According to this approach, people “hire” products for a “job.” If a product does the job well, it gets hired again. If it does a poor job, it gets fired and replaced with something else.

The approach was popularized above all by Harvard professor Clayton Christensen. Together with colleagues, he described it in the Harvard Business Review in 2016. The Christensen Institute stresses that every job has a functional, a social and an emotional side. So someone putting up a shelf may not just want more space, but also a home that looks tidy when guests come over.

The famous milkshake example

The most frequently cited story is about a fast-food chain that wanted to sell more milkshakes. Asking people about the perfect milkshake got nowhere. Things only got interesting when a research team watched when and why people actually bought shakes: a large share went to commuters early in the morning who came alone and took the shake to go. They wanted something to fill a long, boring drive to work, had only one free hand and needed something to keep them full until late morning. So the shake wasn’t competing with other shakes. It was competing with bagels and doughnuts.

Job stories: JTBD in everyday design work

In UX design, JTBD is often captured in so-called job stories. The format comes from the team at software company Intercom and follows the pattern: “When [situation], I want to [motivation], so I can [outcome].” Unlike a classic user story, the focus isn’t on a role but on the moment the need arises. That makes JTBD a good complement to the persona: the persona shows who someone is, while the job story shows what that person wants to achieve in a specific situation.

An example

A team is building a banking app. Before, the backlog says: “As a customer, I want an overview of my spending.” The result is a chart that hardly anyone opens. After interviews, the team writes a job story: “When money gets tight at the end of the month, I want to quickly see where it went, so I can decide what to cut back on until payday.”

Now the solution looks different: an alert when the balance drops unusually fast, and a list of the biggest expenses over the last few days. The feature responds to a real situation rather than an abstract role. For how to approach the interviews behind it, see What Does a UX Researcher Do?

In practice

  • Ask about the moment. In interviews, have people walk you through the last specific time they had the problem. General wishes reveal less than a real sequence of events.
  • Think about every alternative. Your product also competes with spreadsheets, sticky notes or simply doing nothing. Ask what people use today instead of your solution.
  • Keep jobs solution-neutral. A job describes the goal, not the feature. “I want to know where my money went” leaves room for more solutions than “I want a chart.”

Related terms

Persona, User Research, Journey Map

Sources

More terms

Full glossary