# Jobs to Be Done Framework

> Understanding what users are trying to accomplish (not what feature they want) reveals design opportunities others miss.

*Tags: ux, research, mid-level*

---



> [!info] Quick Definition
> 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:

1. **Trigger** — "Tell me about the last time you [encountered situation]. What prompted you?"
2. **Situation** — "Walk me through what you were trying to accomplish. What was the context?"
3. **Obstacles** — "What got in your way? What was hard?"
4. **Current Solution** — "How did you solve it? What did you use?"
5. **Satisfaction** — "Looking back, are you happy with how you solved it? What would make it better?"
6. **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]]

---

Source: https://www.fernandoux.com/en/wiki/research/jtbd/