Unlock Growth - Lock Savings
Offer Ends Soon

What Is Jobs to Be Done (JTBD)? A Complete Guide

Image
What Is Jobs to Be Done (JTBD)? A Complete Guide
Learn what Jobs to Be Done means, how the framework works, real-world examples, and a ready-to-use template that product and agile teams can apply.
Blog Author
Published on
Aug 18, 2026
Views
2437
Read Time
10 Mins
Table of Content

Jobs to Be Done is a customer research approach built on one idea: people don't buy products, they "hire" them to make progress in a specific situation. Instead of studying age, income, or job title, teams focus on the "job" a customer is trying to get done and design around it. The idea traces back to marketing professor Theodore Levitt's drill-and-hole observation and was later shaped into a full model by Clayton Christensen, Bob Moesta, and Tony Ulwick, each adding a different lens on the same core insight. This guide breaks down the theory, framework, real examples, methodology, and how the concept shows up in SAFe (Scaled Agile Framework) teams.

What Is Jobs to Be Done (JTBD)?

Jobs to Be Done is the idea that customers "hire" a product or service to complete a specific task, solve a problem, or move closer to a goal — and they "fire" it the moment something else does that job better. The classic example: nobody wants a quarter-inch drill; they want a quarter-inch hole. The drill is hired to deliver the hole.

The Core Idea Behind Jobs to Be Done Theory

Jobs to be Done theory, popularized by Harvard professor Clayton Christensen, argues that a "job" remains stable over time, even as the products used to complete it change. People once hired a typewriter to draft a letter; today they hire a laptop or a phone for the same task.

Functional, Emotional, and Social Jobs

Every job usually has three layers working together, not just one:

  • Functional job — a practical task to complete, such as getting a hole drilled in a wall.

  • Emotional job — how the person wants to feel, such as feeling capable and self-sufficient.

  • Social job — how the person wants to be seen, such as being seen as handy by family.

Why This Perspective Matters for Growth

Products rarely fail because of missing features; they fail because the job was misunderstood from the start. Anchoring strategy to a stable job — rather than to a product category that technology can reshape overnight — lets a company spot disruption early and keep building things people actually want to hire.

How Does the Jobs to Be Done Framework Work?

The jobs to be done framework shifts the unit of analysis from the customer or the product to the job itself, then maps every step a customer takes before, during, and after that job.

The Job Story Format

Teams capture a job using a simple structure that avoids naming a solution too early:

"When [situation], I want to [motivation], so I can [expected outcome]."

A completed job map usually spans eight recurring stages: define, locate, prepare, confirm, execute, monitor, resolve, and modify — the same skeleton whether the job is "get a loan approved" or "plan a vacation."

Steps in the JTBD Process

  • Define the job — frame the marketing around a job, not a product category.

  • Interview customers — uncover the moment they decided to "hire" a solution.

  • Map the job steps — break the job into before, during, and after stages.

  • Prioritize unmet needs — find steps that are underserved or over-served.

  • Design and test — build a solution that nails the job better than alternatives.

What Are Some Real-World Jobs to Be Done Examples?

Looking at jobs to be done across industries makes the concept concrete rather than abstract.

The Milkshake Study

Christensen's well-known study found that many milkshakes were "hired" for a boring morning commute — something thick enough to last the drive and one-handed enough to sip while driving, not primarily because customers loved the flavor.

Everyday JTBD in Well-Known Products

  • Netflix — surface need: watch a show; underlying job: unwind and escape after a long day.

  • Slack — surface need: send a message; underlying job: reduce email clutter and reply faster.

  • Insurance — surface need: buy a policy; underlying need: feel protected against an uncertain future.

  • Duolingo — surface need: learn a language; underlying job: make daily progress without feeling like homework.

What Is the Jobs to Be Done Methodology in Practice?

In practice, the jobs to be done methodology relies on structured "switch interviews" that trace the exact moment a customer moved away from an old solution.

Switch Interviews

Instead of asking what features people want, researchers ask customers to walk through the day they first tried the new product, focusing on the push, pull, anxiety, and habit forces at play. Twelve to twenty of these conversations is often enough to spot a repeating pattern, since the goal is depth on the moment of choice, not a large statistical sample.

Outcome-Driven Innovation (ODI)

Tony Ulwick's version adds measurable "outcome statements" so teams can rank which unmet needs matter most, turning innovation into a scoring exercise rather than a guessing game. A typical outcome statement looks something like: "Minimize the time it takes to confirm a payment went through," which customers can then score on importance and current satisfaction to reveal the biggest opportunity gaps.

How Is Jobs to Be Done Used in Leading SAFe?

Jobs to Be Done fits naturally into SAFe (Scaled Agile Framework) because both approaches try to connect daily execution back to real customer value. Practitioners trained in Leading SAFe often recognize this overlap immediately, since both disciplines push teams to justify work by the value it delivers to the customer, not just the output shipped.

JTBD on Portfolio and PI Planning

Portfolio teams use the underlying work to define Value Streams and Strategic Themes, so Program Increment (PI) Planning sessions prioritize features that serve a genuine job rather than a requested list of features. At the Epic and Feature level, product managers can phrase acceptance criteria around the job outcome, which keeps Agile Release Trains focused on customer progress even as the backlog changes sprint to sprint.

