Jobs to Be Done (JTBD)
What is Jobs-To-Be-Done?
Jobs-To-Be-Done (JTBD) is a framework that focuses on why people "hire" (use or buy) a product: to get a specific job done in a given situation. It emphasises the job and context over demographics or feature lists.
Use it when: you want to understand what users are trying to accomplish and why, so you can design for the job instead of for assumed preferences.
Copy/paste template
Job story: When [situation/context], I want to [motivation/goal], so I can [expected outcome].
Example: "When I'm rushing to work, I want to have breakfast without stopping, so I can save time and still feel full until lunch."
Why JTBD matters
- Shifts the focus from "who" to "what job" and "when", which often reveals better opportunities.
- Reduces feature bloat by tying design to job completion, not wish lists.
- Surfaces real competition (other ways people get the same job done).
- Keeps you solution-agnostic so you don't lock onto one idea too early.
What a good job formulation includes
Checklist
- Starts with when (situation), not "as a [persona]".
- Describes the goal (what they want to do), not the solution.
- Ends with outcome (why it matters to them).
- Could apply to a functional, emotional, or social dimension of the job.
Common formats
- Job story: When [situation], I want to [motivation], so I can [outcome]. Best for product and design work.
- Forces of progress: Push (frustration with current), Pull (attraction to new), Anxiety (fear of change), Habit (comfort with status quo). Use when analysing switching behaviour.
Examples
Example (the realistic one)
Traditional: "Users want a faster way to edit photos."
JTBD: "When I've taken a photo I want to share, I want to crop and filter it quickly, so I can post without opening a desktop app." The job is "get this image share-ready in this moment"; the solution (mobile editor, presets, etc.) stays open.
Common pitfalls
- Describing the solution instead of the job: "I want a dashboard" is not a job. → Do this instead: ask what they're trying to accomplish and in what situation.
- Staying only functional: jobs have emotional and social dimensions. → Do this instead: add "so I can feel…" or "so I'm seen as…" where it's genuine.
- Confusing with user stories: job stories start with context; user stories start with persona. → Do this instead: use job stories for discovery and strategy; user stories for delivery.
JTBD vs. related concepts
| JTBD / Job Story | Problem Statement | Persona | |
|---|---|---|---|
| Focus | The job & context | The friction & impact | Who the user is |
| Format | When / I want to / so I can | For [user] who… causes [pain]… | Name, role, goals, behaviours |
| Primary use | Discovery & strategy | Team alignment | Communication & empathy |
| Solution stance | Solution-agnostic | Solution-agnostic | Solution-agnostic |
| Starting question | What are they trying to get done? | What's broken, for whom, and why? | Who are we designing for? |
| When to use | Early discovery; understand the job before defining the problem | Before writing stories or specs | Throughout; keeps team user-centred |
All three complement each other. Start with JTBD to understand the job, move to a problem statement to align on what's broken, and use personas for team communication throughout.
- JTBD vs personas: personas describe who; JTBD describes the situation and job. Use JTBD to prioritise what to build; personas can still help with communication and empathy.
- JTBD vs user stories: job story = When / I want to / so I can. User story = As a / I want / so that. JTBD is context-first; user stories are identity-first and better for backlog items.
- JTBD vs value proposition: JTBD clarifies the job; the value proposition is the promise you make to help them get that job done.
Related terms
- Problem statement - often built from a clear understanding of the job and its friction.
- User stories - delivery format; keep them grounded in job-based insight.
- Persona - who you're designing for; JTBD adds the "when" and "why".
- User research - switch interviews and job mapping are core JTBD research methods.
- Value proposition - the promise that fits the job.
- Continuous discovery - ongoing learning about jobs and context.
- Feature prioritisation - prioritise by impact on job completion.
Next step
Use the job story template in your next discovery session, then read Problem statement to turn the job and its friction into a statement the team can align on.
If the job is clear but the team still cannot agree what to commit to, use the free UI Decision Brief to capture the decision, rationale, trade-offs, and next checkpoint in one place.
