jobs-to-be-done

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

1. Assess the current state of the API configuration
2. Identify the specific requirements and constraints
3. Apply the recommended patterns from this skill
4. Validate the changes against expected behavior
5. 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