Jobs to Be Done (JTBD): Framework, Examples, and How to Apply It

Most products fail not because the team built the wrong thing technically, but because they never understood why customers were buying in the first place. The jobs to be done (JTBD) framework is the lens that fixes that blind spot. It shifts the unit of analysis from the product itself to the progress the customer is trying to make.

What is jobs to be done (JTBD)?

Jobs to be done (JTBD) is a theory of customer motivation that says people don't buy products or services outright. They "hire" them to get a specific job done in their lives. A job, in this context, is the progress a person is trying to make in a particular situation, including the functional task they want to accomplish, the emotional state they want to reach, and the social perception they want to manage.

The framework was developed and popularized by Harvard Business School professor Clayton Christensen alongside colleagues Tony Ulwick and Bob Moesta. It grew out of Christensen's research into why well-managed companies still got blindsided by competitors, a problem he later explored in disruptive innovation. The insight was simple but counterintuitive: customers rarely think in terms of product categories. They think in terms of the outcome they need right now.

Key Facts

• Products designed around JTBD research have a new product success rate of 86%, compared to roughly 17% for traditionally developed products, according to Strategyn's outcome-driven innovation research (2016).
• Only 5% of new products launched in the US each year succeed by most industry measures, despite heavy market research investment, per Nielsen IQ data (2014).
• 95% of new products fail because companies focus on the customer rather than the job the customer is trying to get done, according to Clayton Christensen's Harvard Business School analysis (2016).

The job statement formula

A job statement is the core tool of JTBD. It captures what the customer is trying to accomplish in a structured format that makes it testable and actionable. The standard formula is:

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

This structure forces you to anchor the job in a real context (not a demographic), identify the underlying drive (not a feature request), and name the benefit the customer actually cares about (not what they said they wanted).

Here's how that plays out across different products and situations:

Notice that in each row, the product named at the end isn't what the customer would tell you they're shopping for. They'd tell you something much closer to the situation and motivation columns.

Functional, emotional, and social jobs

Every job a customer hires a product to do has up to three layers. Most strategy work only addresses the first.

A scheduling tool that only solves the functional job is a commodity. One that also reduces scheduling anxiety (emotional) and makes the user look professional and organized (social) is genuinely differentiated. That's why JTBD is more than a research method: it's a guide to where your value proposition has room to grow.

The three layers also reveal why switching happens. Customers don't switch products because of features. They switch when the current product stops making progress on the emotional or social job, even if the functional job is still being met adequately.

How to apply the jobs to be done framework

Applying JTBD in practice follows a consistent sequence. The goal at each step is to get closer to the real job and farther from your assumptions about it.

Step 1: Interview customers around events, not opinions

Don't ask customers what they want in a product. Ask them to walk you through the last time they hired something to get a particular job done. What triggered the search? What options did they consider? What made them switch? What did they hope the new solution would change?

Tony Ulwick calls this "switch interviews." You're trying to reconstruct the timeline of demand: the moment the old solution became inadequate, the moment the customer started looking, and the final push that caused them to act. Shoot for 10 to 15 interviews before looking for patterns.

Step 2: Extract and name the jobs

From the interview transcripts, pull out the recurring situations, motivations, and desired outcomes. Group them into job clusters. At this stage, you're building a map of all the jobs your customers are trying to get done, not just the ones your product currently addresses.

Write each job as a statement using the when-I want-so I can formula. Keep the language in the customer's voice, not your internal vocabulary.

Step 3: Identify underserved outcomes

For each job, ask two questions: How important is getting this right? How satisfied is the customer with current solutions? Jobs that are important but poorly served are the gaps where real innovation lives. This is the core of Ulwick's outcome-driven innovation method, and it connects directly to blue ocean strategy, which frames competition as finding spaces where demand goes unmet.

Map the jobs on a two-by-two: importance on one axis, satisfaction on the other. The high-importance, low-satisfaction quadrant is your product opportunity zone.

Step 4: Prioritize by strategic fit

Not every underserved job is yours to solve. Filter the opportunities against your existing capabilities, competitive positioning, and the markets you've chosen to serve. Use JTBD findings as an input to your Ansoff matrix planning: does this job open a new market, or deepen your position in an existing one?

Step 5: Design and test solutions around the job

Build features, messaging, or entirely new products around the specific job and its three layers. Then test them directly against the job statement. Does this solution help the customer make the progress they described? Does it address the emotional and social layers, not just the functional one?

Good JTBD-driven design often removes features rather than adding them. Once you know the actual job, a lot of functionality that felt important turns out to be noise that makes the core progress harder to achieve.

Jobs to be done examples

The most cited JTBD story is the McDonald's milkshake study, and it's worth understanding in full because it shows how wrong intuitive product thinking can be.

