Jobs to Be Done: How to Find What Customers Really Want

You ship a feature customers asked for, and usage barely moves. Or you scrap a project you were sure people wanted, only to watch a competitor’s version take off. Both usually trace back to the same gap: you knew what customers said, not what they were actually trying to get done.

Jobs to be done (JTBD) is a framework for finding that gap. Instead of asking who your customer is, it asks what progress they’re trying to make in a specific moment, and what they’re currently hiring, a product, a workaround, a habit, to make that progress happen. Get the job right and the feature, the messaging, and the pricing tend to follow. Get it wrong and you can nail every survey question and still miss the market.

What Is Jobs to Be Done?

Jobs to be done is the idea that people don’t buy products. They hire them to make progress in a specific situation, then fire them the moment something does the job better.

A “job” here is the progress someone is trying to make, plus the circumstance that triggered the need. Sleeping through a hot night without waking up sore is the job; a mattress is just this decade’s way of getting it done. That framing holds up even as products change: mattress technology has shifted for decades, and the job of “help me sleep well tonight” hasn’t moved at all.

Christensen and his co-authors describe every job as having three dimensions, laid out in the 2016 Harvard Business Review cover story Know Your Customers’ Jobs to Be Done: a functional dimension (the practical task, like backing up files), an emotional dimension (how the person wants to feel while doing it, like less anxious about losing work), and a social dimension (how they want to be seen by others, like careful or organized). A product that nails the functional job while ignoring the emotional or social pain point behind it is a common reason otherwise solid features underperform.

Where Did the Jobs to Be Done Framework Come From?

The modern jobs to be done framework traces to a 2005 consulting project between Harvard Business School professor Clayton Christensen and a fast-food chain trying to sell more milkshakes, a case that’s still cited constantly in consumer goods research because the insight had nothing to do with taste. His team found something odd buried in the sales data: about half of all milkshakes were sold before 8:30 a.m., to solo commuters who bought nothing else with them.

Interviews with those commuters showed the milkshake wasn’t competing against other milkshake flavors. It was competing against bananas, bagels, and boredom, and it won because it was thick enough to last a long commute and easy to drink one-handed while driving. Christensen’s team, including consultant Bob Moesta, a co-creator of the method who had already spent years developing a similar interviewing approach, used that finding to argue people “hire” products to complete a job, not to belong to a product category. The real subject of a JTBD interview is customer motivation, not customer opinion.

Christensen gets most of the credit for popularizing the theory. Tony Ulwick had already spent the 1990s formalizing a related, more quantitative process called Outcome-Driven Innovation. When people say “JTBD” today, they usually mean the qualitative, interview-driven branch that grew out of Christensen and Moesta’s milkshake research.

Jobs to Be Done vs. Personas: What’s the Difference?

Personas and jobs to be done are two of the core building blocks in audience research, and most teams need both rather than picking one over the other. A user persona describes who buys: age, role, goals, a name and a face. A job to be done describes why they buy in a specific moment, regardless of who they are.

Dimension	Jobs to Be Done	Personas
Unit of analysis	The situation and the progress sought	The person and their traits
Stays stable when…	The product or technology changes	The demographics or job titles change
Core question	“What are you trying to get done?”	“Who are you?”
Typical output	A job statement or job story	A named profile with goals and context
Risk if used alone	Progress with no picture of who’s underserved	A believable character solving the wrong problem

Two people with completely different job titles can share the same job to be done. The same person can carry different jobs on different days, depending on what’s pushing them and what they’re anxious about. If you’re building both a persona and a target customer profile, the job is what tells you which persona to prioritize first.

What Does a Job to Be Done Look Like?

A job to be done is easiest to see in the situation it’s hired for, not in the product itself. A few JTBD examples make the pattern concrete.

Situation	What gets hired	What it’s competing against
Long, boring commute, no time to stop	A thick milkshake, hired to fight hunger and boredom one-handed	Bananas, bagels, candy bars, silence
Tight deadline, unfamiliar reporting tool	A familiar spreadsheet, hired to build a “good enough” model fast	Learning a new BI tool, asking an analyst, guessing
First week at a new job, afraid to look lost	An onboarding checklist, hired to avoid asking an obvious question	Asking a coworker directly, re-reading old messages, winging it
Cart open, price higher than expected, hesitating to buy	A buy-now-pay-later option, hired to reduce the anxiety of one big charge	Closing the tab, asking a friend, waiting for a sale

