Jobs to Be Done
A framework describing what people are trying to accomplish and the circumstances driving them, rather than who they are.
Jobs to Be Done shifts the unit of analysis from the person to the situation. Instead of “marketing managers aged 30–45”, the question becomes “when a campaign underperforms mid-flight and I have to justify the spend by Friday, I need to see which channel failed”. Demographics predict poorly; circumstances predict well, because the same person hires different products in different situations.
It also reframes competition. If the job is “show my board that last quarter's spend worked”, the competitor is not another analytics tool — it is a spreadsheet, an agency's PDF, or doing nothing. That is usually a more honest competitive set than the one in the pitch deck, and it changes what “good enough” means.
Jobs and personas coexist
A persona describes who, a job describes what and when. Personas help with tone, access and channel; jobs help with what to build. Teams that throw out personas for JTBD usually end up reinventing a weaker version of them.
In practice
An expense tool positioned itself against other expense tools. JTBD interviews found the real job was “close the month without chasing people”, and the thing it was displacing was a finance manager sending reminder messages on Friday afternoons. Repositioning around chasing — and shipping automated nudges — moved the product from a features comparison into a category of one.
Where teams get it wrong
- Writing jobs as feature requests, which smuggles the solution into the problem statement.
- Dropping the circumstance. “I want to track expenses” is not a job; the trigger and the deadline are what make it one.
- Treating JTBD as a replacement for personas rather than an answer to a different question.
- Defining the job so broadly that every product in the market satisfies it.
- Deriving jobs in a workshop instead of from interviews about actual switching moments.
( Learn more )
Related terms
All terms- User PersonaA research-based profile of a user type — their goals, context, constraints and behaviour — used to keep design decisions grounded in a real audience.
- User InterviewA structured conversation with someone who uses or might use a product, aimed at understanding their situation rather than collecting opinions.
- Product-Market FitThe point at which a product satisfies a real market demand strongly enough that usage and revenue grow without being pushed.
- User ResearchThe systematic study of users' goals, behaviour and context — through interviews, observation and analysis — to inform what gets designed and built.