McDonald's wanted to increase milkshake sales. They surveyed customers and got predictable answers: people wanted thicker shakes, more flavors, bigger cups. They improved all of these things. Sales didn't move.

A JTBD researcher then spent a day watching when people actually bought milkshakes and interviewing them. The finding was unexpected. Almost half of all milkshake sales happened before 8 AM. These customers were on long solo commutes. They weren't hungry enough for a full meal, but they needed something to hold them until lunch. The milkshake did this perfectly: it took a long time to consume, it fit in the cup holder, it wasn't messy, and it was more filling than a banana or a granola bar.

The job wasn't "I want a tasty treat." The job was "help me get through a boring commute without being hungry and without making a mess." The competitors weren't Wendy's milkshakes. They were bananas, bagels, and energy bars.

Here are three additional examples across different industries:

In each case, understanding the real job suggests a different marketing message, a different onboarding experience, and different features to prioritize. And it often reveals competitors you weren't tracking because you were watching the wrong product category.

Common mistakes

Confusing segments with jobs. "Millennial professionals who work remotely" is a demographic segment, not a job. Jobs cut across demographics: a 55-year-old executive and a 28-year-old freelancer can have exactly the same job when they sit down to write a proposal.

Treating stated preferences as jobs. When a customer says "I want a faster product," that's a preference, not a job. The job is underneath: "When I'm presenting to clients, I want to look competent, so I can win their trust." Speed is a way to get that job done. It's not the job itself.

Solving only the functional layer. Many teams do JTBD research, identify the functional job accurately, and then design only for that. They wonder why adoption is low or why customers churn after 90 days. The emotional and social jobs weren't addressed, so the customer eventually found something that felt better, even if it was functionally similar.

Skipping the prioritization step. Once you map all the underserved jobs, it's tempting to try to address all of them. That leads to bloated products that do many things poorly. Prioritize based on strategic fit, not just opportunity size.

Letting the framework go stale. Jobs shift as circumstances change. A job that was underserved two years ago may now be adequately served by a competitor. JTBD research needs to be refreshed periodically, not treated as a one-time discovery.

Best practices

• Interview around real events, not hypotheticals. "What would you want?" produces wishful thinking. "Walk me through the last time you hired something for this" produces actionable insight.
• Look at what customers don't buy, not just what they do. Non-consumption often reveals a job that no current product is serving well enough. This is one of the key sources of disruptive innovation.
• Map JTBD findings to your product life cycle. Different customer jobs dominate at different stages of the product life cycle. Growth-stage customers often have different primary jobs than early adopters.
• Use job statements to write better positioning copy. Good JTBD research translates directly into messaging: your copy should describe the situation and desired outcome, not just the product's features.
• Connect JTBD to your competitive analysis. The jobs lens helps you see your real competitive set. Once you know what job your product is hired for, you can identify every other solution the customer might use instead, including non-consumption.
• Pair JTBD with outcome metrics. Ulwick's method assigns importance and satisfaction scores to each job, giving you a quantitative prioritization tool rather than just a qualitative story.

Frequently asked questions

What is the main idea behind jobs to be done?

The core idea is that customers don't buy products. They hire products to make progress on a specific job in a specific situation. Understanding that job, including its functional, emotional, and social dimensions, is more useful for product and strategy decisions than demographic data or stated preferences.

How is JTBD different from user personas?

Personas describe who the customer is: demographics, behaviors, attitudes. JTBD describes what the customer is trying to do in a specific moment. Two people with very different personas can have identical jobs. JTBD tends to be more predictive of switching behavior and purchase decisions because it's grounded in situations rather than archetypes.

What is a job statement?

A job statement follows the format: When [situation], I want to [motivation], so I can [outcome]. It captures the context, the underlying drive, and the desired progress. A well-written job statement is specific enough to be testable and general enough to apply to multiple potential solutions.

How does JTBD relate to competitive advantage?

JTBD reveals your real competitive set: any solution the customer might use to get the same job done. That set often includes products from entirely different categories, not just direct competitors. Knowing the real job helps you understand where your competitive advantage actually lives and where it's vulnerable.

Can the framework be used for B2B products?

Yes. In B2B contexts, the job usually has multiple layers: the organization's functional job (automate procurement approvals), the buyer's professional job (look like a competent decision-maker to the CFO), and the user's daily job (stop chasing people for approvals manually). All three need to be understood, and they don't always align.

Jobs to be done doesn't replace the rest of your strategy toolkit. But it anchors all of it in something grounded: the real progress your customers are trying to make. Strategy frameworks like the business model canvas or Ansoff matrix become sharper tools once you know which jobs you're designing around.