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:

Functional: The practical thing the person is trying to accomplish. "Organize my team's tasks so nothing falls through the cracks."
Emotional: How they want to feel during and after. "I want to feel in control, not overwhelmed." This is often more important than the functional dimension.
Social: How they want to be perceived by others. "I want my team to see me as organized and reliable."

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.

The four forces that determine whether a user switches solutions

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:

First thought: "When did you first realize you needed something different?" This reveals the trigger event.
Passive looking: "Did you start noticing alternatives, even without actively searching?" This reveals awareness.
Active searching: "What did you compare? What mattered most in the comparison?" This reveals evaluation criteria (which map to jobs).
The decision: "What made you finally pull the trigger?" This reveals the tipping point.
After the switch: "What happened after you started using the new thing? Any regrets or surprises?" This reveals unmet expectations.

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:

During the Initialize stage, use JTBD to frame the challenge around the job, not the product. "Help commuters feel less bored" instead of "improve milkshake sales."
During the Empathize stage, use switch interviews alongside standard user interviews to uncover jobs that standard interviews miss.
During the Define stage, write job stories instead of (or alongside) user stories: "When I am on a long commute, I want something that keeps my hands busy and my stomach full, so I arrive at work in a good mood."
During Ideation, evaluate ideas by how well they address the functional, emotional, and social dimensions of the job.

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

Making jobs too small. "Upload a profile photo" is a task, not a job. "Present myself professionally online" is the job. Jobs are bigger than features.
Making jobs too big. "Live a good life" is a life goal, not a job. Jobs are specific enough to design for.
Ignoring the emotional dimension. If your job statement is purely functional, you are missing the real motivation. Ask "why does this matter to you?" until you hit the emotional layer.
Confusing solutions with jobs. "I need a faster horse" is a solution. "I need to get across town quickly and reliably" is the job.

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.