Most product failures aren’t failures of execution. They’re failures of understanding. Teams build something technically impressive, position it clearly, and then watch it underperform because they were solving a problem customers didn’t actually have, or solving the right problem in the wrong way.
The jobs to be done framework exists to fix that. Here’s how it works, and how to apply it at every stage of product development.
What is the jobs to be done framework?
Developed by the late Harvard Business School professor Clayton Christensen, the jobs to be done (JTBD) framework is built around a single, deceptively simple question: what job is your product hired to do?
The idea is that people don’t buy products for their own sake. They buy them to make progress in a specific situation. A customer doesn’t buy a project management tool because they want software. They buy it because they need their team to stop missing deadlines. The “job” is getting the team coordinated. The software is just the solution they hired to do it.
This shift in perspective changes how you think about product development, messaging, and even who your real competitors are.
The different types of jobs to be done
Customer needs are rarely one-dimensional. The framework breaks them down into layers, which is where much of its analytical power comes from.
- Main jobs: The primary problem a customer is trying to solve.
- Related jobs: Adjacent problems they want to solve at the same time.
- Functional aspects: The practical, rational requirements of the solution.
- Emotional aspects: How the customer wants to feel, and how they want to be seen.
That last category is worth dwelling on. Emotional job aspects split into two dimensions: the personal (how someone feels using your product) and the social (how they feel they’re perceived by others when using it). A car might get someone from A to B functionally, but it also signals something about who they are. Both dimensions influence the buying decision, often more than the functional ones.
The milkshake story: why JTBD changes how you see competition
Christensen illustrated the framework with a case study that has since become something of a classic in product circles. A fast-food chain wanted to increase milkshake sales. Standard market research had gone nowhere. So researchers tried a different approach: they spent a day at the restaurant simply observing who bought milkshakes and asking them why.
It turned out that 40% of milkshakes were sold early in the morning to commuters. They weren’t buying a milkshake because they were hungry. They were hiring it to make a long, boring drive more bearable, keep one hand occupied, and stave off hunger until mid-morning. The milkshake was competing not with other shakes, but with bananas, bagels, and coffee.
Once you understand the job, your real competitors become obvious. And they’re often not who you assumed.
The same logic applies to any product. If a customer stops using your tool in favour of a competitor’s, your product has been “fired” from its job. Understanding why it was fired, and what the replacement did differently, is one of the most useful inputs you can have for product iteration.
When to run a JTBD survey
One of the underrated strengths of JTBD research is its flexibility. It’s useful at almost every stage of product development, not just at the beginning.
- When prioritising your product roadmap and need to ground decisions in customer needs rather than internal opinions
- Before defining your value proposition or writing positioning copy
- When optimising homepage messaging and want to know what job visitors think you do
- When testing a long-held assumption about your unique selling points
- After a drop in retention, to understand what job your product stopped doing well
What good JTBD research looks like in practice
The goal of JTBD research is not to ask customers what features they want. It’s to understand the situation they were in when they came looking for a solution, the progress they were trying to make, and what made them choose (or keep choosing) your product.
Focus on the moment of purchase
The most revealing JTBD questions centre on the circumstances around a buying decision. What was happening in the customer’s life that made them start looking? What had they tried before? What made them switch? The narrative around the decision is often richer than any rating scale.
Look for the emotional and social layer
Functional needs are usually easier for customers to articulate. Push past them. Ask how using your product makes someone feel, and whether it changes how others see them. These answers often surface the real reasons for loyalty or churn.
Survey beyond your existing customers
Former customers and non-customers are particularly valuable. Former customers can tell you what job you failed to do. Non-customers reveal which jobs they’re solving with something else entirely, and what it would take for you to get hired.
From insight to action
JTBD research is only useful if it changes something. The most common applications are sharper product prioritisation (building things that serve real jobs rather than assumed ones), clearer positioning (describing your product in terms of the job it does rather than the features it has), and better competitive analysis (knowing who you’re actually competing with for the same job).
The teams that use this framework most effectively treat it as an ongoing habit rather than a one-time exercise. Customer jobs evolve. New competitors emerge to do the same job differently. The question of what your product is hired to do deserves a fresh answer every year, at minimum.
