jeremylongshore Jobs to Be Done Framework
Framework for discovering innovation based on a fundamental truth: customers don't buy products - they "hire" them to do a specific job in their lives.
Core Principle
Job to Be Done = the progress a customer wants to make in specific circumstances.
Key elements of the definition:
- Progress (not goal, not solution) - customer wants to move from current state to a better one
- Circumstances - context determines the job, not customer attributes (demographics are useless)
- Hiring/Firing - customer actively chooses a product for the "job"
Scoring
Goal: 10/10. When reviewing or creating product strategy or positioning, rate it 0-10 based on adherence to the principles below. A 10/10 means full alignment with all guidelines; lower scores indicate gaps to address. Always provide the current score and specific improvements needed to reach 10/10.
Three Dimensions of Every Job
Every job has three inseparable dimensions - omitting any means failure:
| Dimension | Question | Example (milkshake) |
|---|---|---|
| Functional | What does the customer need to do? | Occupy myself during boring commute |
| Emotional | How do they want to feel? | Have a small treat for myself |
| Social | How do they want to be perceived? | As a sensible parent (not buying donuts) |
Framework
1. The Job Statement
Core concept: A job statement captures the progress a customer seeks in a specific circumstance, expressed in a structured format that separates context, desired progress, and expected outcome.
Why it works: By forcing teams to articulate the job in the customer's language and circumstances, it prevents solution-first thinking and keeps innovation grounded in real human progress.
Key insights:
- The format is: "When [circumstances], I want to [progress], so I can [outcome]"
- Circumstances matter more than customer demographics - the same person has different jobs in different situations
- A well-written job statement never mentions your product or any specific solution
- Jobs are stable over time; solutions change but the underlying job persists
Product applications:
| Context | Application | Example |
|---|---|---|
| New product ideation | Define the job before brainstorming features | "When I'm commuting alone, I want something to occupy me and satisfy hunger, so I'm not hungry until lunch" |
| Feature prioritization | Evaluate whether a feature serves the core job | Prioritize features that help accomplish the stated job over nice-to-have additions |
| Positioning & messaging | Use the job statement language in marketing copy | Lead with the circumstance and desired progress, not product specs |
Copy patterns:
- "When you're [circumstance], you need [progress] -- that's exactly what [product] does"
- Lead with the situation the customer recognizes, not the product category
- Mirror the emotional and social dimensions alongside the functional one
Ethical boundary: Never fabricate or exaggerate circumstances to manufacture urgency. The job must reflect genuine customer progress, not artificially created anxiety.
See: references/innovation-process.md
2. Forces of Progress (Push, Pull, Anxiety, Habit)
Core concept: The decision to "hire" a new product results from the interplay of four forces: Push (frustration with current situation), Pull (attraction of new solution), Anxiety (fear of the new), and Habit (comfort with current behavior). Change only happens when Push + Pull > Habit + Anxiety.
Why it works: Most innovation efforts focus only on making the product better (increasing Pull), but ignore the equally powerful anti-change forces. Understanding all four forces reveals why great products still fail to gain adoption.
Key insights:
- Push is frustration with the current situation ("this annoys me")
- Pull is the attraction of a new solution ("I want this")
- Habit is attachment to current behavior ("I've always done it this way")
- Anxiety is fear of the new ("what if it doesn't work?")
- Often it's more effective to reduce anxiety and habit than to increase push and pull
- Passive seekers (vaguely aware of a problem) are easier to influence than active seekers who already have criteria
Product applications:
| Context | Application | Example |
|---|---|---|
| Onboarding design | Reduce anxiety with free trials, guarantees, and social proof | Money-back guarantee addresses "what if it doesn't work?" anxiety |
| Switching campaigns | Address habit directly by making migration effortless | One-click data import from competitor reduces habit friction |
| Content marketing | Awaken push in passive seekers by naming their frustration | Blog post: "5 signs your current tool is costing you hours every week" |
Copy patterns:
- Address anxiety directly: "No lock-in, cancel anytime, your data is always yours"
- Name the push: "Tired of [frustration]? There's a better way"
- Reduce habit friction: "Switch in 5 minutes -- we import everything automatically"
Ethical boundary: Never manufacture artificial push by exaggerating pain or creating fear. Reducing real anxiety is ethical; creating new anxiety to drive sales is manipulation.
See: references/competitive-strategy.md
3. The Big Hire & Little Hire
Core concept: There are two distinct decision moments: the Big Hire (purchase/signup decision, happens once) and the Little Hire (decision to use in the moment, happens repeatedly). Winning the Big Hire does not guarantee the Little Hire.
Why it works: Many products win the sale but lose the customer because they optimize only for the purchase decision and neglect the repeated usage decision. Understanding both moments reveals where retention problems truly originate.
Key insights:
- Big Hire is driven by marketing, onboarding, and first impressions
- Little Hire is driven by product quality, UX, and ongoing value delivery
- Many products lose at the Little Hire stage -- purchased but never used
- The forces of progress operate differently at each stage: Big Hire anxiety is about the purchase risk; Little Hire anxiety is about effort and learning curves
- Retention problems are almost always Little Hire failures, not Big Hire failures
Product applications:
| Context | Application | Example |
|---|---|---|
| Retention analysis | Distinguish Big Hire metrics from Little Hire metrics | Track "first use after signup" and "weekly active usage" separately from signup conversion |
| Product design | Optimize the repeated usage experience, not just first impression | Reduce friction in daily workflows even if onboarding is already smooth |
| Customer success | Monitor Little Hire signals to predict churn | Declining usage frequency is a Little Hire failure signaling upcoming churn |
Copy patterns:
- Big Hire copy focuses on the promise: "Transform how you [job]"
- Little Hire copy focuses on ease: "One click and you're done"
- Re-engagement copy addresses Little Hire failure: "We've made [specific friction] easier"
Ethical boundary: Never design dark patterns that win the Big Hire (e.g., hidden fees, misleading trials) while failing the Little Hire. Both decisions must deliver genuine progress.
See: references/case-studies.md
4. Competitive Landscape (Non-Obvious Competition)
Core concept: True competition is everything a customer can "hire" for the same job, often from completely different product categories. Competitors are defined by the job, not by industry classification.
Why it works: Analyzing competition through product categories creates blind spots. A milkshake competes with bananas, bagels, boredom, and podcasts. Netflix competes with TikTok, sleep, family conversation, and games. By mapping the full competitive landscape around the job, teams spot threats and opportunities invisible to traditional analysis.
Key insights:
- Non-consumption (doing nothing) is often the biggest competitor
- Workarounds and compensating behaviors reveal unserved jobs: people hack, combine, and improvise solutions
- Online courses compete with books, YouTube, mentoring, and doing nothing
- Integration is needed when performance is "not good enough" for the job; modularization when it's "good enough"
- The best competitive positioning answers "what job are we the best hire for?" not "how do we compare to similar products?"
Product applications:
| Context | Application | Example |
|---|---|---|
| Competitive analysis | Map all hires for the same job across categories | A project management tool competes with spreadsheets, sticky notes, email threads, and memory |
| Positioning strategy | Position against the real alternative, not the obvious one | Position against "doing it manually" rather than against a named competitor |
| Pricing strategy | Price relative to the job's value, not competitor pricing | If the job saves 10 hours per week, price against the value of that time, not against similar SaaS products |
Copy patterns:
- "Stop using [workaround] for [job] -- there's a purpose-built solution"
- "You wouldn't hire a [bad fit] to [job] -- so why are you using [current hack]?"
- Position around the job outcome, not feature comparison charts
Ethical boundary: Never misrepresent competitors or create false equivalences. Honest competitive framing based on the job is powerful; distorting alternatives is deceptive.
See: references/competitive-strategy.md
5. Customer Discovery Interviews
Core concept: Don't ask customers directly "what do you need" -- they don't know. Instead, investigate the purchase timeline by reconstructing the moments of first thought, search, purchase, and usage to uncover the real job.
Why it works: Customers rationalize decisions after the fact and can't articulate latent needs. By walking backward through the concrete events of their decision journey, you uncover the true circumstances, forces, and tradeoffs that drove their behavior.
Key insights:
- First thought questions: "When did you first think about looking for a solution?", "What was happening in your life then?", "What was frustrating you?"
- Search questions: "What alternatives did you look for?", "What eliminated options?", "Who did you talk to about this decision?"
- Purchase moment questions: "Where were you?", "What ultimately convinced you?", "What were you afraid of?"
- Usage questions: "Is the product doing what you expected?", "What surprised you?", "What's still missing?"
- Signals of undiscovered jobs: workarounds, non-consumption, compensating behaviors, negative emotions with current solutions
Product applications:
| Context | Application | Example |
|---|---|---|
| New market entry | Interview people who recently switched to or from a competitor | Reconstruct the timeline to find what pushed them away and pulled them toward the new solution |
| Churn reduction | Interview churned customers about their decision timeline | Discover whether the failure was Big Hire (wrong expectations) or Little Hire (poor daily experience) |
| Feature discovery | Interview customers using workarounds | A customer using spreadsheets alongside your product reveals an unmet job dimension |
Copy patterns:
- Use exact customer language from interviews in marketing copy
- "We heard you say [verbatim quote] -- so we built [feature]"
- Frame benefits using the circumstances and emotions customers actually described
Ethical boundary: Never lead interview subjects toward predetermined conclusions. The goal is genuine discovery, not confirmation of existing assumptions.
See: references/innovation-process.md
6. Designing for the Job
Core concept: Build the entire product experience -- features, metrics, and organization -- around helping the customer accomplish their job, not around internal capabilities or competitive feature parity.
Why it works: When every product decision answers "will this help the customer better accomplish their job?", teams avoid feature bloat, build coherent experiences, and create products that customers genuinely value. If the team cannot answer the question, the job is not yet understood.
Key insights:
- Replace customer satisfaction metrics with "did the job get done?" metrics
- Replace NPS with "reasons for hiring and firing"
- Replace feature usage metrics with "progress on the job"
- When the job is poorly understood, integrate (control entire experience); when well understood, modularize (specialize components)
- Integrate where performance is "not good enough" for the job; modularize where it's "good enough"
- Every product decision should answer: "Will this help the customer better accomplish their job?"
Product applications:
| Context | Application | Example |
|---|---|---|
| Metrics design | Define success metrics around job completion | Track "time from problem to resolution" instead of "features used per session" |
| Product roadmap | Prioritize based on job dimensions (functional, emotional, social) | A functional improvement that ignores the emotional dimension may not move the needle |
| Organizational alignment | Structure teams around jobs, not product components | A "morning commute job" team owns everything from content to packaging to distribution |
Copy patterns:
- "Built for [the job], not for [the category]"
- Emphasize outcome and progress, not features and specifications
- "Everything you need to [job] -- nothing you don't"
Ethical boundary: Never design addictive patterns that serve engagement metrics rather than genuine customer progress. The job framework demands that the customer's progress is the true north, not your retention numbers.
See: references/organizational-change.md
Common Mistakes
| Mistake | Why It Fails | Fix |
|---|---|---|
| Defining jobs too narrowly around your product | You miss the real competitive landscape and build features no one needs | Define the job from the customer's perspective, never mentioning your product |
| Ignoring the emotional and social dimensions | Functional-only jobs miss why customers actually choose (and stay with) products | Always complete all three dimensions: functional, emotional, and social |
| Confusing jobs with goals or tasks | Goals are too abstract ("be healthy") and tasks are too specific ("click button") to drive strategy | Jobs describe progress in specific circumstances -- more concrete than goals, more strategic than tasks |
| Only increasing Pull while ignoring Anxiety and Habit | A great product still fails if switching costs and fear are too high | Map all four forces and design interventions for each, especially reducing anti-change forces |
| Winning the Big Hire but ignoring the Little Hire | High acquisition with high churn -- purchased but never used | Track and optimize the repeated usage decision separately from the purchase decision |
| Asking customers "what do you want?" | Customers rationalize and can't articulate latent needs; you get incremental feature requests | Use timeline-based discovery interviews that reconstruct actual behavior and decisions |
| Defining competition by product category | You miss the real threats and opportunities from adjacent categories and non-consumption | Map every alternative the customer could "hire" for the same job, including doing nothing |
Quick Diagnostic
| Question | If No | Action |
|---|---|---|
| Can you state the job in one sentence without mentioning your product? | You're product-focused, not job-focused | Write a job statement: "When [circumstances], I want to [progress], so I can [outcome]" |
| Have you mapped all four forces (Push, Pull, Anxiety, Habit)? | You're likely over-investing in Pull and ignoring barriers | Map each force and design specific interventions for Anxiety and Habit |
| Do you know the emotional and social dimensions of the job? | Your product may win functionally but lose on experience | Conduct discovery interviews focused on feelings and social context around the decision |
| Have you identified non-obvious competitors from other categories? | You have blind spots in your competitive landscape | List everything a customer could "hire" for the same job, including non-consumption |
| Are you tracking Little Hire separately from Big Hire? | Acquisition problems become indistinguishable from retention problems | Create separate metrics for purchase conversion and repeated usage engagement |
| Can your team explain how a feature helps accomplish the job? | You're building features without strategic grounding | Require every feature proposal to reference the specific job dimension it serves |
| Have you interviewed customers about their purchase timeline? | Your understanding of the job is based on assumptions, not evidence | Conduct 10+ discovery interviews reconstructing the first-thought-to-usage journey |
See: references/diagnostics.md for the full diagnostic checklist.
Examples and Case Studies
See: references/case-studies.md for detailed analyses (SNHU, American Girl, Intuit).
Reference Files
- innovation-process.md: Job hunting methodology, job atlas, prototype testing, job statements
- competitive-strategy.md: Non-obvious competition, jobs-based positioning, pricing strategy
- organizational-change.md: Overcoming objections, feature-factory trap, executive buy-in, change management
- diagnostics.md: Diagnostic checklist for evaluating products through the jobs lens
- case-studies.md: Detailed analyses of SNHU, American Girl, Intuit, and more
About the Author
Clayton M. Christensen (1952-2020) was the Kim B. Clark Professor of Business Administration at Harvard Business School and one of the most influential management thinkers of the modern era. He is best known for introducing the theory of disruptive innovation in his landmark book The Innovator's Dilemma (1997), which fundamentally changed how business leaders think about competition and market evolution. Christensen developed the Jobs to Be Done framework as a practical methodology for understanding customer motivation and driving successful innovation, detailed in Competing Against Luck (2016). He co-founded the innovation consulting firm Innosight and the Clayton Christensen Institute for Disruptive Innovation. Christensen was ranked the #1 management thinker in the world by Thinkers50 and received the award multiple times. His body of work, spanning nine books including The Innovator's Solution and How Will You Measure Your Life?, continues to shape product strategy, corporate innovation, and entrepreneurial thinking worldwide.
Further Reading
This skill is based on the Jobs to Be Done framework developed by Clayton M. Christensen. For the complete methodology, case studies, and deeper insights, read the original book:
- "Competing Against Luck: The Story of Innovation and Customer Choice" by Clayton M. Christensen, Taddy Hall, Karen Dillon, and David S. Duncan
Overview
Discover what customers truly need by analyzing the "job" they hire your product to do.
Prerequisites
- Access to the API environment or API
- Required CLI tools installed and authenticated
- Familiarity with API concepts and terminology
Instructions
- Assess the current state of the API configuration
- Identify the specific requirements and constraints
- Apply the recommended patterns from this skill
- Validate the changes against expected behavior
- Document the configuration for team reference
Output
- Configuration files or code changes applied to the project
- Validation report confirming correct implementation
- Summary of changes made and their rationale
See API implementation details for output format specifications.
Error Handling
| Error | Cause | Resolution |
|---|---|---|
| Authentication failure | Invalid or expired credentials | Refresh tokens or re-authenticate with API |
| Configuration conflict | Incompatible settings detected | Review and resolve conflicting parameters |
| Resource not found | Referenced resource missing | Verify resource exists and permissions are correct |
Examples
Basic usage: Apply jobs to be done to a standard project setup with default configuration options.
Advanced scenario: Customize jobs to be done for production environments with multiple constraints and team-specific requirements.
Resources
- Official API documentation
- Community best practices and patterns
- Related skills in this plugin pack