Jobs to Be Done Framework for Designers

Understand what your users are really trying to accomplish with the Jobs to Be Done framework. Learn the theory, the interview technique, and how to apply JTBD in design thinking.

People do not buy products. They hire them to do a job. That single sentence is the core of the Jobs to Be Done (JTBD) framework, and it changes how you think about design in a fundamental way. Instead of asking "what features should we build?" you ask "what job is the user trying to get done, and how well are current solutions doing it?"

The shift sounds subtle. It is not. It changes what questions you ask in interviews, how you frame problems, and which ideas you prioritize. It also pairs naturally with design thinking because both frameworks center on understanding human needs before jumping to solutions.

The Theory in Plain Language

Clayton Christensen, who popularized the framework, used a famous example: a fast-food chain wanted to sell more milkshakes. They surveyed customers, improved the recipe, adjusted the price. Sales did not budge. Then researchers watched what was actually happening. Nearly half the milkshakes were sold before 8:30am to commuters who needed something to make their boring drive more interesting and keep them full until lunch.

The "job" was not "drink a milkshake." The job was "make my commute less boring and keep me full." The milkshake was competing not with other milkshakes but with bagels, bananas, and boredom. Once the team understood the job, they made the milkshakes thicker (they lasted longer in the car) and moved the dispenser in front of the counter (faster purchase for people in a hurry). Sales went up.

The lesson: if you define your competition by product category, you miss the real competition. If you define it by the job the user is hiring for, you see opportunities your competitors cannot see.

Jobs Have Structure

A well-defined job has three dimensions:

Most product teams only address the functional dimension. That is why so many products are feature-complete but feel empty. The emotional and social jobs explain why people choose a beautiful, simple tool over a powerful, ugly one. The simple tool does the emotional job better.

How to Discover Jobs: the Switch Interview

The canonical JTBD interview technique focuses on the moment a user switched from one solution to another. This is different from a standard user interview because you are not asking about features or satisfaction. You are reconstructing the timeline of a decision.

The interview follows the user's journey backward from the switch:

The four forces model helps you understand the dynamics at play: push (frustration with current solution), pull (attraction of new solution), anxiety (fear of switching), and habit (comfort with the status quo). A user switches only when push plus pull overcomes anxiety plus habit.

JTBD Meets Design Thinking

JTBD and design thinking are complementary, not competing. Here is how they fit together:

Job Stories vs User Stories

A user story says: "As a [persona], I want [feature], so that [benefit]."

A job story says: "When [situation], I want to [motivation], so I can [expected outcome]."

The difference is that user stories anchor on the persona (which can lead to demographic stereotyping), while job stories anchor on the situation (which focuses on what is actually happening). Two very different people can have the same job in the same situation. A 22-year-old freelancer and a 55-year-old executive both need to "present ideas clearly to skeptical stakeholders." The situation is the same even though the personas are different.

Common JTBD Mistakes

Applying JTBD to Your Next Project

Start simple. Take your current project and ask: "What job did users hire our product to do?" Then ask: "What else could they hire to do that same job?" The answers will reveal your real competitive landscape and highlight the dimensions where you are under-serving users.

Combine this with empathy mapping and journey mapping to build a rich picture of user needs. JTBD gives you the "why." Empathy maps give you the "what they think and feel." Journey maps give you the "when and where." Together, they give you a complete understanding that leads to better design decisions.

Related guides: stakeholder mapping · user research on a budget · competitive analysis design thinking

Design Thinker Labs Home · All Guides · How It Works · Pricing