Jobs to Be Done — The Framework That Makes Product Ideas Obvious

A fast-food chain wanted to sell more milkshakes. The marketing team did the obvious stuff: surveyed customers, ran focus groups, asked what flavors people preferred, whether they wanted it thicker, cheaper, more chocolatey. They got answers. They made changes. Sales barely moved. Then Clayton Christensen's research team, pioneers of the jobs to be done framework, approached the problem differently. Instead of asking what milkshake people wanted, they asked when and why people were buying milkshakes. They camped out in the restaurant and watched. Nearly half of all milkshakes were sold before 8:30 a.m., to solo customers in business clothes who walked in, bought a shake, and drove off. No fries. No burger. Just the milkshake.

When the researchers followed up with those morning buyers, the answers had nothing to do with taste preferences. These people had a long, boring commute. They needed something to do with one hand while driving. They needed something that would last the whole trip and keep them full until lunch. They'd tried bananas (gone in two minutes). They'd tried bagels (dry, crumbs everywhere). They'd tried Snickers bars (guilt, sticky fingers). The milkshake was thick enough to last 20 minutes through a straw, filling enough to kill hunger, and clean enough for one-handed driving. The customers weren't buying dessert. They were hiring a milkshake to do a job: make my commute bearable and keep me full.

That insight is the foundation of the jobs to be done framework, and it changes how you think about every product, service, and business decision you'll ever make.

The Core Insight: Nobody Wants Your Product

Here's the uncomfortable truth at the center of JTBD theory: nobody wakes up wanting to buy a product. They wake up with a problem, a desire, or a situation that needs resolving. The product is just the thing they hire to resolve it.

Theodore Levitt, the Harvard marketing professor, put it memorably: "People don't want a quarter-inch drill. They want a quarter-inch hole." But even Levitt didn't go far enough. People don't want a quarter-inch hole either. They want a shelf on the wall. And if you push further, they want their books organized, their living room to look a certain way, their spouse to stop complaining about the boxes in the hallway. The drill is four or five steps removed from what the customer actually cares about.

This is the core principle of the jobs to be done framework. Every purchase is a hiring decision. The customer has a "job" that arises in their life, and they look around for something to "hire" to get that job done. Your product is a candidate for the position. If it does the job better than the alternatives (including doing nothing), it gets hired. If it doesn't, it gets fired.

The shift sounds subtle, but it rewires how you think about product development from the ground up. Instead of starting with "what features should our product have," you start with "what job is the customer trying to get done, and how well are the current options serving them?"

Three Types of Jobs Customers Hire For

Not every job is about getting a task completed. Christensen and the JTBD researchers identified three distinct types of jobs that drive purchasing decisions, and most products touch all three whether the product team realizes it or not.

The functional job is the obvious one. It's the task, the utility, the thing you'd put on a spec sheet. But the emotional and social jobs often drive the final hiring decision more than the functional one does.

Consider project management software. The functional job is straightforward: help me track tasks, deadlines, and assignments across a team. But the emotional job is where the real purchase decision lives. The team lead wants to feel in control of a chaotic workload. They want to feel like they won't miss something critical. The social job matters too: they want to look organized and competent when presenting project status to leadership. A tool that nails the functional job but makes the user feel confused or look disorganized in meetings will get fired for a simpler tool that does less but delivers on the emotional and social jobs.

This is why so many technically superior products lose to inferior competitors. The winner often isn't the product with the most features. It's the product that does the complete job (functional, emotional, and social) better than the alternatives.

How to Discover Jobs to Be Done: Switch Interviews

The most powerful JTBD research method is the Switch Interview, developed by Bob Moesta and Chris Spiek. Instead of asking customers what they want (people are terrible at answering that question), you study the moment someone switched from an old solution to a new one. That switching moment reveals the forces at play: what pushed them away from the old thing, what pulled them toward the new thing, what anxieties almost stopped them, and what habits kept them stuck.

The four forces of progress in a Switch Interview look like this:

For a switch to happen, Push + Pull must overcome Anxiety + Habit. This is why even products that are objectively better than the competition sometimes fail to win customers. The pull isn't strong enough, or the anxiety of switching is too high. Think about how many people stick with mediocre banks despite better options existing. The habit force is enormous, and the anxiety of moving direct deposits, updating auto-pays, and learning a new app creates enough friction to kill the switch.

The key questions in Switch Interviews aren't "what features do you want?" They're questions like: "What were you using before? What was the moment you thought 'I've had enough'? What were you afraid of when you considered switching? What almost stopped you?" These questions surface the real customer needs analysis, not the sanitized version people give in surveys.

The Job Statement: Your Product's North Star

Every JTBD research effort should produce a clear job statement. The format is simple but disciplined:

The situation is the trigger context. The motivation is what the person is trying to do. The outcome is the progress they want to make in their life. Here are real examples across different industries:

Accounting software (small business): "When tax season approaches and my receipts are scattered across three apps and a shoebox, I want to pull all my financial data into one place, so I can file accurately without paying an accountant $2,000."

Meal kit delivery: "When I get home at 7 p.m. exhausted and my family is hungry, I want to make a real dinner without planning or grocery shopping, so I can feel like a parent who feeds their kids properly without it consuming my entire evening."

Online course platform: "When I realize my industry is shifting and my current skills won't be relevant in three years, I want to learn new skills on my own schedule, so I can stay employable without quitting my job to go back to school."

CRM software: "When I'm about to hop on a call with a prospect and I can't remember our last conversation, I want to see the full relationship history in ten seconds, so I can sound prepared and close the deal instead of fumbling through pleasantries."

