A Different Way of Looking at Users
Most user research starts from the user as a person: their demographics, their needs, their preferences. Jobs-to-be-Done (JTBD) starts from a different angle. It asks not who is this user but what is this user trying to get done , and treats products as things users "hire" to accomplish specific jobs. The shift in framing seems small. The implications are profound.
Clayton Christensen popularised JTBD in the 1990s and 2000s, drawing on earlier work by Theodore Levitt ("people don't want a quarter-inch drill, they want a quarter-inch hole") and developing it through case studies and consulting work. Bob Moesta, Tony Ulwick, and others extended it in different directions. Today JTBD is widely cited and frequently misapplied. Many teams use the vocabulary without the underlying discipline, producing user-story-shaped artefacts that miss what made the framework valuable in the first place.
This article describes JTBD as we understand it after using it across many products: what it actually argues, how to apply it rigorously, where it adds value, and where it is overrated. We use it constantly, but we use it as one tool among several, not as a comprehensive philosophy.
The Milkshake Story
The most famous JTBD example, popularised by Christensen, is the milkshake study. A fast-food chain wanted to sell more milkshakes. Standard market research suggested making them thicker, sweeter, or chunkier. None worked. A different team approached the problem by asking when and why people bought milkshakes.
The data revealed that a surprising portion of milkshakes were bought before nine in the morning, by commuters on their way to work. Why? Because they had a long, boring drive, they wanted something they could consume one-handed in traffic, something that would last the whole commute, and something that would tide them over until lunch. The milkshake competed with bagels (too messy), bananas (gone too quickly), donuts (too sticky), and coffee (lasted but did not satisfy hunger). The job being done was not have a tasty drink ; it was make my morning commute more bearable while keeping me full .
Once the team understood the actual job, they made the milkshake thicker (lasted longer), added small chunks (more interesting to suck through a straw), and put the dispensers on the customer side of the counter (faster purchase for hurried commuters). Sales increased significantly. The competitive set in the team's head changed from other milkshakes to bagels and bananas. The framing changed everything.
The Three Types of Jobs
Christensen and others distinguish three kinds of job, often happening simultaneously. A useful product analysis attends to all three.
1. Functional Jobs
The practical task the product helps complete. Get to work with caffeine in my system. Track my expenses for tax purposes. Communicate with my team about today's priorities. Functional jobs are the most visible and the easiest to identify. Most product work treats them as the entire picture.
2. Emotional Jobs
How the user wants to feel during or after the job. Feel competent in front of my boss. Feel less anxious about the deadline. Feel like a thoughtful person who keeps in touch. Emotional jobs often shape adoption more than functional ones, but they are rarely articulated by users and rarely surfaced by standard research. The product that wins is often the one that addresses an emotional job that competitors missed.
3. Social Jobs
How the user wants to be perceived by others. Look like a responsible parent. Be seen as a forward-thinking team. Appear successful at the dinner party. Social jobs explain why users sometimes pay much more than the functional value would warrant, why brands matter, and why some products succeed despite functional inferiority to alternatives.
A complete JTBD analysis examines all three layers. A product designed only for the functional job is competing on a narrow axis where many alternatives exist. A product that also handles the emotional and social jobs is harder to displace, because the customer relationship runs deeper than functionality.
Job Stories vs. User Stories
Traditional user stories follow the format As a [type of user], I want [some action], so that [some benefit]. JTBD advocates often replace these with job stories: When [situation], I want to [motivation], so I can [expected outcome]. The difference looks small. It is not.
Aspect User Story Job Story
Anchor Type of user (often a persona) Specific situation or trigger Implication Same user has same need always Same user has different needs in
different situations
Risk Optimises for assumed user attributes Optimises for the actual moment of
need
Best for Familiar workflows, well-understood Discovering novel use cases, novel
users motivations
Both formats have their place. User stories are concise and easy to scan; they work well when the team has solid user understanding and is communicating about a known segment. Job stories force attention to the situation that triggers the need, which can reveal use cases the user-story framing misses.
An example of the difference. User story: As a project manager, I want to assign tasks to my team members, so that everyone knows their responsibilities. Job story: When I notice the team is unclear about who is doing what, I want to quickly communicate ownership, so that the work moves forward without me having to chase people. The job story surfaces the trigger ("notice the team is unclear") and the deeper goal ("move forward without chasing"), both of which suggest design directions that the user story might miss.
How to Identify Real Jobs
Identifying the real job a user is hiring your product to do is harder than it looks. The first answer is rarely the deepest one, and the surface answer is often misleading. Several techniques help.
The Switch Interview
The most useful single technique we have used. Talk to a user who recently started using your product, and ask about the moment they decided to switch. Specifically: what was happening before? What triggered them to look for a solution? What alternatives did they consider? What ultimately led them to choose your product? The narrative of the switch reveals the actual job, the actual competition, and the actual decision criteria, often in ways no other research method captures.
The Five Whys
When a user describes a need, ask why. Then ask why about the answer. Repeat until you reach a layer that is fundamental rather than instrumental. I need to schedule meetings. Why? So I can coordinate with my team. Why? So we stay aligned on priorities. Why? So we don't waste time working on the wrong things. Why? So I can deliver results without being seen as the bottleneck. The fifth answer is often the actual job.
The Anomaly Hunt
Look at usage data for unusual patterns. Users using the product at unexpected times, in unexpected ways, for unexpected lengths of time. These anomalies often reveal jobs the team did not design for. The milkshake example is exactly this: anomalous morning purchases revealed an unanticipated job.
The Substitute Mapping
Ask users what they would do if your product disappeared. The substitutes they would use reveal the true competitive set, which reveals the real job. If users would substitute your scheduling tool with text messages, the job is communication, not calendar management. If they would substitute it with a spreadsheet, the job is record-keeping.
Common Misuses of JTBD
Misuse One: JTBD as User Story Renaming
Some teams adopt the job story format without changing how they think. They write the same user stories with a different template, missing the deeper shift. The format is a tool to support the thinking, not a substitute for it. If your job stories all reduce to when I am at work, I want to do my work, so I can complete my work , you are using the format without the discipline.
Misuse Two: JTBD as a Replacement for All Other Research
JTBD is excellent for understanding why users hire a product and what jobs they are using it for. It is less useful for understanding usability problems, evaluating designs, or measuring satisfaction. Some teams treat JTBD as the only research methodology, missing the other layers of insight that other methods provide.
Misuse Three: Inventing Jobs Without Research
Many teams construct jobs from imagination rather than from user contact. The jobs sound plausible. They were not actually discovered. Users would not describe them. The product is designed for jobs nobody is hiring it to do, which produces the same pattern of poor adoption as any other imagination-based product work.
Misuse Four: Treating Jobs as Eternal
Christensen argued that jobs are stable while products change. This is mostly true but not always. New technology can create new jobs (the job of find a stranger's contact details online did not exist in 1990). Cultural shifts can change what jobs people care about. Treating the job map as a fixed input rather than something to revisit periodically can leave products serving jobs that no longer exist.
Misuse Five: Single-Job Tunnel Vision
Users typically hire a product for multiple jobs simultaneously, not just one. Designing exclusively around one identified job can produce a product that is excellent at one thing and useless for the adjacent jobs that originally drove the user to consider it. The job map should include the secondary and tertiary jobs, not just the primary.
When JTBD Excels and When It Falls Short
Where It Excels
- Identifying the real competition. JTBD reveals that your competitor may not be another product in your category but a workaround, a manual process, or doing nothing. This changes how you position and price.
- Surfacing emotional and social motivations. Most research methods miss these. JTBD's framing forces attention to them.
- Understanding switching behaviour. The switch interview is one of the most powerful research techniques available, and it is native to JTBD thinking.
- Disrupting category boundaries. JTBD often reveals that the customer's mental model crosses category lines that product teams treat as fixed. This is where blue-ocean opportunities tend to live.
- Evaluating new product opportunities. Asking what job would this hire-able for is a useful filter on new product ideas.
Where It Falls Short
- Detailed design decisions. JTBD does not tell you whether a button should be on the left or the right. Other methods are needed for that level of detail.
- Measuring satisfaction or quality. JTBD describes what users hire products for, not how well they are doing it. Other measurements are needed.
- Quantifying market size. JTBD describes jobs qualitatively but does not quantify how many people have each job how often. Other research is needed for sizing.
- Specifying internal capabilities. JTBD focuses on the user side. Internal capabilities (engineering complexity, operational support, regulatory constraints) need to be thought about separately.
- Edge cases and error handling. JTBD describes the main job; the failure modes and edge cases need their own attention.
Applying JTBD to Your Current Product
If you have not done JTBD analysis on your current product, here is a practical sequence that has worked for us. It takes about two weeks of part-time effort and produces durable insight.
- 1. Identify ten to fifteen recent users (within the last two to three months) who started using the product. They should be a mix of segments and use cases.
- 2. Run switch interviews with each. Focus on the moment of switching: what triggered them, what alternatives they considered, what made them choose your product, what they expected.
- 3. Across the interviews, identify patterns in the triggers (situations that prompted the switch), the alternatives (products and workarounds considered), and the deciding factors (why your product won).
- 4. Articulate the primary jobs your product is being hired for. Usually two to four major jobs emerge, with several secondary jobs.
- 5. Map each job across the three layers (functional, emotional, social). Note which layers your product addresses well and which it neglects.
- 6. Compare the jobs your product is being hired for with the jobs your team thought it was designed for. Gaps reveal either positioning errors or strategic opportunities.
- 7. Use the analysis to inform the next quarter's roadmap. Features that strengthen the most-hired jobs deserve priority. Features that serve hypothetical jobs nobody actually hires for can probably be cut.
A Worked Example
Consider a hypothetical team building a habit-tracking app. The team's assumed job is build healthy habits . After running JTBD analysis on twelve recent users, the team finds:
- Three users hired the app for the assumed job (build habits). They are highly engaged but represent a minority.
- Five users hired it as a daily journal: a way to record what happened today, with habits as a structured prompt.
- Two users hired it for accountability with a partner: their spouse or coach checks the streak.
- Two users hired it for low-stakes self-soothing: the act of checking off a box produces a small dopamine hit they enjoy as a kind of micro-meditation.
The team's product was designed for the first job and largely neglects the others. The journaling users are using a workaround (writing in the comment field). The accountability users want sharing features that do not exist. The self-soothing users would benefit from satisfying interactions that the team has been removing in the name of "reducing friction."
The implications are direct. The team can either deepen its focus on the assumed job (and accept that it serves a smaller audience), or expand to serve the actual jobs (and reshape the product accordingly). Either is a legitimate strategic choice. But making the choice consciously, with knowledge of the actual jobs, is far better than continuing to serve only the assumed job by accident.
A Final Word
Jobs-to-be-Done is one of the most useful frameworks we have encountered, and like most useful frameworks, it is most valuable when used as a way of thinking rather than as a checklist. The shift from who is the user to what are they trying to get done opens up perspectives that other framings close off. The discipline of asking about switches, alternatives, and the three layers of jobs produces insight that compounds over time.
Use it. Apply it to your current product. Run the switch interviews. Map the jobs across the three layers. Compare actual jobs against assumed jobs. The gaps will surprise you, and the surprises are where the strategic opportunities live. Then keep using it as one tool among several, balanced with other research methods, with the humility that no single framework captures everything that matters about how users and products meet.
Key Takeaways
- Users hire products to do jobs in specific situations. The job, not the user demographics, is the durable unit of analysis.
- Jobs have three layers: functional (the task), emotional (how the user wants to feel), and social (how the user wants to be seen). All three matter; most products address only the first.
- Job stories anchor on situations and motivations, while user stories anchor on user types. Both are useful; the shift in framing reveals different things.
- The switch interview is the single most useful technique. Ask recent users what triggered them, what alternatives they considered, and what led them to choose your product.
- JTBD excels at identifying real competition, surfacing emotional and social drivers, and revealing strategic opportunities. It is less useful for detailed design or quantitative sizing.