Jobs-to-be-Done Framework: A Practical Guide for PMs
Most products fail not because they are badly built but because they are built for the wrong reasons. The jobs-to-be-done framework is a way of understanding why people buy and use products that goes deeper than demographics, personas, or feature lists. Applied well, it reframes information a team already had rather than requiring new research, and it consistently produces better product decisions because it starts from the right question: what job is the customer hiring this product to do?
This guide explains the jobs-to-be-done framework in practical terms — what it is, how it works, how to run JTBD interviews, and how to apply the insights to a roadmap.
What Is the Jobs-to-be-Done Framework?
The jobs-to-be-done framework is a theory of customer motivation developed by Clayton Christensen, Tony Ulwick, and Bob Moesta, among others. Its central premise is that customers do not buy products — they hire products to do a job. When a person buys a product, they are making a hire: bringing in something new to make progress on a goal they have. Christensen laid out the theory at book length in Competing Against Luck, co-authored with Taddy Hall, Karen Dillon, and David Duncan.
The famous milkshake example, associated with Christensen, illustrates this well. A fast food chain wanted to improve milkshake sales. The standard approach would be to survey customers about flavors and sweetness. The jobs-to-be-done framework led the researchers to ask a different question: when and why are people buying milkshakes? They discovered that a significant portion of milkshake purchases were by commuters in the morning who were hiring the milkshake to do a specific job: provide something to do with their hands and mouth during a long, boring commute that would fill them up until lunch without making a mess. This insight suggested entirely different product changes than a flavor preference survey would have revealed. As Christensen and his co-authors put it in their Harvard Business Review piece on the theory, most innovation efforts fail not from a lack of good ideas but from a lack of clarity about which job a product is actually being hired to do.
The jobs-to-be-done framework has three dimensions: functional jobs (the practical task the customer wants to accomplish), emotional jobs (how the customer wants to feel during and after the experience), and social jobs (how the customer wants to be perceived by others). A complete JTBD analysis considers all three dimensions.
How to Apply Jobs-to-be-Done as a Product Manager
The jobs-to-be-done framework changes how you approach product decisions at every stage.
In discovery: Instead of asking users what features they want, ask about the situations in which they hired your product (or a competitor). When did the problem first appear? What were you doing when you realized you needed a solution? What had you tried before? What made you choose this product over alternatives? These questions surface the job and the context, which is far more useful than a feature wishlist.
In prioritization: The jobs-to-be-done framework helps you evaluate features by asking: Which job does this feature help the customer do better? Features that serve well-defined, important jobs rank higher than features that add capability with no clear job attached. This connects directly to how you score work in a framework like RICE — a feature tied to a clearly understood job is much easier to score with real confidence than one justified by “customers asked for it.”
In positioning: The jobs-to-be-done framework reveals who your real competition is. For the milkshake buyer, the competition is not other milkshakes — it is bananas, granola bars, and bagels. Understanding the full competitive set from the customer’s perspective produces better positioning and clearer differentiation.
In roadmap communication: The JTBD framework gives you a language for explaining why you are building what you are building that resonates across all stakeholders. “We are building this because it helps customers do X job better” is a clearer and more compelling rationale than “customers asked for this” or “our competitor has it.”
Consider a project management SaaS company where the team was split on whether to build a resource-planning module: half the team argued from feature requests, half argued from fear of a competitor’s roadmap, and neither argument moved the other side. Six JTBD interviews with recent power users found something neither side had said explicitly: teams weren’t asking for resource planning because they needed a planning tool — they were hiring it to have a defensible answer ready before a Monday leadership meeting, on a weekly cadence tied to a specific recurring anxiety. That reframe changed the design brief from “build a planning module” to “make the weekly leadership update take five minutes instead of ninety,” producing a much narrower, faster-to-ship first version than either original camp had proposed.
How to Run JTBD Interviews That Surface Real Insights
JTBD interviews are fundamentally different from standard user research interviews. The goal is not to understand the user’s opinions or preferences. The goal is to reconstruct the specific moment when the user made the decision to hire a new product or fire an old one.
The JTBD interview technique, developed largely by Bob Moesta, focuses on a specific purchase or switching event. It walks the user backwards from the moment of purchase through the situation that created the need, the search process, the alternatives considered, and the factors that drove the final decision.
The core JTBD interview questions:
“Walk me through the day you decided to [buy/sign up/start using] this product.” This opening question establishes the specific event and begins the narrative.
“What was happening in your life at that time that made this the right moment?” This question reveals the context — the trigger or situation that made the job urgent.
“What had you tried before this?” This reveals the competitive set from the customer’s perspective and what those alternatives failed to do.
“What made you choose this product over the alternatives?” This is where the real job-to-be-done emerges — the specific progress the customer was trying to make that this product uniquely addressed.
“Were there moments when you almost did not go through with it?” This surfaces the anxieties and switching costs that your product had to overcome to get hired.
Interview principles for JTBD: Focus on what people did, not what they think. Reconstruct specific events, not general opinions. Listen for emotional language — words like “frustrated,” “embarrassed,” “finally,” and “relieved” signal important dimensions of the job. Interview people within 90 days of purchase or first use while the experience is fresh.
Where the Jobs-to-be-Done Framework Goes Wrong in Practice
The framework is simple to explain and easy to apply badly. A few patterns show up consistently.
Writing job statements from a desk, not from interviews. A job statement is a hypothesis to be tested against real switching moments, not a creative-writing exercise a team does in a conference room. Teams sometimes produce polished-sounding JTBD statements that are really just personas with different formatting, because nobody actually interviewed anyone before writing them.
Confusing the job with the solution. “Job: use a project management tool” is not a job — it’s a solution category wearing a job’s clothing. The actual job sits one level up: what progress is the person trying to make that a project management tool happens to be one way of achieving? Skipping this distinction is the single most common mistake teams make when they’re new to JTBD.
Treating one interview as the whole picture. A single vivid interview story is memorable, and memorable is dangerous — teams anchor on the first compelling narrative they hear and stop looking for disconfirming cases. Conventional JTBD advocacy sometimes undersells this risk; in practice, five to eight interviews before drawing conclusions is a reasonable minimum, not an inconvenience to skip past.
Ignoring the forces holding people back. JTBD theory (particularly Moesta’s version) emphasizes anxiety and habit as forces working against a switch, not just the pull of a new solution. Teams that only map the attractive forces and skip the friction end up building something people admire but never actually adopt, because nobody addressed what was keeping them stuck with their old approach. Intercom’s own writing on Job Stories makes a similar point about designing directly against causality and anxiety rather than just the attractive pull of a new feature.
Jobs-to-be-Done vs User Stories: Key Differences
| User Story | JTBD Statement | |
|---|---|---|
| Level | Feature / task | Underlying motivation |
| Format | “As a [role], I want [task] so [benefit]” | “When [situation], I want to [motivation], so I [desired outcome]” |
| Used for | Sprint planning, engineering communication | Strategy, discovery, positioning |
| Stability over time | Changes as features change | Stays stable for years |
Product teams that already use user stories often ask how the jobs-to-be-done framework differs. They are related but operate at different levels of abstraction.
A user story describes a specific task: “As a project manager, I want to see all overdue tasks so I can follow up with team members.” It is useful for engineering communication and sprint planning.
A JTBD statement describes the underlying motivation: “When I am managing a team that is behind schedule, I want to quickly identify what is blocking progress and communicate urgency to the right people, so I feel in control and confident that I can deliver.” This captures the functional, emotional, and social dimensions of why the project manager cares about overdue tasks.
The JTBD framework informs product strategy and discovery. User stories communicate requirements for execution. Both are valuable; they operate at different levels. The jobs-to-be-done framework should sit above user stories in product thinking — jobs define what outcomes matter, and user stories define how specific features deliver on those outcomes.
For connecting JTBD to your discovery practice, see our guides on how to run a product discovery sprint and what is continuous discovery.
Jobs-to-be-Done Examples From Real Products
Understanding the jobs-to-be-done framework is easier with concrete examples.
Slack’s job: When teams working across locations and time zones need to coordinate work without email chaos, they hire Slack to make communication feel immediate and organized, so they feel productive and connected to their team.
Headspace’s job: When professionals feel chronically anxious and scattered but cannot commit to a major lifestyle change, they hire Headspace to provide a five-minute daily practice that makes them feel like they are doing something about their mental state.
Notion’s job: When knowledge workers feel overwhelmed by tools scattered across Confluence, Google Docs, Trello, and email, they hire Notion to consolidate their thinking and work into one place, so they feel organized and in control.
In each case, the JTBD statement reveals more about why the product works and where it could fail than a feature list ever could. Slack’s real competition is not just Microsoft Teams — it is email, direct messages, and every other way teams try to coordinate. Headspace’s real competition is not just Calm — it is yoga apps, therapy, and doing nothing. Notion’s real competition is not just Confluence — it is the complex multi-tool setups that Notion promises to replace.
For connecting JTBD to user research practice, see our guide on how to write a user story. The test of whether a team actually understands a job, rather than just having a well-written statement about it, is simple: can it say what the product loses to when it doesn’t get hired? If the only competitors that come to mind are other software products in the same category, the real job hasn’t been found yet — and running the jobs-to-be-done framework properly, end to end, is usually what surfaces it.
References
- Christensen, C., Hall, T., Dillon, K., & Duncan, D.S. (2016). Competing Against Luck. HarperBusiness. hbs.edu
- Christensen, C., Hall, T., Dillon, K., & Duncan, D.S. (2016). Know Your Customers’ “Jobs to Be Done.” Harvard Business Review. hbr.org
- Ulwick, A.W. (2016). Jobs to be Done: Theory to Practice. IDEA BITE PRESS. anthonyulwick.com
- Intercom. Designing Features Using Job Stories. intercom.com
