Jobs to Be Done: The Framework Every PM Needs to Know
Clayton Christensen's Jobs to Be Done framework changes how product managers think about users, competition, and what to build. Here's how it works, why it matters in PM interviews, and how to use it in practice.
By The Cala Voice Team ·Most product decisions start from the wrong place. Teams build personas, run surveys, track usage data, and still ship things people don't use. The frameworks are sound. The execution is disciplined. The product misses.
Clayton Christensen spent decades studying why this happens. His diagnosis, developed with Taddy Hall and published in Competing Against Luck (2016), is precise:
There is a simple, but powerful, insight at the core of our theory: customers don't buy products or services; they pull them into their lives to make progress.
Competing Against Luck, Clayton Christensen
The operative word is progress. Users aren't evaluating features against a checklist. They're trying to move forward in a specific situation, and they'll use whatever gets them there. Understanding that situation, at the right level of detail, is what Jobs to Be Done is actually about.
The Hire and Fire Metaphor
Christensen describes the relationship between a customer and a product in terms of employment:
When we buy a product, we essentially 'hire' something to get a job done. If it does the job well, when we are confronted with the same job, we hire that same product again. And if the product does a crummy job, we 'fire' it and look around for something else we might hire to solve the problem.
Competing Against Luck, Clayton Christensen
The metaphor is deliberate and exact. Hiring implies a context: you hire something for a specific role, in a specific situation, to accomplish something specific. Two people who look identical demographically — same age, same city, same income — might hire the same product to do completely different jobs. Or they might hire completely different products to do the same job.
This is why demographic segmentation so often fails to predict behavior. Knowing who buys your product tells you nothing about why. And without the why, you're building in the dark.
If you do not know how to ask the right question, you discover nothing. After decades of watching great companies fail over and over again, I've come to the conclusion that there is, indeed, a better question to ask: What job did you hire that product to do?
Competing Against Luck, Clayton Christensen
What makes this reframe powerful is what it implies about the unit of analysis. A job doesn't exist in the abstract. It arises in a specific moment, in a specific situation, when someone encounters a gap between where they are and where they want to be. Christensen calls this the "struggling moment." It's not a persona attribute or a segment characteristic. It's a circumstance. And two people with nothing in common can share the same struggling moment, which means they're in the same market whether or not any product team has ever recognized them as such.
The Milkshake Story
The most useful illustration of JTBD in practice is one Christensen returns to throughout the book.
McDonald's wanted to increase milkshake sales. They gathered feedback from customers, improved the product on every dimension customers said they wanted, and saw no meaningful change. Then Christensen's team tried a different question:
I wonder what job arises in people's lives that causes them to come to this restaurant to 'hire' a milk shake?
Competing Against Luck, Clayton Christensen
They discovered that roughly 40% of milkshakes were sold before 9am. One-on-one interviews revealed the same pattern:
They all said they had a long boring drive to work. Each person needed something to help them stay engaged in life, and they needed to consume it with one hand on the wheel.
Competing Against Luck, Clayton Christensen
The milkshake was being hired to solve a commute problem, not a hunger problem. Its real competitors were bananas, bagels, and doing nothing. Later in the day, the same product was being hired for a completely different job:
Parents have had to say 'no' to their children about any number of things all week long... 'Of course, Spence, you can have a milk shake.'
Competing Against Luck, Clayton Christensen
Same product, two completely different jobs, two completely different improvement directions. The morning job needed a thicker milkshake that would last longer. The afternoon job needed a smaller, cheaper one that wouldn't make a parent feel guilty. No amount of "make it better in a general way" would have surfaced either.
The circumstance is fundamental to defining the job (and finding a solution for it), because the nature of the progress desired will always be strongly influenced by the circumstance.
Competing Against Luck, Clayton Christensen
McDonald's had all the data they needed. They were measuring the wrong thing. Satisfaction scores and stated preferences are downstream of the job. The moment you understand the job, the improvement direction becomes obvious. The moment you don't, you're optimizing blindly.
The Three Dimensions of Every Job
Every job a customer is trying to do has three distinct dimensions. Most products address only one of them, and most research methods only surface one of them.
Functional: the practical task. Track my action items. Get from A to B. Share a document with my team. These are the jobs that feature requests describe, that users can articulate clearly, and that competing products usually solve at roughly similar levels of adequacy.
Emotional: how the customer wants to feel while doing the functional job, and after. Not overwhelmed. In control. Competent. Legitimate. Confident that they didn't make a mistake. The emotional job is usually invisible in feature requests but is often the primary reason a user stays or leaves.
Social: how the customer wants to be perceived by others as a result of using or owning the product. Look organized to their manager. Signal technical sophistication to their peers. Appear to be running a real operation, not a hobby. Social jobs are rarely discussed openly but are frequently decisive.
The key to getting hired is to understand the narrative of the customer's life in such rich detail that you are able to design a solution that far exceeds anything the customer themselves could have found words to request. In hindsight, breakthrough insights might seem obvious, but they rarely are.
Competing Against Luck, Clayton Christensen
Consider personal finance software. Three products address an almost identical functional job: QuickBooks, Mint, and a spreadsheet. QuickBooks users are not managing more complex finances than Mint users. They are managing a different emotional and social job. QuickBooks signals legitimacy: "I run a real business, not a side project." Mint signals responsibility: "I'm an adult with a handle on my money." The spreadsheet user has often opted out of the emotional job entirely, or is actively avoiding it.
A product team analyzing the functional job will build features all three products already have. The differentiation opportunity is in the emotional and social dimensions. Those are the ones that determine whether a user feels like the product was made for them, and they're almost never captured in surveys.
The same pattern appears in B2B. A professional buying project management software has a functional job (track tasks and deadlines), an emotional job (feel in control and not overwhelmed), and a social job (look organized and reliable to the people who evaluate their performance). A product that solves only the functional job is a commodity. The differentiation lives in how the product makes the user feel when things go wrong, when a deadline slips, when they need to surface status under pressure. That's the emotional dimension. No feature request will surface it because users will say they want faster task creation when what they actually want is to stop feeling behind.
New products succeed not because of the features and functionality they offer but because of the experiences they enable.
Competing Against Luck, Clayton Christensen
Writing a Job Statement
Understanding JTBD conceptually is useful. Being able to write a precise job statement is where it becomes operational. A vague job is as useless as a vague persona because it doesn't constrain decisions. The purpose of a job statement is to rule out wrong solutions and rule in right ones.
A job statement has three components: a situation or context (when or while doing X), a motivation or goal (I want to Y), and an expected outcome (so I can Z).
Weak:
Users want to communicate with their team faster.
Faster is not a job. It's a feature preference attached to an unspecified job. It doesn't tell you why they want speed, in what context, or what progress they're trying to make.
Stronger:
When I'm mid-project and something unexpected changes the timeline, I want to alert my stakeholders before they hear about it from someone else, so I can maintain their confidence and protect my credibility even when the news is bad.
Now the context is specific (mid-project, unexpected change), the motivation is clear (get ahead of bad news), and the outcome is defined (credibility preservation). This job statement tells you exactly what the product needs to do: make it fast and low-friction to send a clear, composed message under pressure. It implies that formatting, templates, and tone support matter. It implies that response latency matters. It tells you the competitor is not just Slack but also the impulse to say nothing and hope the situation resolves itself.
A job statement is a hypothesis, not a finding. You write it after research, not before. You revise it as you learn. The test of a good statement is simple: if two people working from it independently would make the same product decisions, it's specific enough.
Why Features Miss the Point
The problem with feature-driven roadmaps is not that the features are wrong. It's that they're addressing the functional dimension while the competitive differentiation happens somewhere else entirely.
Most product research is optimized to surface functional jobs. Surveys ask what features are missing. Support tickets describe what broke. Usage analytics show which flows are being completed. All of that is real data about real friction. But it only tells you what users can articulate, which is almost always the functional layer.
The emotional and social dimensions of a job are not hidden from users. They're just invisible to standard research methods. Ask someone why they switched from one tool to another and they'll tell you about the feature that was missing. Ask them to describe a moment where they felt the product had let them down, and something different emerges. The moment where the export failed in front of a client. The moment the reporting looked unprofessional in a board deck. Those are the emotional and social jobs revealing themselves.
This is why breakthrough product insights feel obvious in retrospect but were invisible to the team working on the problem:
The key to getting hired is to understand the narrative of the customer's life in such rich detail that you are able to design a solution that far exceeds anything the customer themselves could have found words to request.
Competing Against Luck, Clayton Christensen
The user who tells you they want a faster search function is not lying. They do want faster search. But their underlying job might be "stop looking incompetent when I can't find things quickly in front of my team," and that job has a different solution entirely. One builds an algorithm. The other redesigns what the search experience looks and feels like under time pressure.
The Four Forces of Progress
Understanding the job explains what a customer wants. It doesn't explain whether they'll actually change their behavior to get it. That requires a different model.
Bob Moesta, who worked directly with Christensen on JTBD, developed the Four Forces framework to explain adoption behavior. The four forces pull in two directions.
Push and Pull drive the customer toward change. Push is the dissatisfaction with the current situation: something about what they're doing now is wrong enough, frustrating enough, or costly enough that they begin considering alternatives. Pull is the attraction toward a new solution: the promise that this will solve what the current solution can't, and that the outcome will be meaningfully better.
Anxiety and Habit pull the customer toward staying. Anxiety is the fear of the unknown: what if the new solution doesn't work, what if the learning curve is steep, what if switching breaks something. Habit is the pull of the familiar: not comfort exactly, but the cost of changing a behavior that has become automatic. The incumbent doesn't need to be good to be sticky. It just needs to be known.
For adoption to happen, push and pull must outweigh anxiety and habit. This means that even a product with a compelling value proposition can fail if anxiety and habit are strong enough. The product is not competing against inferior software. It's competing against the cost of change itself.
This matters practically because most activation and retention problems are diagnosed as pull problems when they're actually anxiety or habit problems. If users try the product and don't return, the assumption is usually that the value proposition didn't land. But it's equally possible that the onboarding created enough uncertainty that the user decided to go back to what they knew. That's an anxiety problem, and it has a different solution than improving the feature set.
The Four Forces also explain why launching a better product is not sufficient. If the push in the current situation is low, meaning users aren't frustrated enough to consider switching, even a strong pull won't generate adoption. This is why many products that solve real problems fail to grow: the target users aren't struggling enough yet to bother changing. The implication for PMs is that sometimes the job is to increase push, not to increase pull. Making the cost of the current situation visible, through benchmarks, comparisons, or quantified estimates of what users are losing, is product work.
The Competitor You Didn't Know You Had
One of the most practically useful implications of JTBD is what it reveals about competition.
When you define competition by product category, you ask "who else makes something like ours?" When you define it by job, you ask "what else could someone hire to do this job?" Those are different questions with very different answers.
People don't want to buy a quarter-inch drill. They want a quarter-inch hole.
Quote from Theodore Levitt, in Competing Against Luck, Clayton Christensen
The drill competes with any other way of making a hole, including hiring a handyman, buying a pre-drilled bracket, or deciding the shelf doesn't need to go up at all. "Do nothing" is always in the competitive set, and in most categories it's the most common choice. A product that is better than the incumbent on every feature dimension can still lose to inertia.
Switching cost matters as much as the alternative:
Before a customer hires any new product, you have to understand what he'll need to fire in order to hire yours. Companies don't think about this enough. Something always needs to get fired.
Competing Against Luck, Clayton Christensen
If your product requires the user to fire a habit, that habit is in your competitive set. If it requires firing a workflow their whole team depends on, the team is in your competitive set. Users don't evaluate your product in isolation. They evaluate it against everything they'd have to stop doing to use it.
The job-defined competitive frame changes positioning too. If your users are hiring a project management tool to feel organized in front of their manager, the competition is not other project management tools. It's the combination of a personal to-do list, a weekly Slack update, and a shared spreadsheet, which already does that job well enough. Whether your product wins depends on whether it does the emotional and social job better in a way that's worth the switching cost.
You can only shape the experiences that are important to your customers when you understand who you are really competing with.
Competing Against Luck, Clayton Christensen
In PM interviews, this matters at the problem framing step. A candidate who defines competition by product category is analyzing the market. A candidate who defines competition by job is analyzing what actually determines adoption.
JTBD in PM Interviews
JTBD changes the quality of PM interview answers at the user definition step: the moment most candidates treat as a formality.
A weak user definition names a demographic: "I'd focus on young professionals who want to stay organized." A JTBD-framed user definition names a job in a circumstance: "I'd focus on someone who's just been promoted to manager for the first time and is running four times as many meetings as before. Their job is to stop things falling through the cracks without spending an hour each day maintaining a system. The emotional job is feeling competent in a role where they don't have a template yet."
The second version tells you exactly what to build. Everything downstream, the solution, the prioritization, the success metric, follows directly from it.
Example: "How would you improve a note-taking app for knowledge workers?"
Without JTBD:
I'd focus on knowledge workers who take a lot of notes. Their main pain point is finding things later. I'd improve search.
With JTBD:
The job isn't capturing information. It's acting on it. The specific user I'd focus on is someone who finishes five meetings a day and leaves each one with three things they meant to follow up on. By Friday, half of those are gone. The job they're hiring a note-taking app for isn't storage. It's accountability: they want the app to remember what they committed to so they don't have to.
The friction isn't search. It's that nothing in the app distinguishes a casual observation from a commitment. I'd redesign around that distinction: surface commitments automatically, resurface them at the right moment, and make it trivial to close the loop. Success metric: follow-up completion rate for items captured in meeting notes.
Example: "How would you define success for a new onboarding flow?"
Without JTBD:
I'd measure completion rate and time-to-first-value.
With JTBD:
The job being done in onboarding isn't completing a setup wizard. It's forming enough confidence to justify investing more time in the product. Users abandon not when onboarding is long but when they hit a moment of doubt: 'is this actually going to work for me?'
Success is the moment that doubt resolves. That's not a completion event, it's a behavioral shift. I'd measure the inflection point where a user stops exploring and starts working: not checking boxes but taking a goal-directed action that signals they've decided to stay. That moment is the leading indicator of retention far more reliably than flow completion.
In both examples, the JTBD framing produced a specific problem, a specific solution, and a specific metric. The feature framing produced a feature.
The Switching Interview
JTBD is most valuable when it's treated as a discovery discipline, not a slide deck framework.
The research method that consistently surfaces jobs is the switching interview: a structured retrospective conversation about the specific moment someone decided to change solutions. The questions are behavioral and timeline-based:
- "Take me back to the first moment you felt the old solution wasn't working. What were you trying to do that day?"
- "What happened next? Did you start looking for alternatives right away, or did you put it off?"
- "Was there a specific moment where you finally decided to actually try something new?"
- "Walk me through the first time you used it. What were you hoping would happen?"
- "Was there a moment where you almost went back to what you used before?"
You're building a timeline: first struggle → passive awareness of alternatives → active search → first use → continued use or abandonment. That timeline is where the job lives. The struggling moment is usually well before the switching decision, which means it often predates the period that standard research focuses on.
What you're listening for is not satisfaction levels but the narrative of change: what was wrong enough to generate push, what was compelling enough to generate pull, what created anxiety, and what made the habit of the old solution hard to break. That narrative contains more product insight than any survey because it captures the full set of forces that determined behavior, not just the feature preferences the user can articulate after the fact.
Innovation is less about producing something new and more about enabling something new and important for customers.
Competing Against Luck, Clayton Christensen
The hardest organizational application is keeping the job visible across the development cycle. A job statement discovered in discovery has a tendency to drift as teams move into delivery. Requirements get written, engineering constraints get introduced, scope gets negotiated, and by the time the feature ships it's solving a problem that looks like the original job but isn't quite.
If the customer job is not given a voice and a champion it will drown. Passive data needs active management.
Competing Against Luck, Clayton Christensen
The practical fix is simple: the job statement belongs in the spec, in the design review, and in the retrospective, not only in the discovery presentation. Teams that write "users want X" will build X and be surprised when retention doesn't follow. Teams that write "users are trying to make progress on Y in circumstance Z, and X is currently getting in the way" have a shared language for every tradeoff decision that comes after.
The Mistakes That Kill Good Research
The most common failure mode when teams apply JTBD is substituting data analysis for job discovery.
None of that data, however, actually tells you why customers make the choices that they do.
Competing Against Luck, Clayton Christensen
Usage data tells you what happened. It doesn't tell you why, what the user was trying to do before they opened your product, or what they would have done if your product hadn't existed. Pattern-matching on behavioral data produces incrementalism: you optimize the things that are already working and miss the jobs that are going unserved entirely.
The pull toward data is real and understandable:
Managers feel an understandable sense of reassurance when they shift their attention from the hazy contours of a story of struggle to the crisp precision of a spreadsheet.
Competing Against Luck, Clayton Christensen
But the precision is an illusion when you're measuring the wrong thing:
Data has an annoying way of conforming itself to support whatever point of view we want it to support.
Competing Against Luck, Clayton Christensen
There's a second failure mode that's less discussed: applying JTBD at the wrong level of abstraction. A job statement that's too broad, "users want to be more productive", is useless because it's true of nearly every product ever built. It doesn't rule out any solutions. A statement that's too narrow ("users want to resize the sidebar") is a feature request wearing a job statement's clothes. It doesn't reveal the job; it just redescribes a functional complaint.
The right level of abstraction produces a job with a meaningful competitive set: other ways a user could make the same progress. If the competitive set is obviously just your direct competitors, the statement is too narrow. If it encompasses all of human productivity software, it's too broad. The goal is the level where the job is specific enough to make decisions from but broad enough that multiple solutions could credibly address it.
JTBD requires sitting with ambiguity long enough to understand a human situation. That takes interviews, observation, and the discipline to ask what someone is trying to accomplish rather than whether they liked the product they used. It's slower than pulling a dashboard. It produces the insights that dashboards can't, and it does so in the form that actually drives product decisions: a situation, a motivation, and a desired outcome, precise enough to disagree about.
The Question That Changes Everything
The Jobs to Be Done framework doesn't require a methodology overhaul or a new discovery process. It requires a different question at the beginning of every product decision: not "who is this user?" but "what are they trying to get done, in what circumstance, and what's getting in their way?"
Ask that question across the functional, emotional, and social dimensions. Understand the forces pushing users toward change and the anxieties and habits pulling them back. Write a job statement specific enough to rule in right solutions and rule out wrong ones. Keep that statement visible across the entire development cycle, from brief to retrospective.
That question, asked honestly and followed wherever it leads, is what separates products that get hired from products that get ignored.
What to Read and Do Next
For how JTBD applies specifically to product design interview questions, see the Product Design Interview Guide. For a full overview of interview frameworks including how JTBD fits alongside STAR, CIRCLES, and the estimation and strategy structures, see PM Interview Frameworks.
Cala Voice covers this framework in its audio brief library, alongside PM book summaries, interview guides, and framework deep dives. For interview practice, the voice coach lets you work on the user definition step, the moment where JTBD thinking either shows up in your answer or doesn't, with immediate feedback on whether your analysis is specific enough to drive a real solution.