What is Jobs to Be Done?
Jobs to Be Done (JTBD) is a framework for understanding why customers make the choices they do. Originally developed by Clayton Christensen and colleagues at Harvard Business School, it reframes the central question of product development from "what should we build?" to "what job is the customer trying to get done?"
The core insight is deceptively simple: customers don't buy products or features — they hire solutions to make progress toward a goal. When someone hires your product, they fire whatever they were relying on before — whether that's a competitor, a workaround, or simply doing nothing.
"People don't want a quarter-inch drill. They want a quarter-inch hole." — Theodore Levitt, Harvard Business School
The classic milkshake example: McDonald's discovered that many milkshakes were bought early in the morning by solo commuters. They weren't buying sweetness — they were hiring the milkshake to make a boring commute more tolerable and stave off hunger until lunch. The real competition wasn't other milkshakes; it was bananas, bagels, and coffee.
This reframing has profound implications. It means your competition is defined by the customer's job, not your product category. It means features matter only insofar as they help the customer make progress. And it means the most important design question is: what is the customer actually trying to accomplish?
Customer-Centric
Focuses on the customer's goal, not product features. Prevents building solutions in search of a problem.
Stable Over Time
The job rarely changes even as technology shifts. "Share moments with friends" is the same job whether it's a postcard or Instagram.
Redefines Competition
Your real competitors are anything else hired for the same job — not just products in your category.
Reveals Opportunity
Uncovers underserved jobs — the whitespace where customers struggle to make progress and no good solution exists yet.
The Job Statement
A job statement gives the team a precise, solution-agnostic description of what the customer is trying to accomplish. The standard format captures a situation, a motivation, and an expected outcome — and deliberately omits any product or technology.
The key constraint: the statement must hold meaning even if no product exists yet. If you can replace the product name in the statement with "magic" and it still makes sense as a real human need, you have a genuine job.
| Weak Statement | Why It Fails | Stronger Version |
|---|---|---|
| "I want to use your app to track spending." | Names the solution, not the job | "When I reach the end of the month, I want to understand where my money went so I can feel in control of my finances." |
| "I want faster reporting." | Feature request, not a job | "When my manager asks for a status update, I want to provide accurate data immediately so I look prepared and credible." |
| "I need a to-do list." | Names the solution | "When I'm overwhelmed with tasks, I want to identify what actually matters today so I feel productive instead of anxious." |
Three Dimensions of Every Job
Every job has three layers operating simultaneously. Most teams address only the first. The products that win markets tend to address all three.
Functional
The practical task the customer needs to accomplish. Objective and measurable — the "what" of the job.
Example: "Transfer money to another account quickly and accurately."
Emotional
How the customer wants to feel — or not feel — during and after completing the job. Drives satisfaction and loyalty.
Example: "Feel confident and in control of my finances, not anxious."
Social
How the customer wants to be perceived by others while doing the job. Often unstated but remarkably powerful.
Example: "Look financially responsible and put-together to my partner."
This is why two products with identical functional specs perform completely differently in the market. A Volvo and a Porsche both drive you from A to B — the emotional and social dimensions are where the differentiation lives.
In customer interviews, the functional job is usually volunteered. The emotional and social jobs require listening carefully to the language customers use to describe frustration and success. Words like "embarrassed," "proud," "stressed," or "look like I know what I'm doing" are your signal.
Emotional: Feel like a competent, organized professional — not someone who loses receipts.
Social: Be seen by finance and management as low-maintenance and trustworthy.
The Four Forces of Progress
When a customer considers switching from their current solution to yours, four forces operate simultaneously. Two push them toward change; two hold them back. This model explains why products with genuinely superior capabilities often lose to established incumbents.
Struggling Moment
Frustrations, limitations, and failures of the current solution that build dissatisfaction over time until the pain becomes undeniable.
- Current tool is too slow or too complex
- Spreadsheet keeps crashing
- Support takes days to respond
- Team has outgrown the old system
Attraction of the New
The appeal of the new solution — what it promises and how it helps the customer imagine a better version of their life or work.
- Promises real-time collaboration
- Looks clean and easy to learn
- A trusted colleague raves about it
- Free trial lowers the barrier to try
Habits & Switching Costs
The invisible weight of the familiar. Existing habits, sunk costs, institutional knowledge, and the simple effort of change push back against switching.
- "I already know how this works."
- Years of data locked in old system
- Team has been trained on current tool
- Integrations built around the incumbent
Fear of the New
Worry and uncertainty about whether the new solution will actually deliver — and whether the transition itself will cause disruption or embarrassment.
- "What if I lose my data?"
- "Will my team actually adopt it?"
- "What if it doesn't integrate with X?"
- "What if it's worse than what I have?"
Most teams only focus on increasing Pull — adding more features. The smarter lever is often reducing Anxiety through free trials, easy migration, and strong onboarding. A product that is 3x better can still lose if it creates enough switching anxiety.
Pull: The new tool promises real-time collaboration, automatic saves, audit trail, and a clean interface.
Inertia: Three years of financial models live in Excel. Every analyst knows the formulas. The CFO trusts it.
Anxiety: "What if the import is incomplete? Will I have to rebuild everything? What if leadership doesn't trust a new tool?"
The practical implication: your onboarding experience, migration tooling, and free trial are not peripheral niceties — they are the mechanism for tipping the scale. Invest in them as seriously as you invest in core features.
Desired Outcomes & Outcome-Driven Innovation
Developed by Tony Ulwick, Outcome-Driven Innovation (ODI) extends JTBD by making jobs quantifiable. For every job, customers have a set of desired outcomes — the criteria they use internally to judge how well the job is being done. These are not product metrics; they are customer-controlled measures of progress.
The formula for writing a desired outcome statement:
Minimize the time it takes to find relevant information in a document
Context: when reviewing a contract under time pressure.
Minimize the likelihood of missing a critical deadline
Context: when managing multiple projects simultaneously with shifting priorities.
Maximize the confidence felt when presenting data to leadership
Context: when the data originates from multiple disparate and potentially unreliable sources.
Minimize the number of steps required to complete a recurring task
Context: when the task must be completed more than ten times per day.
In ODI research, customers rate each desired outcome on two scales: importance (how much does getting this right matter?) and satisfaction (how well is your current solution doing it?). The gap reveals opportunity:
| Importance | Satisfaction | Signal | Strategic Move |
|---|---|---|---|
| High | Low | 🔴 Underserved | Core innovation target — build this first |
| High | High | 🟡 Table stakes | Must-have to compete — never cut it |
| Low | Low | ⚪ Non-issue | Customers don't care — don't invest here |
| Low | High | 🟣 Over-served | Opportunity to simplify and reduce cost |
The JTBD Interview
JTBD is grounded in qualitative research. The goal of a JTBD interview is to reconstruct the customer's purchase timeline — the events, context, and emotions that led them from passive dissatisfaction to actively switching. You're not asking about features or ratings; you're asking about moments.
The methodology was refined by Bob Moesta (who co-developed JTBD with Christensen) and is sometimes called the "Switch Interview." The key insight: the moment of switching is when all four forces are most visible.
Anchor to the purchase moment
"Take me back to the day you decided to switch. Where were you? What had just happened right before you made the call?"
Explore the struggling moment
"What was happening in your work / life that made you realize the old way wasn't working anymore? What was the last straw?"
Map the passive and active search
"When did you first start thinking there might be something better out there? What did you look at first?"
Find the deciding moment
"What finally made you choose this one over everything else you considered? Was there a specific moment?"
Uncover what was fired
"What did you stop using when you started using this? Do you miss anything about it?"
What to listen for: The job hides in emotional language — "I just wanted to stop worrying about…", "I was embarrassed when…", "I finally felt like I could…". These phrases reveal the emotional and social dimensions of the job that no survey would surface.
Never ask hypotheticals ("Would you use a feature that…?"). Customers cannot accurately predict their own behavior in contexts they haven't lived yet. Anchor always to what they actually did, not what they imagine they might do.
Applying JTBD in Practice
JTBD creates value only when it changes how the team makes decisions — not just when it fills a research doc. Here is how each component of the framework connects to specific product and business decisions:
| JTBD Element | Decision It Informs | Example Impact |
|---|---|---|
| Job Statement | Product vision & positioning | "We help marketing managers confidently report campaign ROI to leadership" — not "analytics platform." |
| Emotional Job | UX tone, copy, design feel | Dashboard communicates calm clarity, not data density. Confirmation messages reduce anxiety, not just confirm actions. |
| Social Job | Sharing, export, and social features | One-click shareable reports because the user's social job is "look data-literate to leadership." |
| Four Forces | Onboarding & growth strategy | Build a one-click data migration wizard to reduce Anxiety; invest in free trial to lower Inertia barrier. |
| Desired Outcomes | Roadmap prioritization | Search ranks 9/10 importance, 3/10 satisfaction — it goes to the top of the roadmap over the fifth dashboard widget. |
| JTBD Interviews | Customer segmentation | Discover two distinct jobs in the user base — split the roadmap and messaging accordingly instead of averaging them. |
Emotional layer: Feel confident and in control before a high-stakes meeting.
Social layer: Be seen as data-literate and strategic, not just a spreadsheet jockey.
Top desired outcome: Minimize the time to go from raw data to a shareable, branded report.
Forces driving switch: Push — current tool requires manual copy-paste into PowerPoint. Pull — this tool promises one-click branded export. Inertia — existing PowerPoint templates the team knows well. Anxiety — "Will the formatting match our brand guidelines?"
Product decisions this unlocks: Invest in branded export templates, one-click PDF generation, and a "presentation mode" — not in more chart types, more metrics, or a better data connector.
JTBD also improves cross-functional alignment. When engineering, design, and marketing all share the same job statement, they make independently coherent decisions — because they are all optimizing for the same customer progress, not for different interpretations of a vague goal.
Teams that internalize JTBD get better at saying no. Every feature request gets evaluated against the job: does this help the customer make progress? If not, it is a distraction regardless of how many users ask for it or how interesting the engineering challenge is.