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.