None of these situations name a product category first. That’s the point: the milkshake competed with bananas, not other milkshakes, and the spreadsheet competed with a person’s time and confidence, not other reporting software. The same pattern shows up constantly in ecommerce research, where the real competitor at checkout is rarely the store down the street. It’s hesitation. Writing down the situation before the solution is what keeps a job to be done from turning into a feature list in disguise.

How Do You Do Jobs to Be Done Research?

Jobs to be done research is fundamentally a qualitative research method: it works by interviewing people who recently switched, meaning they recently started, stopped, or changed how they handle a specific situation, then reconstructing the story that led to that switch.

The core steps:

• Find recent switchers. People who bought, canceled, or changed a habit in the last 30 to 90 days remember the decision clearly. People who’ve used something for years usually can’t reconstruct why they started.
• Interview along a timeline. Walk from the first moment they thought “there has to be a better way” through passively noticing options, actively looking, deciding, and first use.
• Listen for forces, not features. The goal is what pushed them to look, what pulled them toward the new thing, and what almost stopped them.
• Write the job as a job story (below), one per interview.
• Cluster the stories. A single interview is an anecdote. The pattern across 10 to 12 interviews, a sample size well below what a quantitative survey would need, usually shows up once several stories share the same push and the same anxiety.

This is the same instinct behind a broader customer discovery process: talk to people who recently made the decision you care about, not people asked to predict a hypothetical one.

What Questions Do You Ask in a JTBD Interview?

A jobs to be done interview, often called a switch interview, works backward from the moment someone started using your product (or a competitor’s) to everything that led up to it.

Questions that tend to surface the real job:

• “Take me back to the first time you thought about needing something like this. What was happening?”
• “What were you using before? What made that stop being good enough?”
• “Did you look at other options? What ruled them out?”
• “What almost stopped you from switching?”
• “The first time you used it, what surprised you?”

Notice none of these ask “what features do you want” or “how would you rate this on a scale of 1 to 5.” Feature requests describe a solution someone has already imagined, and hypothetical “would you” questions run into a well-documented bias: people are unreliable narrators of what they might do, but fairly reliable narrators of what they actually did. A switch interview stays in the past tense long enough for the actual job to surface on its own.

That’s close to the actual script we used for the speed-vs-accuracy study below: recent experience, current process, switch trigger, previous method, push factor, decision criteria, then two pointed questions on speed and accuracy specifically, since that was the fork we needed the interview to resolve.

What Is the JTBD Template (the Job Story)?

The job story is the standard template for writing down a job to be done, and it follows one line: When [situation], I want to [motivation], so I can [expected outcome].

Job stories trace to a 2013 Intercom blog post by product lead Paul Adams; writer Alan Klement helped popularize the exact three-part template and gave it the name “job story.” The format was built as a direct alternative to the traditional user story (“As a user, I want X, so that Y”), which names a persona and often a solution up front. A job story names a situation and stays solution-agnostic.

An example: “When I’m closing out my workday and a teammate is blocked on something only I can unblock, I want to send a quick update without scheduling a call, so I can leave on time and they can keep moving by morning.” Notice there’s no job title, no persona, and no mention of Slack, email, or any specific tool. That’s what keeps a job story useful past the moment you wrote it.

What Are the Four Forces That Decide Whether Someone Switches?

Whether someone actually switches from an old solution to a new one comes down to the four forces of progress, a model developed by Bob Moesta and Chris Spiek to make JTBD interviews actionable. It’s a model of one person’s purchase decision, not of company-versus-company positioning.

Two forces drive the switch forward: the push of the current situation getting bad enough to act on, and the pull of the new option looking genuinely better. Two forces hold people back: the anxiety of the new option, worries about cost, setup, or looking foolish if it doesn’t work, and the habit of the present, the comfort of a routine that already works well enough.

A switch happens when push plus pull outweighs anxiety plus habit. Teams that only work on pull, by adding features and polishing messaging, often miss that anxiety and habit are usually the bigger blockers. A cheaper onboarding flow or a no-risk trial can move the needle more than another feature.

What’s the Cheapest or Free Way to Do JTBD Research?

The cheapest version costs nothing but your own time: book 10 to 12 unmoderated calls with recent switchers yourself, using the questions above, and take notes by hand. The only real cost is the day or two it takes to schedule and run them.

Paid options scale up from there. Recruiting agencies and participant panels typically charge $50 to $150 in incentives per consumer participant, which usually pushes the fully loaded cost of a single interview to somewhere between $150 and $500 once platform and screening fees are added. Full-service research agencies, the kind that handle recruiting, moderation, and a formal report, commonly run from a few thousand dollars to well over $15,000 per study depending on scope. Synthetic interview tools sit at the far low end: Articos runs a JTBD-style synthetic interview for roughly $8 to $20 per study.

