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) -- the customer wants to move from the current state to a better one
• Circumstances -- context determines the job, not customer attributes (demographics are useless)
• Hiring/Firing -- the customer actively chooses a product for the "job"

Scoring

Goal: 10/10. Score 1 point per satisfied row in the Quick Diagnostic (7 rows) plus up to 3 points for depth: +1 if all three job dimensions are evidenced, +1 if the job statement avoids any product/solution name, +1 if competition includes non-consumption. Bands: 9-10 = job stated without the product, all four forces mapped, three dimensions evidenced, non-obvious competition and Little Hire tracked; 5-6 = job named but one or two diagnostic rows fail (usually missing forces or emotional/social dimensions); <=3 = product-first framing, demographic segmentation, or Pull-only thinking. Always state the current score and the specific diagnostic rows to fix.

Three Dimensions of Every Job

Every job has three inseparable dimensions -- omitting any means failure:

Framework

1. The Job Statement

Core concept: A job statement captures the progress a customer seeks in a specific circumstance, in a structured format separating context, desired progress, and expected outcome.

Why it works: Because jobs are stable while solutions churn, anchoring on the job protects a roadmap from chasing features that the next technology shift makes irrelevant.

Key insights:

• Format: "When [circumstances], I want to [progress], so I can [outcome]"
• Circumstances matter more than 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:

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

See references/innovation-process.md when running an innovation project end-to-end -- the job-hunting methodology, the job atlas, and fill-in statement templates.

2. Forces of Progress (Push, Pull, Anxiety, Habit)

Core concept: The decision to "hire" a new product results from four forces: Push (frustration with the current situation), Pull (attraction of the new solution), Anxiety (fear of the new), and Habit (comfort with the current behavior). Change happens only when Push + Pull > Habit + Anxiety.

Why it works: Most innovation efforts only increase Pull while ignoring the anti-change forces -- which is why great products still fail to gain adoption.

Key insights:

• Push: "this annoys me"; Pull: "I want this"; Habit: "I've always done it this way"; Anxiety: "what if it doesn't work?"
• Reducing anxiety and habit is often more effective than increasing push and pull
• Passive seekers (vaguely aware of a problem) are easier to influence than active seekers who already have criteria

Product applications:

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"

See references/competitive-strategy.md when mapping competitors or writing positioning -- forces analysis, the non-obvious-competition tables, and the jobs-based positioning formula with worked examples.

3. The Big Hire & Little Hire

Core concept: Two distinct decision moments: the Big Hire (purchase/signup, 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 the purchase decision -- understanding both moments reveals where retention problems truly originate.

Key insights:

• Big Hire is driven by marketing, onboarding, and first impressions; Little Hire by product quality, UX, and ongoing value
• Big Hire anxiety is purchase risk; Little Hire anxiety is effort and learning curves
• Retention problems are almost always Little Hire failures -- purchased but never used

Product applications:

Copy patterns:

• Big Hire copy sells the promise: "Transform how you [job]"
• Little Hire copy sells ease: "One click and you're done"
• Re-engagement copy addresses the failure: "We've made [specific friction] easier"

See references/case-studies.md when you need a worked precedent to reason from -- full Big Hire / Little Hire breakdowns of SNHU, American Girl, and Intuit.

4. Competitive Landscape (Non-Obvious Competition)

Core concept: True competition is everything a customer can "hire" for the same job, often from completely different categories. Competitors are defined by the job, not by industry classification.

Why it works: Category-based analysis creates blind spots: a milkshake competes with bananas, bagels, and podcasts; Netflix competes with TikTok, sleep, and family conversation. Mapping the full landscape around the job reveals threats and opportunities traditional analysis misses.

Key insights:

• Non-consumption (doing nothing) is often the biggest competitor
• Workarounds and compensating behaviors reveal unserved jobs -- people hack, combine, and improvise
• Integrate where performance is "not good enough" for the job; modularize where it's "good enough"
• The best positioning answers "what job are we the best hire for?", not "how do we compare to similar products?"

Product applications:

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

5. Customer Discovery Interviews

Core concept: Don't ask customers "what do you need" -- they don't know. Instead, reconstruct the purchase timeline (first thought, search, purchase, usage) to uncover the real job.

Why it works: Customers rationalize decisions after the fact and can't articulate latent needs; walking backward through concrete events reveals the true circumstances, forces, and tradeoffs that drove behavior.

Key insights:

• First thought: "When did you first look for a solution? What was happening in your life? What frustrated you?"
• Search: "What alternatives did you consider? What eliminated options? Who did you talk to?"
• Purchase: "Where were you? What ultimately convinced you? What were you afraid of?"
• Usage: "Is it doing what you expected? What surprised you? What's still missing?"
• Signals of undiscovered jobs: workarounds, non-consumption, compensating behaviors, negative emotions toward current solutions
• Ask only about past events, never hypotheticals ("would you...", "do you wish...") -- a question that names your solution or a benefit leads the subject and produces confirmation, not discovery

Product applications:

Copy patterns:

• Use exact customer language from interviews in marketing copy
• "We heard you say [verbatim quote] -- so we built [feature]"
• Frame benefits in the circumstances and emotions customers actually described

6. Designing for the Job

Core concept: Build the entire experience -- features, metrics, organization -- around helping the customer accomplish their job, not around internal capabilities or feature parity.

Why it works: When every decision answers "will this help the customer better accomplish their job?", teams avoid feature bloat and build coherent products; if you can't answer it, you don't understand the job yet.

Key insights:

• Replace customer satisfaction metrics with "did the job get done?"
• Replace NPS with "reasons for hiring and firing"; replace feature usage with "progress on the job"
• Organize teams and processes around jobs, not internal capabilities or product components

Product applications:

Copy patterns:

• "Built for [the job], not for [the category]"
• "Everything you need to [job] -- nothing you don't"
• Emphasize outcome and progress, not features and specifications

See references/organizational-change.md when adoption is the bottleneck rather than the analysis -- escaping the feature-factory trap, winning executive buy-in, and managing the change.

Common Mistakes

Quick Diagnostic

When the inline Quick Diagnostic above is not enough -- you are diagnosing a symptom (low signups, high churn, "used wrong") or need JTBD-specific metrics -- see references/diagnostics.md: the "why aren't they buying" symptom table, churn-pattern tables, and traditional-vs-JTBD metric swaps.

Further Reading

For the complete methodology, case studies, and deeper insights:

• "Competing Against Luck: The Story of Innovation and Customer Choice" by Clayton M. Christensen, Taddy Hall, Karen Dillon, and David S. Duncan

About the Author

Clayton M. Christensen (1952-2020) was the Kim B. Clark Professor of Business Administration at Harvard Business School, best known for the theory of disruptive innovation introduced in The Innovator's Dilemma (1997). He developed Jobs to Be Done as a practical innovation methodology in Competing Against Luck (2016) and was repeatedly ranked the world's #1 management thinker by Thinkers50.