Jobs to Be Done (JTBD) is a way of defining your market by the progress a customer is trying to make in a specific circumstance, not by their age, job title, or the features they click. A founder uses JTBD to reframe "who is my customer" into "what job are they hiring my product to do," which changes everything from positioning to the roadmap. Clayton Christensen built the theory at Harvard, the Christensen Institute maintains it, and Strategyn turned it into a repeatable process. That matters because HBS online reports that roughly 75% to 85% of new products fail financially largely because they were built for a demographic instead of a job.
Key Takeaways
JTBD works because it replaces demographic guessing with a measurable, solution-agnostic description of the progress customers are trying to make.
| Point | Details |
|---|---|
| Define the job first | Write one solution-free sentence naming the progress the customer wants, before discussing features. |
| Map the job steps | A job map exposes the specific step where people struggle, which is usually your best opportunity. |
| Prioritize by outcome gaps | Focus on desired outcomes rated highly important but poorly satisfied, not on internal opinions. |
| Avoid solution-baked statements | Rewrite any job statement that names a feature, action, or category until it survives without one. |
| Use Klaritea to connect research to build | Klaritea links JTBD job statements and outcomes directly to TAM/SAM/SOM sizing and a build spec. |
Table of Contents
- What Is Jobs to Be Done, Really?
- Core JTBD Concepts Every Product Team Needs
- How Do You Apply the JTBD Method Step by Step?
- What Questions Reveal a Customer's Job?
- Job Statement and Job Story Templates You Can Reuse
- What Do JTBD Case Studies Actually Show?
- When Should You Use JTBD Instead of Other Methods?
- What Mistakes Undermine JTBD Work?
- Does JTBD Actually Improve Product Outcomes?
- Turn JTBD Research Into a Build Spec, Faster
- Sources
- FAQ
What Is Jobs to Be Done, Really?
JTBD treats the customer's situation, not their profile, as the unit you design around. Strategyn's playbook lays out the core tenets plainly: the job is the unit of analysis, jobs carry functional, social, and emotional weight, and a well-written job statement stays solution-agnostic. A 34-year-old marketing director and a 61-year-old retiree can hire the exact same product if they share the same job in a given moment. That is the opposite of how most teams build personas.
A persona asks "who are you." JTBD asks "what are you trying to get done, and what's stopping you." The difference shows up fast in practice:
- Persona-led thinking: "Our user is a busy parent aged 30 to 45" tells you almost nothing about what to build next.
- Feature-led thinking: "Users want a dashboard" describes a solution before you've confirmed the underlying need.
- Job-led thinking: "I need to reassure myself my kid got home safely without interrupting my workday" tells you exactly what to design for.
Every job also has three layers worth separating. The functional dimension is the task itself (get from A to B, track spending). The social dimension is how the person wants to be perceived while doing it (look competent in a meeting, seem like a responsible parent). The emotional dimension is how they want to feel (calm, in control, unembarrassed). The Christensen Institute treats all three as forces that shape which product actually gets "hired." For canonical write-ups on scope and definition, Jobs-to-be-done is worth bookmarking alongside Strategyn and the Christensen Institute.
Core JTBD Concepts Every Product Team Needs
Four ideas do most of the work once you move past the definition.
- The job map. A job map breaks the job into the sequence of steps a person moves through to get it done, from defining what they need to confirming it worked. Mapping those steps surfaces the exact point where people struggle, which is usually where the real opportunity sits.
- Forces of progress. People switch solutions when a push (frustration with the current way) and a pull (an appealing new option) outweigh the anxiety of change and the habit of the status quo. Christensen's forces model explains why a technically better product still loses to an inferior, familiar one.
- Desired outcomes. Strategyn's approach captures the job as dozens of specific, measurable statements ("minimize the time it takes to confirm a payment cleared") rather than vague satisfaction scores. Those outcomes are the metrics customers actually use to judge whether a solution works, and they stay stable even as technology changes.
- Solution-agnostic stability. A correctly written job doesn't mention your product, a competitor, or a feature. "Get home information quickly during a commute" hasn't changed in a hundred years, even though the tools people hire to do it have gone from newspapers to radio to smartphone apps.
Christensen and Strategyn agree on the point that matters most here: solve for the stable job, and your product stays relevant even as the "how" shifts underneath you.
How Do You Apply the JTBD Method Step by Step?
Running JTBD doesn't require a research department. It requires five deliberate steps, ideally compressed into a focused sprint.
- Define the job and the job executor. Write one solution-free sentence describing the progress someone wants to make and for whom. Skip anything that names a feature or a category.
- Map the job steps. List the sequence from "define" through "confirm," and mark where people currently improvise, get stuck, or use a workaround. Those friction points are opportunity nodes.
- Run qualitative interviews. Talk to people who recently "hired" a solution (including your own) to capture the circumstances, the forces of progress, and any workaround they built themselves.
- Translate outcomes into metrics. Turn what you heard into measurable desired-outcome statements, then run a short quantitative survey asking people to rate importance and current satisfaction for each one.
- Prioritize the gaps. Outcomes rated highly important but poorly satisfied are your best bets. Strategyn calls this an opportunity score; a simple importance-versus-satisfaction matrix works fine if you're moving fast.
For a lean two-week run: one person owns recruiting and scheduling in week one while a second drafts the discovery guide (borrow structure from a customer discovery interview playbook); both conduct 8 to 12 interviews together; a third teammate synthesizes outcomes and drafts the job map by the end of week two.
- Interviews take 45 to 60 minutes each and go faster in pairs, one asking, one taking notes.
- Aim for 8 to 12 interviews for discovery; validation surveys can run with 50 or more respondents.
- Block a half-day for synthesis immediately after interviews, while details are fresh.
Pro Tip: Record every interview and pull three verbatim quotes per session before you write a single job statement. Paraphrasing too early is how teams accidentally bake their own assumptions into the "customer's" words.
What Questions Reveal a Customer's Job?
Good JTBD interviews avoid two traps: leading with your product and asking abstract "what do you want" questions that produce wish lists instead of real behavior.
Recruit people who recently made a switch: current users of your product, people who churned in the last 90 days, and non-users actively wrestling with the job using a substitute or workaround. For early discovery, 8 to 12 interviews per segment usually surfaces the recurring patterns; validation work benefits from a larger quantitative pass afterward.
Open with the moment of struggle, not your product:
- "Walk me through the last time you needed to [job]. What triggered it?"
- "What were you using before that? What made you look for something else?"
- "What almost stopped you from switching?"
- "If this solution disappeared tomorrow, what would you do instead?"
Notice none of those mention a feature or your brand. Let the person describe their circumstance in their own words, then probe for timeline and trade-offs ("what did you give up by choosing this option?"). A structured guide like a founder's discovery interview playbook helps keep sessions consistent across interviewers, and a partner resource like OffBook's AI call coaching can sharpen how a team runs and reviews those calls.
Pro Tip: When someone mentions a workaround, spreadsheet hack, or "I just deal with it," stop and dig in. Improvised fixes are where the sharpest, most underserved outcomes hide.
Job Statement and Job Story Templates You Can Reuse
A job statement follows a simple, solution-free pattern: [verb] + [object of the verb] + [contextual clarifier]. A job story adds circumstance and desired outcome: "When [situation], I want to [motivation], so I can [expected outcome]." Strategyn's own examples follow this same discipline.
- Consumer example: "When I'm commuting and haven't eaten, I want something filling and easy to consume one-handed, so I can start my workday without being distracted by hunger." (Functional: satisfy hunger. Emotional: avoid distraction. Social: not messy in public.)
- B2B example: "When I'm preparing for a board meeting, I want to pull accurate revenue numbers without waiting on finance, so I can walk in fully prepared." (Functional: get accurate data fast. Emotional: confidence. Social: look competent in front of the board.)
- SaaS example: "When a customer complains publicly, I want to resolve it before it escalates, so I can protect the team's reputation." (Functional: resolve fast. Emotional: reduce stress. Social: protect the brand.)
Keep job statements broad enough to survive a technology shift but narrow enough to guide a roadmap. "Manage my life better" is too broad; "confirm a payment cleared without calling support" is usable. Before you act on one, check it against three questions: does it name a solution, is it measurable, and would it still make sense in ten years?
What Do JTBD Case Studies Actually Show?
The Christensen Institute's milkshake study is the field's founding example for a reason: a fast-food chain wanted to sell more milkshakes, so researchers watched who bought them and when. Roughly half were sold before 8 a.m. to solo commuters who wanted something filling, one-handed, and slow enough to last a long drive. That's not a demographic insight; it's a job (make a boring commute less boring while eating something that won't spill) that competed against bananas and bagels, not other milkshakes.
- A software company that redefined its job as "help me feel confident I won't lose data" instead of "provide cloud storage" shifted its whole roadmap toward recovery and version history features.
- A product that bundled several disconnected steps of a job map into one flow, rather than optimizing any single step, saw adoption climb because customers no longer had to stitch tools together themselves.
- Strategyn reports that its Outcome-Driven Innovation clients see an 86% success rate on product outcomes, against much lower industry norms for new launches.
What changes after a team finds the real job is rarely a single feature. It's usually a repositioning of what the product is for, sometimes a full business-model pivot.
When Should You Use JTBD Instead of Other Methods?
JTBD earns its place when you're defining a market, hunting for underserved outcomes, or deciding which features actually complete the whole job rather than just one step of it. It's the right tool before you've committed to a solution.
- Choosing what to build next: JTBD, because it prioritizes by outcome gaps, not opinions.
- Fixing a confusing UI on an existing flow: rapid prototyping and usability testing beat JTBD here.
- Improving a known conversion step: A/B testing the existing flow is faster and cheaper.
- Deciding brand tone and messaging: positioning work informed by JTBD outcomes, not JTBD interviews alone.
- Testing a very early idea cheaply: pair JTBD findings with a lean experiment approach before building anything.
What Mistakes Undermine JTBD Work?
The most common failure is writing a job statement that secretly names a solution ("use an app to track expenses" is an action, not a job). Fix it by asking "why does this action matter" until you reach a circumstance that doesn't reference any tool.
- Confusing an action for a job: rewrite until the statement survives without naming a feature or category.
- Treating emotional jobs as the whole job: emotional and social dimensions matter, but they sit on top of a functional core; don't let "feel confident" replace "get accurate numbers."
- Over-broad statements: if a job statement could apply to five unrelated products, narrow the context until it's specific and testable.
- Skipping triangulation: cross-check interview claims against actual behavior data or support tickets before committing a roadmap to them.
Run every job statement through a quick audit before you act on it: does it name a solution, is it measurable, and does behavioral data back up what people said in the interview?
Does JTBD Actually Improve Product Outcomes?
The case for JTBD rests on a gap that shows up repeatedly in innovation research. HBS online cites that 75% to 85% of new products fail financially, largely because they targeted a demographic instead of a job. A summary of executive sentiment cited via HBS Working Knowledge found the vast majority of leaders call innovation critical, yet most are dissatisfied with their own results, which is exactly the gap JTBD claims to close.
- Strategyn reports an 86% success rate for its Outcome-Driven Innovation engagements, far above typical new-product outcomes.
- The Christensen Institute frames JTBD as a lens on circumstance, not demographics, which is why it transfers across industries as different as fast food and enterprise software.
- HBS Executive Education runs Disruptive Strategy programs built around the same question-driven approach.
A note on preventing wasted builds
I've watched too many founders build for months before realizing they never defined the job clearly. When Klaritea turns a one-line idea into a connected model, mapping the job, desired outcomes, and build spec early is exactly how we try to stop that waste before it starts.
Turn JTBD Research Into a Build Spec, Faster
Once you've run interviews and drafted job statements, the hard part is connecting them to actual product decisions: which outcomes map to which features, and how big is the market for the job you just found. Klaritea takes that raw research and structures it into a connected model, linking the job you defined to TAM/SAM/SOM sizing, competitor gaps, and a feature list without you rebuilding the logic in five different documents.
A typical workflow looks like this: you capture a takeaway from a customer interview, draft it into a solution-free job statement inside Klaritea, and the platform generates a clarity scorecard showing how well your current plan actually serves that job. From there it's a short step to a build spec your dev team (or you, vibe coding solo) can act on with confidence instead of guesswork. If you want to see how the connected model handles JTBD-style inputs specifically, the Klaritea 'why' page walks through the full structure, and it's worth ten minutes before you write your first line of code.
Sources
For deeper study beyond this guide, the Christensen Institute covers the theory's origins and forces-of-progress model, Strategyn documents the Outcome-Driven Innovation process, and HBS online offers accessible real-world examples. Jobs-to-Be-Done.com is a useful companion for community discussion and additional case material.
- The Jobs to Be Done Framework & Real-World Examples
- Jobs to Be Done Theory - Christensen Institute
- Jobs-to-be-Done (JTBD): The Original Framework by Tony Ulwick
FAQ
What are some real examples of jobs to be done?
Classic examples include "make a boring commute more bearable" (the milkshake study), "feel confident I won't lose important data" (cloud storage), and "reassure myself my child got home safely" (family locator apps). Each names a circumstance and outcome, never a product category.
What is the JTBD method in a product context?
The JTBD method is a five-step process: define the job, map its steps, interview people who recently hired a solution, translate what you learn into measurable desired outcomes, and prioritize the outcomes with the biggest gap between importance and satisfaction.
How is JTBD different from user stories or personas?
Personas and user stories describe who a user is or what feature they need; JTBD describes the underlying progress they're trying to make regardless of who they are, which keeps the insight stable even as your product or user base changes.
When should I use JTBD instead of design thinking or A/B testing?
Use JTBD when defining a market or deciding what to build next; use rapid prototyping or A/B testing once you already have a specific flow to refine, since those methods work on existing solutions rather than open-ended market definition.
How do I validate a job to be done after launch?
Track whether the desired outcomes you identified show measurable improvement (faster task completion, fewer workarounds, higher satisfaction on the specific outcome metric), and pair that with a tool like an idea validator to check demand signals before scaling the build.