Free works best when you have the calendar time and a small enough list of candidates that scheduling them yourself is realistic. Once you need more than about 10 to 12 interviews, or the people you need are hard to reach, the time cost usually outweighs whatever cash you saved.

Should You Combine Synthetic and Human Research, or Pick One?

Combine them. For most teams, the practical answer is synthetic first, human to confirm, not synthetic or human.

Synthetic interviews are cheap enough to run against 20 or 30 different job hypotheses in an afternoon, which is exactly what a real interview schedule can’t do. That volume is useful for narrowing a long list of guesses down to the two or three jobs that actually show up as a pattern. Real interviews are still the only way to hear an anxiety or a habit nobody on the team predicted, the kind of detail a synthetic persona can’t invent because it hasn’t actually lived it.

If the decision ahead of you is reversible and cheap, like a first pass at messaging or an early concept, synthetic research alone is often enough. If it’s expensive or hard to undo, like a pricing change or a new product line, budget for real interviews too. When you do need real participants and don’t already have a list of recent switchers to call, a dedicated recruiting platform is the standard route; see how that approach compares to an AI-native one in the Articos vs. User Interviews breakdown.

How Do You Find Customer Jobs Without Weeks of Recruiting?

The hardest part of jobs to be done research is finding 10 to 12 people who recently switched and getting time on their calendar, which routinely stretches a JTBD study into a 4 to 6 week project before a single insight comes back.

Synthetic interviews shorten that step without replacing the method. Synthetic user research works by running a full JTBD-style interview, situation, push, pull, anxiety, habit, against AI personas built from your actual target market. Articos returns a synthesized report in under 30 minutes instead of weeks of scheduling. In Articos’s own validation testing, a self-reported figure rather than an independently audited benchmark, its personas showed 86% recall accuracy against expert-led research across 46 studies. That’s useful for drafting job hypotheses fast and deciding which ones are worth chasing.

Here’s what that looked like on a real question:

We ran this exact method on ourselves: 12 synthetic switch interviews, four startup founders, four product managers, four agency owners, to settle whether this article’s own homepage should lead with speed (“research in 30 minutes”) or with accuracy (“86% recall vs. expert human research”).

The finding wasn’t a tiebreaker between the two. It was a job with two forces pulling in the same direction. Speed is what gets a tool considered when a decision window is closing, sprint planning, a launch date, a client deadline. Defensibility is what gets it bought and used again; participants across all three roles said fast alone wasn’t enough, they needed an output they could share, get challenged on, and still stand behind.

Written as a job story:

When a decision window is closing and I can’t afford to be wrong in front of my team or a client, I want research I can get fast and still defend under scrutiny, so I can move quickly without getting picked apart later.

It has a real limit worth naming: a synthetic persona hasn’t lived through an actual anxiety or an actual habit, it’s modeling one. For a decision with real budget or roadmap risk attached, the strongest approach is to use synthetic interviews to surface and rank the likely jobs, then confirm the top two or three with real user interviews with people who genuinely switched recently. Synthetic research narrows the search; it doesn’t replace the confirmation.

How to Choose Your Next Step

If you have the time and budget, run 10 to 12 real switch interviews before you write a single job story. If you’re earlier, resource-constrained, or need to validate a startup idea before committing engineering time, draft your job hypotheses fast with synthetic interviews, then spend your limited real-interview budget confirming the two or three jobs that showed up most often.

Once you’ve named the job, two things tend to follow it. The situation and outcome you captured are usually the most honest raw material for a value proposition, worth running through a message testing pass before any of it goes on a landing page. In our own speed-vs-accuracy study above, that’s exactly where the job story earned its keep: scored against four separate messaging goals, speed and defensibility didn’t trade off evenly.

Speed alone scored well for grabbing attention and poorly for closing a purchase; defensibility did the opposite. The job story is what explained why: attention and purchase are two different moments in the same decision, not two ways of describing the same one.

Once you’ve named the job, two things tend to follow it. The situation and outcome you captured are usually the most honest raw material for a value proposition, worth running through a message testing pass before any of it goes on a landing page. And if you’re choosing between two or three ways to solve that job, a concept test will tell you which one actually resolves it before you build any of them. Getting the job right earlier is one of the more reliable paths to product-market fit: the situation and the outcome are what will still be true next year. The feature is just this year’s answer to it.