Jobs to Be Done (JTBD) Framework Explained

The Jobs to Be Done framework, usually shortened to JTBD, says that customers don't really buy products because of who they are — they "hire" a product to get a specific job done in their life. The classic example, from the framework's most famous case study: people don't buy a quarter-inch drill because they want a drill, they buy it because they want a quarter-inch hole. Understanding the real underlying "job" a customer is trying to get done — not just their surface-level demographics or the feature they asked for — reveals what they'd actually switch products for.

Quick facts

• The core idea: customers "hire" a product to complete a specific job, and "fire" it for something that does that job better.
• A "job" isn't the product feature itself — it's the underlying progress the customer is trying to make in their life or work.
• JTBD looks past demographics (age, job title, company size) toward the actual circumstance and motivation driving a purchase or a switch.
• The framework was popularized by Clayton Christensen, a Harvard Business School professor, through his work on innovation.
• JTBD pairs especially well with customer discovery interviews — see Jobs to Be Done Interview Technique.

The core idea, explained with the classic example

The famous "quarter-inch drill" example captures the whole idea: a hardware store doesn't actually sell drills because people want to own a drill — they sell drills because people need a quarter-inch hole in a wall, and a drill happens to be the best current way to get that hole. If a better way to make a quarter-inch hole existed — cheaper, faster, safer — customers would switch to it immediately, even if it looked nothing like a drill. The "job" is making the hole. The drill is just the current best solution to that job.

Why this matters more than demographics

Traditional customer segmentation often groups people by who they are — age, income, job title, company size. JTBD argues this misses the real driver of a purchase decision: the situation someone finds themselves in, and the progress they're trying to make. Two people with identical demographics can be trying to accomplish completely different jobs, and two very different people can be trying to accomplish the exact same job. A product built around demographics risks solving a problem some segment doesn't actually have; a product built around a real job solves something people will actually pay for, switch to, or recommend.

A worked example: a meal-kit delivery service

Picture a meal-kit company trying to understand why customers actually sign up. A demographic view might say "our customers are working professionals aged 28-40." A JTBD view digs deeper, and might reveal several distinct jobs different customers are actually hiring the product for:

• "Help me feel like a competent home cook without the planning effort." This customer cares about the recipe variety and the confidence of cooking something new.
• "Help me eat healthier without thinking about it." This customer cares mostly about nutrition information and portion control, and barely notices the recipe variety.
• "Help me spend quality time cooking with my partner or kids." This customer cares about the experience of cooking together, not primarily about saving time.

These are three genuinely different jobs, even though all three customers might fit the same basic demographic profile. A product team that understands these distinct jobs can make sharper decisions — like whether to prioritize recipe variety, nutritional clarity, or a more experience-focused unboxing — instead of guessing based on a generic customer persona.

How to actually uncover a customer's real "job"

JTBD is typically uncovered through a specific style of interview, different from a standard user interview — instead of asking what features someone wants, you ask about the actual moment they decided to start using (or switch to) a product: what were they doing right before, what triggered the search for a new solution, what did they consider and reject, and why. This "switch interview" style reconstructs the real story behind a decision, which tends to reveal the underlying job far more reliably than directly asking "why do you use this product," which often produces a rationalized, surface-level answer rather than the real underlying motivation.

JTBD job statement format

A job statement is often written in a simple format: "When [situation], I want to [motivation], so I can [expected outcome]." For example: "When I get home late from work with no time to plan dinner, I want to cook something that feels homemade without a lot of decision-making, so I can still feel like I'm eating well without extra effort." This format deliberately focuses on the situation and desired outcome, not on a specific feature or solution.

Common mistakes when applying JTBD

• Confusing a feature request with the underlying job. "I want a mobile app" is a requested solution, not a job — the real job might be "I want to check on this while I'm away from my desk," which could be solved several different ways, not only a mobile app.
• Writing job statements that are really just personas in disguise. A job statement focused on demographics ("as a busy professional...") rather than situation and motivation misses the point of the framework.
• Only interviewing current happy customers. Some of the most valuable JTBD insight comes from understanding why someone switched away from a competitor, or why they never adopted a solution at all — insight current happy customers alone can't fully provide.
• Treating JTBD as a one-time research exercise. The jobs customers are trying to get done can shift as a market and customer expectations evolve — periodically revisiting this understanding matters, not just doing it once at a company's founding.

FAQ

Who created the Jobs to Be Done framework? Clayton Christensen, a Harvard Business School professor, popularized JTBD through his work on disruptive innovation, though related ideas had existed in marketing theory before his specific framing brought it to wider prominence in product and business circles.

How is JTBD different from a user persona? A persona typically describes a type of person — demographics, role, general characteristics. A job statement describes a situation and a desired outcome, deliberately independent of who the person is — the same job can apply to very different types of people, which is the whole point of the distinction.

Can JTBD be used for B2B products, not just consumer products? Yes — B2B purchases are also driven by an underlying job, like "help our team collaborate on documents without version-control confusion," even though the buying process involves more stakeholders and a longer decision cycle than a typical consumer purchase.

How does JTBD relate to product positioning? They connect directly — understanding the real job a customer is hiring your product for is often the foundation for strong product positioning, since positioning is fundamentally about being the best choice for a specific need, and JTBD is how you uncover what that need actually is.