JTBD vs. User Stories in Agile Teams

AspectUser StoryJTBD Approach
FocusA user type and an actionThe underlying motivation and context
RiskMay jump straight to a solutionForces discovery before solutioning
Best usedSprint-level executionDiscovery, roadmap, and PI planning

How Do You Create a Jobs to Be Done Template?

A repeatable structure helps teams capture every job statement consistently across a product line so that you can compare insights from one interview directly with another.

Elements of a JTBD Template

A workable version usually includes the situation, the motivation, the expected outcome, functional/emotional/social job notes, and current alternatives being "fired." Keep every field solution-free so the statement stays valid even after the product roadmap changes.

Sample Job Story Template 

FieldPrompt
SituationWhen I am...
MotivationI want to...
OutcomeSo I can...
Current alternativeToday I use... instead
Success metricI'll know it worked when...
 
 
 
 
 
Become Certified SAFe Agilist with StarAgile's Leading SAFe Course
 

What Else Should You Know About JTBD?

A few related questions come up often and are worth covering directly. Is JTBD a theory or a tool? It's both — Jobs to Be Done is the theory that explains customer motivation, and the JTBD framework is the applied tool teams use to act on it. What tools support this work? Common tools include customer interviews, survey platforms like Intercom's JTBD surveys, and outcome-scoring spreadsheets.

Common mistakes teams should watch for include:

Writing job statements that already name a feature, which quietly reintroduces the exact solution bias the Jobs to be done framework was built to remove. Confusing the job with the customer's job title, which pulls the analysis back toward demographics instead of motivation. Treating one round of interviews as final, when jobs should be revisited as competitors and technology changes what customers can hire instead.

Jobs to Be Done is not a one-time workshop; it is a recurring lens. Revisit the job map whenever a competitor, technology shift, or new alternative changes what customers can "hire" instead of your product.

Want to apply this thinking inside your own Agile Release Train? A Leading SAFe course teaches product managers, product owners, and Scrum Masters how to turn a job story into Strategic Themes, Features, and PI Objectives—so the customer's real motivation stays intact from discovery through delivery.

Frequently Asked Questions

1. What is the difference between Jobs to Be Done and buyer personas?

Personas group customers by who they are (age, role, income). JTBD groups them by the job they're trying to get done, since very different people can hire the same product for the same reason.

2. How is Jobs to Be Done different from Design Thinking?

Design Thinking is a broad problem-solving process (empathize, define, ideate, prototype, test). JTBD is narrower — a research method focused only on uncovering the underlying motivation behind a purchase or switch.

3. Who created the Jobs to Be Done theory?

Theodore Levitt first raised the idea in the 1960s ("People want a hole, not a drill"). Clayton Christensen popularized it in the 2000s, and Tony Ulwick and Bob Moesta each built practical methods around it.

4. How Can JTBD Research Reveal Opportunities Competitors Overlook?

  • Maps the job itself, not the category, catching alternatives like spreadsheets or "doing nothing"
  • Switch interviews uncover frustrations that never appear in feature comparisons

5. How Do You Identify the Real Competing Alternatives for a Job?

  • Ask what customers tried right before choosing you, not who else is in your industry
  • Use switch interviews to trace the trigger event and options considered
  • Real alternatives often include manual workarounds or inertia

6. How Can Teams Validate That a Job Exists Across Different Customer Segments?

  • Check if the same trigger, trade-offs, and success definition hold across 3+ segments
  • If surface details vary but the struggle stays consistent, the job is validated

7. How Should JTBD Insights Influence Product Positioning and Messaging?

  • Anchor messaging to the progress customers want, not feature lists
  • Frame copy as "when X happens, use this instead of Y"
  • Use customers' own words from interviews, not internal jargon

8. How Can JTBD Help Teams Decide Which Customers Not to Target?

  • Flags when customers hire your product for a job it can't do well
  • Poor job-fit leads to churn, support costs, and low retention
  • Excluding these segments protects focus on the strongest-fit customers

9. How Do You Measure Whether a Product Is Actually Doing the Job Better?

  • Track outcome-based metrics tied to the customer's definition of progress
  • Pair this with qualitative signals like fewer complaints or active recommendation
  • High engagement doesn't equal job success if outcomes aren't moving

10. When Should a Company Revisit or Redefine Its Core Job?

  • When growth stalls despite strong execution
  • When competitors solve the same struggle in a new way
  • Re-run switch interviews every 12–18 months to keep the job definition current
Share
WhatsappFacebookXLinkedInTelegram
About Author
Ishwin Khokhar

Corporate Trainer

Experienced Agile Coach with more than a decade of experience in transforming organizations through Agile methodologies. Specializing in SAFe (Scaled Agile Framework), I guide teams to drive continuous improvement, enhance collaboration, and achieve business agility at scale. Passionate about fostering a culture of innovation.    

Are you Confused? Let us assist you.
+1
Explore Leading SAFe® Agilist!
Upon course completion, you'll earn a certification and expertise.
ImageImageImageImage

Trending Articles

The most effective project-based immersive learning experience to educate that combines hands-on projects with deep, engaging learning.
WhatsApp