The research framework that makes personas look shallow
Jobs-to-be-Done is a framework for understanding why people choose a product — framed around the underlying goal they're trying to accomplish, not the features they interact with. It shifts the question from 'what does this user do?' to 'what are they trying to get done?'
Where It Comes From
The framework was developed by Clayton Christensen, the Harvard Business School professor who also gave us disruption theory. His famous milkshake story captures it well: a fast food chain couldn't figure out why people bought milkshakes in the morning. Demographics told them nothing useful. When they watched customers and asked better questions, they found out people were hiring the milkshake for a commute — they needed something to keep one hand busy and stave off hunger until lunch. That single insight restructured the entire product decision.
Since then, teams at companies like Intercom, Basecamp, and Spotify have built their product strategy around JTBD precisely because it cuts through the noise that personas generate.
The Core Idea: Hiring and Firing Products
JTBD proposes that people don't buy products — they hire them to do a specific job in their life. And when a better option comes along, they fire the old one.
This reframe changes everything about how you approach research. Instead of asking 'who is this user?', you ask:
- What situation were they in when they decided to look for a solution?
- What were they trying to accomplish?
- What had they tried before, and why did it fall short?
- What would make them switch away from what they're using now?
For B2B SaaS teams, this often surfaces motivations that were invisible in persona work — like the fact that a VP of Product isn't just buying a design tool, they're hiring it to reduce the friction in their design-to-dev handoff process and justify headcount decisions to their CEO.
Functional, Emotional, and Social Jobs
Not all jobs are task-oriented. Christensen identified three layers:
- Functional job — the practical thing the person is trying to do ("review designs without needing access to Figma")
- Emotional job — how they want to feel while doing it ("confident I'm not missing something important before we build")
- Social job — how they want to be seen by others ("looking like a structured, process-driven leader to my engineering team")
Most product teams optimise for functional jobs and completely miss the emotional and social layers. Those layers, though, are often what determines whether someone recommends your product or quietly churns after six months.
JTBD vs Personas
Personas group users by who they are. JTBD groups them by what they're trying to do. Neither is wrong — but they answer different questions.
Personas are useful for communication and alignment: they give stakeholders a human to think about. They're weak for product decisions because two people with identical demographics can have completely different jobs to be done.
JTBD is better suited to informing feature prioritisation, messaging strategy, and {{LINK:onboarding-ux}} decisions. It tells you why someone showed up, not just who showed up. If your personas are gathering dust because they feel too vague to act on, JTBD is usually the better fit for the specific research questions product teams actually face.
The strongest teams combine both: personas for stakeholder alignment, JTBD for product and design decisions.
How to Use It in Practice
You don't need a full research programme to start applying JTBD. The fastest way in is through switch interviews — conversations with people who recently switched to your product, switched away, or were actively considering both and chose one.
The key questions are structured around the timeline of the decision:
- What prompted the search? What was the first moment you thought 'I need to solve this'?
- What had you already tried? Why wasn't that working?
- What made you decide to act now, not three months ago?
- What almost stopped you from switching?
Six to eight of these conversations will surface patterns. Those patterns are your jobs. From there, you can map your current {{LINK:information-architecture}}, feature set, and onboarding against those jobs and immediately see where the gaps are.
Our {{INTERNAL:/services/ux-research}} work often starts here — especially for teams that feel their research isn't connecting to product decisions.
Key Takeaway
JTBD doesn't replace other research methods — it anchors them. Once you know the job a user is hiring your product to do, every other design decision gets a filter. Does this feature serve the job? Does the onboarding get them to the job faster? Does the empty state make it obvious what job this product can do for them?
For teams preparing a major release or trying to understand why activation is stalling, it's often the fastest way to stop guessing and start designing for the right outcomes.
Related: {{LINK:cognitive-load}}, {{LINK:onboarding-ux}}, {{LINK:heuristic-evaluation}}