Jobs to Be Done Framework
Understanding what users are trying to accomplish (not what feature they want) reveals design opportunities others miss.
What is Jobs to Be Done?
Jobs to Be Done (JTBD) is a framework for understanding user motivation. Instead of asking “what do users want in a product?”, JTBD asks “what is the user trying to accomplish?”
A customer isn’t buying a drill. They’re buying the ability to make a hole. A customer isn’t buying a dating app. They’re trying to meet someone. A customer isn’t buying a project management tool. They’re trying to organize their team’s work.
The “job” is the outcome the user wants. A well-designed product makes the job easier. A poorly designed product makes the job harder, even if the features are impressive.
One sentence punch: People don’t want your product; they want to accomplish something, and your product is a means to that end.**
Why is it important?
- Reveals True Motivation: Features are visible. Motivation is hidden. JTBD surfaces motivation. Why do users use your competitor? What job are they getting done?
- Uncovers Unmet Needs: Most user requests are feature requests. JTBD ignores feature requests and asks “what outcome does the user want?” Unmet needs emerge.
- Guides Product Roadmap: When you understand the job, roadmap priorities clarify. Features that accelerate the job rank higher than features that don’t.
- Differentiates Products: Competitors offer similar features. JTBD reveals that users care about the outcome, not the feature. A product that delivers the outcome faster wins.
The JTBD Interview
Conducting a JTBD interview requires specific questions:
- Trigger — “Tell me about the last time you [encountered situation]. What prompted you?”
- Situation — “Walk me through what you were trying to accomplish. What was the context?”
- Obstacles — “What got in your way? What was hard?”
- Current Solution — “How did you solve it? What did you use?”
- Satisfaction — “Looking back, are you happy with how you solved it? What would make it better?”
- Alternatives Considered — “What else did you consider? Why didn’t you choose that?”
The interview follows a narrative. Let the user tell their story. Don’t interrupt. The job emerges from the story.
Competing Jobs
Users don’t choose your product in a vacuum. They compare it to alternatives:
- Using a competitor
- Using a manual workaround
- Doing nothing (status quo)
JTBD asks: “Why did the user switch to your product? What job were they not getting done with the status quo?”
Mentor Tips
- First tip: JTBD interviews are conversational, not surveys. You need to hear the story. Why did they use it? What led to this moment? A survey asking “what job are you trying to do?” won’t work. Let them tell the story.
- Focus on specific occasions, not general behavior. “Tell me about the last time…” not “How do you typically…?” Recent specific events are more accurate than generalized habits.
- Listen for disappointment. When users describe switching to your competitor, listen for the disappointment. What wasn’t working? That’s the job they were trying to get done.
- Separate wants from needs. Users say “I want better UI.” That’s a want. The underlying need is “I want to accomplish my task faster.” Design for needs, not wants.
Resources and Tools
- Books: “Competing Against Luck” by Clayton Christensen, “Jobs to Be Done” by Anthony Ulwick
- Tools: Miro for mapping jobs, interview recording with transcription services, Notion for documentation
- Articles: JTBD framework on Clayton Christensen’s site, interviews on UX Collective