Jobs to Be Done: What It Actually Means and How to Use It
Jobs to Be Done is one of those frameworks that everyone in product has heard of and almost nobody uses correctly. Most summaries you'll find open with Clayton Christensen's milkshake story, explain that customers "hire" products to do jobs, and stop there. It's a clean metaphor. It also leaves out the part that actually changes how you work.
The useful version of JTBD is not a metaphor. It's a specific way of restructuring customer conversations, a different unit of analysis for thinking about competition, and a sharper lens for deciding what to build next. Internalizing it is less about understanding a theory and more about learning to ask a different question.
Want to put your idea through a JTBD-aware discovery? Run it through Scoutr →
The Core Idea, Without the Milkshake
The premise is straightforward: when someone uses a product, they're not expressing loyalty to the product category. They're trying to get a specific job done. The product is the tool they happened to hire for that job. If something else does the job better, they'll switch.
That sounds obvious. What makes JTBD useful is the operational implication: you should stop thinking about your customer in terms of demographics, personas, or product categories, and start thinking about them in terms of the job they're trying to get done in the moment they decide to use something.
The same person will hire completely different products for different jobs. A busy parent hires a coffee shop at 7am ("help me wake up quickly on my way to work") and hires the same coffee shop at 3pm ("give me an excuse to take a break from my desk for fifteen minutes"). Same customer. Same location. Different jobs. The features that matter are different in each case.
This reframing is why JTBD is hard to use well. It asks you to abandon categories that feel natural and replace them with something less tangible — but more predictive.
Why the Milkshake Story Is a Trap
The story, briefly: McDonald's studied who was buying milkshakes in the morning and found they weren't families or teenagers. They were commuters, often men, buying shakes as breakfast during their drive to work. The shake wasn't competing with other desserts. It was competing with bananas, bagels, and donuts — things you could eat one-handed in traffic. Once McDonald's understood that job, they could make the shake thicker (takes longer to drink, fills the whole commute) and sold more.
The story is memorable. But it's also slightly misleading about how JTBD actually helps, because it implies you just need better observational research. In practice, JTBD is not primarily about observing usage patterns. It's about asking better questions in interviews.
The milkshake insight could have come from watching drive-through behavior. But most JTBD insights come from asking someone why they bought what they bought, and what they would have bought if the thing they bought didn't exist. Those two questions do more work than any observational study.
The Three Dimensions of a Job
A useful job statement has three dimensions, and none of them should mention your product category.
Functional dimension. What practical thing are they trying to accomplish? "Get through the morning commute without being hungry." "Track project progress without sending an update email." "Know whether this candidate is technically competent."
Emotional dimension. How do they want to feel? Or what feeling do they want to avoid? "Feel in control of my schedule." "Avoid looking foolish in front of my team." "Feel like I made a thoughtful decision."
Social dimension. How do they want to be perceived? This matters more than people admit. "Be seen as someone who's organized." "Be seen as someone who did due diligence." "Not be seen as the person who slowed down the project."
Most products focus exclusively on the functional dimension. The ones that win — and that users stay loyal to — address all three, often without the user consciously realizing it. The social dimension in particular is where many B2B purchases actually live: the buyer's fear of being blamed if the tool doesn't work is often the dominant force in the decision.
How JTBD Changes Customer Interviews
The single most useful thing JTBD does is change the questions you ask in customer research.
Most interview frameworks start with "who are you?" — demographics, role, team size, context. JTBD starts with "what were you trying to do?" The first question collects attributes. The second collects a specific situation, which is where all the useful information lives.
Compare two versions of the same interview:
Persona-based: "You're a marketing manager at a mid-sized company. Tell me about your daily workflow with analytics tools."
JTBD-based: "Walk me through the last time you tried to answer a specific question using an analytics tool. What were you actually trying to figure out? What did you do first? Where did you get stuck?"
The first version produces a tidy summary that could apply to any marketing manager. The second version produces a specific narrative about one moment, which is where the design decisions live. What they did first tells you about their mental model. Where they got stuck tells you about the gap in current tools. Why they started looking tells you about the trigger event that made them willing to pay.
This is why JTBD pairs naturally with the Mom Test — both frameworks push you away from generic questions and toward specific, past-tense, situation-based questions.
How to Write a Job Statement
A clean job statement follows this shape: When [situation], I want to [motivation], so I can [expected outcome].
Bad: "I want to be more productive."
Better: "When I'm starting a new project and don't know where to begin, I want to see how other teams approached similar projects, so I can avoid obvious mistakes and feel confident about my first decisions."
The second version is a real job. It has a trigger (starting a new project), a motivation (seeing how others approached it), and an outcome that includes both functional (avoiding mistakes) and emotional (feeling confident) dimensions.
When you write job statements for your target user, the statements should be specific enough that you could identify the moment the job becomes active. "I want to be productive" has no moment. "When I'm starting a new project and feel paralyzed by a blank page" has a moment you can target with a product, a message, a notification.
If your job statements are vague, your product will be vague. If they're specific, your product has a clear reason to exist.
The Competition Question JTBD Answers
Asking "who are our competitors?" in a product category sense almost always misleads you. JTBD reframes competition: your real competitors are whatever the user would do instead if your product didn't exist. That might be a competitor in your category. It might also be a spreadsheet. A Slack message to a coworker. Doing nothing. Paying someone to do it manually.
Figma's competitor isn't just Sketch. It's PowerPoint slides pretending to be mockups, screenshots annotated in Preview, and designers sending PDFs back and forth over email. When you understand that, you understand why Figma's product roadmap looks the way it does — it's designed to replace those workarounds, not just to beat Sketch on features.
This is also why "nobody is doing this" is rarely a green flag for founders. If no product exists for a job, users are almost certainly doing the job with something — a workaround, a manual process, a combination of tools. That workaround is your real competitor. Understanding it well enough to beat it is usually the actual work. This is the same pattern as demand signals from workarounds: the workaround is the market telling you what the job looks like from the inside.
When JTBD Doesn't Work
JTBD is great for products that solve identifiable, discrete jobs. It works less well for products where the job is ambient, low-intent, or primarily aesthetic.
Entertainment products are hardest. The job "entertain me for twenty minutes" is so broad that JTBD doesn't help you make design decisions the way it would for a productivity tool. Similarly, products driven by taste, identity, or community — fashion, certain consumer brands, social networks — have jobs that are real but hard to pin down in a statement.
For most B2B software, productivity tools, utilities, and services, JTBD is as useful a framework as exists. For consumer products in categories driven by emotion and identity, it's a useful supplement, not a primary lens.
Using JTBD Alongside the Rest of Your Discovery Work
JTBD is a sharp tool for one part of discovery: understanding what the user is actually trying to accomplish. It's not a complete framework. You still need to validate that the job is common, that it's painful enough that people would pay to solve it, and that your specific solution is better than the workarounds they're currently using.
A structured validation process runs JTBD as one of several lenses. You identify the job (JTBD), confirm the workaround (demand signals), confirm willingness to pay (willingness to pay), and assess whether you can reach enough users at a price that makes sense. The six-question discovery framework weaves those together.
What JTBD specifically contributes is that you stop building for an abstract persona and start building for a moment in someone's day when they need something to happen. That's a much more useful design target than "our target user is a marketing manager at a mid-sized company."
If you want a structured way to surface the job your idea is being hired for — including JTBD mapping and the competitive workarounds already serving that job — Scoutr runs that as part of its discovery analysis. The output is a clear job statement, the current alternatives users hire for that job, and a read on whether your solution represents a meaningful upgrade. It won't replace the interviews. But it gives you a starting map before you book them.