What Is Jobs to Be Done?
Jobs to Be Done (JTBD) is a framework for understanding why customers really buy. It reframes competition in a way that reveals opportunities hidden from conventional analysis.
Key Takeaways
- JTBD argues that customers 'hire' products to do a specific job in their lives or work.
- Understanding the job reveals competitors you would never see in a traditional category analysis.
- The framework is most powerful for product development and positioning decisions.
The core idea
Clayton Christensen, who developed the framework, used the example of a fast food milkshake. Research showed that a large share of milkshakes were sold in the morning to commuters. The job being done was not 'satisfy a sweet craving' — it was 'give me something to consume slowly during a boring commute that keeps me full until lunch.' That insight revealed that the milkshake's real competitors were bananas and granola bars, not other desserts. Defining the job changes who you're competing against.
Functional, emotional, and social jobs
Every job has three dimensions. The functional job is the practical task being accomplished — 'manage my invoicing'. The emotional job is how the customer wants to feel — 'feel in control of my finances'. The social job is how they want to be perceived — 'look professional to my clients'. Products that address all three dimensions build much stronger loyalty than those addressing the functional job alone. Competitors who only solve the functional job are more easily displaced.
Applying JTBD to competitive intelligence
Map the job your most loyal customers are hiring you to do — in their own words, gathered through interviews. Then ask: what else could they hire to do this job? This surfaces non-obvious competitors. A project management tool might discover its real competition is email, not other project management tools. That insight changes everything about how you position, what features you prioritise, and what objections you pre-empt in sales conversations.
JTBD in product development
When considering a new feature or product, define the job it addresses before building. A feature that solves a job customers are actively struggling with will be adopted; a feature that solves a job they do not recognise having will be ignored. Validate the job through interviews that focus on the struggle — 'Tell me about the last time you tried to do X' — rather than feature preference questions, which produce unreliable data.