Notice what these job statements do. They don't mention product features. They don't specify solutions. They describe a real human situation, a motivation, and a desired outcome. That's what makes them powerful. A good job statement holds true regardless of which specific product solves it, which means it opens up your thinking about positioning and messaging instead of locking you into feature comparisons.

From Jobs to Product Decisions

A job statement on a whiteboard is interesting. A job statement connected to your product roadmap, marketing copy, and sales pitch is useful. Here's how the translation works in practice.

Roadmap Prioritization

Every proposed feature gets filtered through one question: does this help the customer get the job done better? "Better" means faster, more reliably, more completely, with less effort, or with less anxiety. If a feature doesn't clearly connect to an underserved dimension of the job, it doesn't make the roadmap, no matter how clever the engineering team thinks it is.

This kills vanity features. The features that get built because a competitor has them, because an executive suggested them in a meeting, or because the engineering team thinks they're cool. JTBD discipline forces you to justify every investment against the actual job the customer is hiring you for.

Marketing and Positioning

When you know the job, your marketing writes itself. Instead of listing features ("our CRM has 200+ integrations, AI-powered insights, and customizable dashboards"), you lead with the struggling moment ("walking into a sales call blind because your notes are scattered across three tools?"). The feature list becomes supporting evidence for why your product does the job well. It's no longer the headline.

This applies directly to how you think about sales strategy. When your sales team understands the job, discovery calls become conversations about the customer's situation instead of product demos. "Tell me about the last time you lost a deal because of disorganized follow-ups" is a better opening than "let me show you our dashboard."

Competitive Analysis

JTBD redefines who your competitors actually are. A meal kit company's real competitor isn't just other meal kits. It's frozen pizza, takeout, skipping dinner, and the guilt-driven 9 p.m. grocery run. When you define the competition by the job instead of the product category, your strategic picture gets much wider and much more accurate.

JTBD in Action: Three Industry Examples

Intercom (customer messaging). Intercom famously adopted JTBD as their core product development framework. Instead of organizing around features (chat widget, knowledge base, email campaigns), they organized around jobs: "help me onboard new users," "help me resolve support issues quickly," "help me convert website visitors to trial users." This restructured their entire product, pricing, and marketing. Each plan corresponded to a job, not a bundle of features. Customers could immediately see which plan matched what they were trying to accomplish.

Snickers. Mars Inc. discovered through JTBD research that Snickers wasn't competing against other candy bars. It was competing against actual meals. The job: "I'm hungry and I don't have time for a real meal, but I need enough energy to get through the next two hours." This insight led to the "You're not you when you're hungry" campaign, one of the most successful repositioning efforts in consumer goods. They stopped talking about chocolate and started talking about the job: hunger that needs solving now.

Basecamp (project management). Jason Fried and the Basecamp team used JTBD to stay deliberately simple while competitors kept adding features. They identified that their core customer's job wasn't "manage complex projects with Gantt charts and resource allocation." The job was "keep my small team on the same page without spending all day managing the tool itself." This insight justified saying no to hundreds of feature requests that would have made the product more powerful but worse at the actual job their customers hired it for.

Common Mistakes That Ruin JTBD Research

JTBD is straightforward in theory but easy to mess up in practice. Here are the mistakes that sabotage most teams.

Confusing jobs with tasks. "Send an email" is a task. "Keep my client informed so they feel confident the project is on track" is a job. Tasks are the how. Jobs are the why. If your job statement could be a line item on a to-do list, you haven't gone deep enough.

Segmenting by demographics instead of situations. Traditional marketing slices customers by age, income, and job title. JTBD slices by situation. A 22-year-old recent graduate and a 55-year-old executive might hire the same productivity app for the exact same job ("get control of a chaotic schedule during a life transition"). Situations predict purchasing behavior. Demographics predict almost nothing about what job needs doing.

Making jobs too broad. "I want to be happy" is not a job. "I want to be productive" is barely a job. The narrower your job definition, the more actionable your product decisions become. "When I have 30 minutes between meetings and a pile of unprocessed emails, I want to triage my inbox by priority, so I can respond to the urgent ones and batch the rest for later" is a job you can build for.

Ignoring the emotional and social dimensions. Teams with engineering-heavy cultures tend to focus exclusively on the functional job and treat the emotional and social jobs as soft, unmeasurable fluff. This is how you end up with products that are technically excellent and commercially disappointing. The emotional job (how does the customer want to feel?) and the social job (how does the customer want to be perceived?) are just as real and just as measurable through Switch Interviews as the functional job.

Treating JTBD as a one-time exercise. Jobs evolve. The job that drove someone to hire your product two years ago may have shifted as new competitors appeared and circumstances changed. Smart teams revisit their core job statements quarterly and run fresh Switch Interviews whenever they see unexpected churn patterns.

Putting This to Work

You don't need to be running a product company to use JTBD. Freelancers can use it to understand why clients actually hire them (hint: it's rarely the deliverable itself). Job seekers can use it to understand the hiring manager's job and position themselves as the best candidate. Marketers can rewrite every piece of copy to lead with the struggling moment instead of the feature list. Anyone making something for other people benefits from asking "what job is this getting hired to do?"

Start with one question this week: what is the real job your customers (or your boss, or your clients) are hiring you to do? Not the task. Not the deliverable. The underlying progress they're trying to make in their situation. Sit with that question. Talk to five people who recently "hired" or "fired" you. Map their struggling moments. Write the job statement.

The best products don't win because they have more features, better design, or bigger marketing budgets. They win because they understood the job better than everyone else and removed every point of friction between the customer and the outcome they were actually after. That's the entire framework. Everything else is execution detail.