Jobs to be done (JTBD) is a framework for understanding why people adopt, use or abandon a product: they “hire” it to make progress in a specific situation, and they “fire” it when something else does that job better. The unit of analysis is the job, a stable goal with functional, emotional and social dimensions, rather than the user’s age, role or product features.
In UX design, JTBD shapes research questions, information architecture and feature priorities around the circumstances and desired outcomes that trigger use. It complements, and often challenges, demographic personas by asking what a person is trying to get done and what currently stands in the way.
How the jobs to be done framework works
The central claim of JTBD is that circumstance predicts behavior better than attributes. Two people of very different profiles may hire the same product for the same job, while one person may hire different products for different jobs during the same day. Research therefore focuses on the moment of struggle in which someone starts looking for a solution.
A job has several dimensions, each of which can be addressed by design.
| Dimension | Question it answers | Illustration |
|---|---|---|
| Functional job | What practical task must be completed | Split a shared bill fairly |
| Emotional job | How the person wants to feel | Avoid awkwardness with friends |
| Social job | How the person wants to be seen | Appear organized and generous |
| Related jobs | What else happens around the core job | Track who still owes money |
| Consumption jobs | What it takes to use the solution | Install, learn, pay, maintain |
Jobs are solution-agnostic and stable over time. People have needed to record music, move money and stay informed for decades, while the products hired for those jobs have changed repeatedly. Framing work around the job helps teams see non-obvious competitors, including spreadsheets, paper notes, phone calls or doing nothing at all.
Schools of practice within JTBD
JTBD is not one standardized method but a family of related approaches. They share the job concept and differ in what they treat as the main output: a demand story, a quantified outcome list or a design artifact for teams.
| Approach | Main focus | Typical output |
|---|---|---|
| Jobs as progress | Why people switch products | Switch timeline, forces of progress |
| Outcome-driven innovation | Measurable desired outcomes | Ranked outcome statements by opportunity |
| Job stories | Situational design requirements | Situation, motivation, expected outcome |
| Job mapping | Steps of executing a core job | Universal job map with eight stages |
The switch interview is the signature research technique of the progress school. Researchers reconstruct a recent purchase or adoption as a timeline from first thought to first use, probing for the push of the current situation, the pull of the new solution, the anxiety of change and the habit of the present. These four forces explain why people switch or stay.
Writing job statements and job stories
A well-formed job statement contains a verb, an object and a contextual clarifier, for example “organize household documents so they can be found during tax season”. It avoids product names, features and adjectives such as easy or fast, which belong to desired outcomes, not to the job itself.
A job story reframes a user story around circumstance. Instead of naming a role, it names a triggering situation, the motivation it creates and the expected outcome. This makes acceptance criteria more concrete, because the design must work in that exact situation, for instance on a phone, in a hurry, with one hand.
- Good statement: keep track of medication doses for an elderly parent across several caregivers.
- Weak statement: use a simple app to manage medication, because it names a solution and an adjective.
- Desired outcome: minimize the likelihood of a missed or duplicated dose, which can be measured and prioritized.
Jobs to be done compared with personas and user journeys
JTBD, personas and user journeys answer different questions and work best together. Personas describe who the users are, user journeys describe the sequence of their experience, and JTBD describes why they engage at all and what success means to them.
| Tool | Core question | Strength | Common weakness |
|---|---|---|---|
| Jobs to be done | What progress is the person seeking | Reveals motivation and competitors | Abstract without good interviews |
| Persona | Who is the user | Builds empathy, aligns teams | Drifts into demographic stereotypes |
| User journey | What happens over time | Exposes pain points across touchpoints | Assumes the current solution |
| User story | What must the system allow | Fits agile backlogs | Role-based, lacks context |
A practical combination is to anchor personas on jobs: each persona is defined by the jobs and circumstances it represents rather than by age or hobbies. User journeys then map how the person executes the job today, which reveals where the product can remove friction or skip steps.
Pitfalls when applying JTBD
The framework is easy to quote and hard to apply rigorously. Most failures come from defining jobs at the wrong level or skipping the qualitative research that gives them substance.
| Mistake | Symptom | Correction |
|---|---|---|
| Job too narrow | Job is really a feature request | Ask why until a stable goal appears |
| Job too broad | Job such as live a happy life | Bound it by situation and context |
| Solution in the job | Product name in the statement | Rewrite in solution-agnostic terms |
| Opinion instead of evidence | Jobs invented in workshops | Base jobs on interviews about real events |
| Ignoring emotional jobs | Feature parity, no preference | Design for confidence and reassurance |
Teams should also remember that JTBD explains demand and motivation, not usability. A product can address the right job and still fail through poor interaction design, so JTBD findings must still be validated with usability testing and behavioral data.
Understanding it simply
Jobs to be done is a way of looking at products by asking what people are really trying to achieve. Nobody wants a drill for its own sake. They want a hole in the wall, and even more, they want the shelf to hang straight.
When designers understand that underlying goal, they can build what actually helps. They also notice surprising competitors. A budgeting app, for example, competes not only with other apps but with a notebook, a spreadsheet and simply ignoring the problem.
Applied in practice
A team redesigning a time-tracking tool for freelancers runs twelve switch interviews with people who recently started or stopped using such a tool. The interviews show that the real job is not logging hours but getting paid accurately without awkward client conversations. Many people switched right after a client disputed an invoice.
The team reprioritizes the roadmap. Instead of adding more timer options, it builds a client-ready report that turns tracked time into a clear invoice breakdown in one step. In the following release, the share of active users who send at least one report rises substantially, and support requests about exporting data drop, confirming that the design now serves the job people hire it for.