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 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.