Jobs to Be Done (JTBD) Framework

By Dnyaneshwar N • 5 min read • Clayton Christensen & Bob Moesta, 2003 (Harvard Business School)

Focuses on the functional, emotional, and social progress a user desires rather than superficial demographics. Uncovers true user motivations and unarticulated friction points.

Core Principle

Customers do not buy products or services; they "hire" them to make progress in a specific circumstance.

Focusing on Functional, Emotional, and Social Progress

Popularized by Clayton Christensen and Bob Moesta, the Jobs to Be Done (JTBD) framework argues that customers do not buy products; they "hire" them to make progress in specific circumstances.

A person does not buy a drill because they want a drill; they buy it because they want a quarter-inch hole in their wall. In digital product design, JTBD strips away superficial demographic data to uncover the core functional, emotional, and social motivations driving user behavior.

Using Job Stories ("When [situation], I want to [motivation], so that I can [expected outcome]") aligns engineering and design teams around meaningful user value rather than feature lists.

Reframing AI Interaction Around Underlying Jobs

Many current AI tools focus on prompting as a feature: "Use our AI to write complex prompts!" But prompt engineering is not a job anyone wants to hire a product for.

The user's actual job might be: "When I receive fifty customer support inquiries overnight, I want to prioritize the urgent billing issues immediately, so our team does not violate service level agreements."

Autonomous agents and generative UI succeed when they solve the core job directly: analyzing the inbox, tagging the invoices, and preparing draft responses for review without forcing the user to become a prompt engineer.

Frequently Asked Questions

Outcome-driven design with Jobs to Be Done:

What is the Jobs to Be Done framework? A methodology focusing on the underlying progress a user seeks to achieve in a particular situation, rather than demographic characteristics.
How does a Job Story differ from a User Story? User stories focus on user roles and features ("As a user, I want X"); Job stories focus on context, motivation, and desired outcome ("When X happens, I want Y so I can Z").
Why is JTBD vital for AI product strategy? It ensures AI features automate the user's actual progress goals rather than adding unnecessary conversational gimmicks.

When to Apply

User interview synthesis and customer journey mapping
Feature prioritization and roadmap planning
Value proposition design and SaaS product messaging
Churn analysis and competitor substitution research
Focus on user progress and outcomes instead of screens using How to Frame a UX Problem Before Designing.

Recommended Practices

Frame requirements as Job Stories: "When [situation], I want to [motivation], so I can [expected outcome]."
Analyze the emotional and social anxieties preventing users from adopting new tools.
Focus on the struggle and the catalyst that prompted the user to search for a new solution.
Replace static demographic profiles with situational struggle moments from User Personas: Beyond Static Deliverables.

Practices to Avoid

Do not rely solely on superficial demographics (e.g. "Male, 28-35, Tech Enthusiast").
Do not mistake product features for user jobs.
Do not assume users care about your software architecture; they care about their progress.

Diagnostic Checklist

Is every feature tied to a clear Job Story with situation, motivation, and expected outcome?
Have emotional anxieties and switching hurdles been addressed in the onboarding flow?
Does the user interface celebrate the user’s real-world progress rather than just app usage?
Identify the core progress users hire microlearning platforms to achieve in the Learniac Microlearning Case Study.