Note to the reader:
This part of the field guide comes from our 2019 version of the UX Research Field Guide. Updated content for this chapter is coming soon!
Want to know when it's released?
Subscribe to our newsletter!
“After decades of watching great companies fail, we’ve come to the conclusion that the focus on correlation—and on knowing more and more about customers—is taking firms in the wrong direction. What they really need to hone in on is the progress that the customer is trying to make in a given circumstance—what the customer hopes to accomplish. This is what we’ve come to call the job to be done.” – Clayton M. Christensen et. al., creator of JTBD
The Jobs to Be Done theory is fraught with confusion and controversy.
It’s been called both a “gimmick” and a “scam.”
But product teams at some of the world’s most successful enterprises—including Microsoft, GitLab, and Home Depot—have incorporated Jobs to Be Done into their development process, citing the framework as a source of innovation and customer value.
After searching through numerous case studies and examples of successful applications of the Jobs to Be Done framework, we believe that it is, in fact, a legit and useful approach for UX teams—and UX research is a linchpin component of doing it right.
In this chapter, we’ll discuss:
Jobs to Be Done is a framework that represents the high-level goals customers want to accomplish that might lead them to choose (or “hire”) your product as a means to get there, as well as the functional, social, and personal context of the job. Teams use JTBD to understand the specific goals, outcomes, or “jobs” the user is trying to accomplish and develop products that help them achieve those outcomes.
For example:
Harvard Professor Clayton Christensen created the JTBD framework in 2005. In an HBR article explaining JTBD, he wrote:
When we buy a product, we essentially “hire” it to help us do a job. If it does the job well, the next time we’re confronted with the same job, we tend to hire that product again. And if it does a crummy job, we “fire” it and look for an alternative.
Hear Christensen discuss how the JTBD framework helped McDonald’s innovate on their milkshake product line in the video below.
There are some conflicting perspectives on JTBD which have caused confusion in the UX community. However, many teams have learned and applied JTBD with clarity, describing it as “one of the most innovative and effective frameworks” for achieving business goals.
A user’s “jobs to be done” are characterized by social, emotional, and functional dimensions.
To demonstrate each dimension, JTBD findings are expressed through a simple formula:
"When [Circumstance], I want to [job], so I can [need/outcome] without [pain point]."
For example, a Jobs to Be Done statement for Research Hub (a participant recruitment and panel management solution by User Interviews) might be: “When I’m recruiting participants for UX research, I want to automate screening, scheduling, and reminder messages so I can quickly move participants through the study without the enormous time-suck of doing it manually.”
Like any research deliverable, the Jobs to Be Done statement is a tool to help you communicate your research findings to stakeholders.
You may have already noticed some similarities between the function of JTBD and the function of user research. That’s because, as design leader Maximillion Speicher says, the core principles of JTBD and user research are the same:
“When I, as a UX professional, look at these statements, I quickly see that the two principles described — a deep understanding of peoples’ problems and desires, and a deep understanding of their social and emotional contexts — are exactly what’s also at the core of UX research, and in particular, persona research.”
Just like user personas and other user insight deliverables, a JTBD statement must be based on actual research. Your “best guess” at user motivations isn’t going to cut it. In that sense, JTBD is only as good as the research that’s behind it.
As Nikki Anderson-Stanier, a user research career coach, says:
“Ultimately, UX research and JTBD are complementary. Proper UX and persona research should already (at least implicitly) include Jobs To Be Done; and Jobs To Be Done are a very structured and easy-to-understand way to formulate customers’ pain points, contexts of use, as well as social and emotional circumstances.”
Jobs to Be Done is just one framework that you can use to communicate user needs. Similar user research deliverables include:
Let’s discuss the differences between each.
![Jobs to be done vs. user stories User stories are brief, narrative-based descriptions of why users want certain functionalities, written from the user’s perspective. A typical user story statement looks something like: “As a [description of user], I want [functionality] so that [benefit].” For example, “As a content marketer, I want website sessions data broken down by URL, so that I can make the case for prioritizing certain topics and article types over others.” Although user story statements look quite similar to JTBD statements, they’re not the same. JTBD statements focus on the user’s end-goal (irrespective of the feature, product, or user segment), while user stories describe the type of user, the product feature they want to use, and the ultimate benefit of that feature. Jobs to be done vs. user personas While JTBD focuses on what your users are trying to accomplish, user personas focus on who your users are, holistically. They’re used to segment different types of customers to understand how to build products that cater to the entire customer base. Because personas try to represent the specific characteristics of a segment using one “person” (e.g. talking about “Designer Dave” as if he is a real individual), they tend to be more abstract than JTBD, which is presented as persona-agnostic outcomes. Jobs to be done vs. customer journey maps Unlike JTBD, which only defines the user’s end-goal, customer journey maps focus on what your customers do in the process of becoming a customer, including the steps they take and the pain points they may encounter. Jobs to be done vs. empathy maps Empathy maps are great for, well, building empathy. By depicting what users think, feel, say, and do as they interact with your product, empathy maps help teams step into the users’ shoes to deeply understand their experience. Although empathy maps may include goals-related information, they’re broader and more humanized than JTBD. The motivations and desires of users depicted in JTBD are typically less touchy-feely and solely focus on what the user is trying to accomplish. Jobs to be done vs. task analysis While JTBD focuses on what users are trying to accomplish, task analysis breaks down the how. In this sense, JTBD and task analyses are highly compatible. For example, let’s say the JTBD for a banking app is, "When I’m out shopping, I want to transfer money from my savings to my spending account, so I can make purchases without having to run to the bank first." In this case, a task analysis might break down exactly what a user needs to do to accomplish this goal: open their banking app, sign into their account, view their savings balance, submit a transfer request, etc.](https://cdn.prod.website-files.com/59b1667dd2e65000019d07be/66bb971dd1bcb8e0147b4c35_642d97ba53d215dbd979aacc_z6IcS8mb-SLW1E8xXZcCM9fdqyPwVvHr6p_3u_zVg76OJzd4nRMDle3f4N6x_v6euQ097OYrWei1ZC9DuFthZjeW9TQ_b1p-bkrNtLm2pvh0HtSPLyyvzuCbdVsPDd7VJD3OB4Qm-jwvwMPSX9qTqiU.png)
User stories are brief, narrative-based descriptions of why users want certain functionalities, written from the user’s perspective. A typical user story statement looks something like: “As a [description of user], I want [functionality] so that [benefit].” For example, “As a content marketer, I want website sessions data broken down by URL, so that I can make the case for prioritizing certain topics and article types over others.”
Although user story statements look quite similar to JTBD statements, they’re not the same. JTBD statements focus on the user’s end-goal (irrespective of the feature, product, or user segment), while user stories describe the type of user, the product feature they want to use, and the ultimate benefit of that feature.
While JTBD focuses on what your users are trying to accomplish, user personas focus on who your users are, holistically. They’re used to segment different types of customers to understand how to build products that cater to the entire customer base.
Because personas try to represent the specific characteristics of a segment using one “person” (e.g. talking about “Designer Dave” as if he is a real individual), they tend to be more abstract than JTBD, which is presented as persona-agnostic outcomes.
As J. Henry McKeen, Senior UX Researcher at The Home Depot, says in UXMatters:
“Personas require designers and product managers to become fluent in complex structures that represent a lot of attitudinal variability, then interpret how those personas might respond to a proposed experience. JTBD circumvents these layers of abstraction.”
However, some UX researchers, like Nikki Anderson-Stanier, believe that JTBD can be used in tandem with personas:
“If you look up Jobs To Be Done Personas, you will often find articles called: ‘jobs to be done versus personas.’ When you put these two concepts together, it is usually an either/or conversation. They don’t seem to be able to exist together, in harmony. Most people believe you either do JTBD research or you have personas. I, however, disagree. I believe there is space for a JTBD persona.”
Unlike JTBD, which only defines the user’s end-goal, customer journey maps focus on what your customers do in the process of becoming a customer, including the steps they take and the pain points they may encounter.
CJMs are useful for building empathy and discovering common pain points. However, as J. Henry McKeen explains in UXMatters, they typically represent a highly generalized version of the customer experience:
“Journey maps depict how motivations and behaviors can change across time, but they also falsely depict rigid linearity. This oversimplification can cause a form of tunnel vision that fails to account for the nonlinear aspects of actual experiences. In contrast, JTBD doesn’t bring time into the equation. All that matters is that we document thought processes, behaviors, and points of friction, showing how they influence the perceived quality of an experience.”
Empathy maps are great for, well, building empathy. By depicting what users think, feel, say, and do as they interact with your product, empathy maps help teams step into the users’ shoes to deeply understand their experience.
Although empathy maps may include goals-related information, they’re broader and more humanized than JTBD. The motivations and desires of users depicted in JTBD are typically less touchy-feely and solely focus on what the user is trying to accomplish.
While JTBD focuses on what users are trying to accomplish, task analysis breaks down the how. In this sense, JTBD and task analyses are highly compatible.
For example, let’s say the JTBD for a banking app is, "When I’m out shopping, I want to transfer money from my savings to my spending account, so I can make purchases without having to run to the bank first." In this case, a task analysis might break down exactly what a user needs to do to accomplish this goal: open their banking app, sign into their account, view their savings balance, submit a transfer request, etc.
Ultimately, the mental model you choose for demonstrating tangible user insights is largely up to the needs and preferences of your team. As Sr. UX Researcher J. Henry McKeen says in UXMatters:
“It is noteworthy that, despite all the differences in these deliverables, the actual UX research methods underpinning JTBD do not differ from those for the creation of journey maps or personas. When developing a jobs atlas, you would still conduct contextual-inquiry interviews, think-aloud observations, and supplemental surveys, gathering data you might use as converging evidence in the same way you would elicit data in support of a journey map or set of personas. But it’s the way in which you analyze, organize, format, and present the data that really makes JTBD different and so powerful. This flexibility has made the adoption of JTBD methods much easier.”
Although Jobs to Be Done has become a staple of many product management teams, it’s not for everyone. Some of the reasons you might choose to use the JTBD framework over other mental models include:
For a real-life example of how and why a team uses JTBD, check out GitLab’s deep-dive into their JTBD philosophy, or watch the overview video below.
On the other hand, some of the reasons you might be wary about introducing JTBD into your product development process include:
Despite these potential drawbacks, there are plenty of case studies that demonstrate JTBD’s effectiveness when implemented correctly. For example, check out the JTBD case study for Target below.
You’ve decided to jump on the Jobs to Be Done train—so where do you start? Here’s a step-by-step guide to researching users’ desired outcomes, defining a strong JTBD statement, and using the framework to design effective solutions:
As we mentioned earlier, JTBD is only as good as the research that’s behind it—so the process of identifying “jobs” needs to be based on sound research.
As Jared Spool says:
“We know, from years of design practice, that the quality of user research matters. Inadequate or poor-quality research will not uncover strategically important unmet needs. Leaving the research details undefined opens a door for process issues down the road.”
Although there are different research approaches you can take to discover JTBD, it’s important to leave your solution out of the equation during the process, as explained by Nikki Anderson-Stanier:
“With Jobs To Be Done, we are completely solution-agnostic. We aren’t even thinking about our product or any products in general. We are focused solely on people’s motivations and how they act. We try to identify their anxieties and the deeper reasons of why they act the way they do, and why they respond in certain ways.”
For Jobs to Be Done research methods, we’re a big fan of user interviews (obviously). Nikki Anderson-Stanier provides a great guide on how to conduct interviews for JTBD research here, including sample interview questions like:
You can also find some helpful JTBD interview note-taking sheets and examples here.
Although we’re partial to interviewing as the primary method for uncovering users’ jobs and desired outcomes, surveys are also a great method for JTBD research too. You can reference this Jobs to Be Done survey template from Maze to get started.
For every JTBD, there’s typically a high-level job and smaller, related jobs that ladder up to accomplishing the main job.
Here’s an example from Microsoft XC Research of how a high-level JTBD—“be a healthy person”—could be broken down into smaller jobs:
Typically, there are jobs to be done throughout the customer journey, so you might define jobs across the user experience, similar to this example from GitLab:
For each of these main jobs and related jobs, there are functional, emotional, social, and personal dimensions that influence the user’s ultimate decision regarding which products to “hire” and “fire.”
As you’re doing your Jobs to Be Done analysis, you’ll want to identify the main jobs, the micro jobs that ladder up to the main jobs, and the different contextual dimensions of each. Every time you think you’ve discovered a JTBD, ask yourself whether or not it can be broken down into smaller steps, or if it’s a small/micro job that’s really representative of a higher-level goal.
Here’s an example of a JTBD defined by Lean Labs (via David Hodder):
After analyzing your research, you should be able to come up with a list of users’ desired (and undesired) outcomes, including:
Most JTBD statements can be built into one formulaic sentence:
"When [Circumstance], I want to [job], so I can [need/outcome] without [pain point]."
Some people prefer to write their JTBD statements from the company’s point of view (e.g. “In [situation], for [type of user], our [product or service] provides [benefit]”). However, we believe that writing them in the user’s POV does a better job of building empathy while remaining solution-agnostic.
When we say “competition” here, we’re not just talking about competitor brands in the same space as your solution.
Instead, we’re talking about any competing solution to achieving the job-to-be-done, including:
Even if these competing solutions are complicated or irksome, users still “hire” them to successfully get the job done. Your product needs to be better than the status quo to win—even if the status quo is an Excel spreadsheet.
When you’ve identified common jobs-to-be-done that your solution could solve, use surveys or likert scales to rank their urgency and prioritize the order in which your product team should work on solving them.
Your first priority should be critical JTBD for which there’s no satisfactory solution, i.e. customers need to get this job done, but currently don’t have access to great products or services for doing it. This is your opportunity to develop something better.
For jobs with satisfactory solutions, you may not have much of an opportunity to reinvent the wheel. Focus on solving related jobs or shifting to a new market.
When you’ve clearly articulated the JTBD and prioritized your product roadmap, you can work on designing solutions that solve for it.
To make sure you’re designing solutions that actually get the job done, consider:
After you’ve designed and launched solutions informed by your JTBD research, you need to continue monitoring the UX and make small adjustments to better satisfy users.
Some UX metrics you might want to track and measure include:
If you’ve been successful in designing a solution that gets the job done, then you’ll notice higher engagement, reduced customer churn, better reviews and NPS scores, and fewer requests for the support and customer success teams. If you see these metrics getting worse or remaining stable, then you might need to reevaluate your solution.
You can implement the Jobs to Be Done framework more easily and efficiently by taking inspiration from JTBD examples and using standardized JTBD templates. We’ve done the work of finding these examples and templates for you. 👇
When customers decide to invest in your product or service, they’re doing it to achieve a larger-scale goal beyond “send blast marketing emails” or “listen to music.”
The Jobs to Be Done framework helps you dig deeper into the context of users’ lives to determine these larger-scale motivations. Informed by the main JTBD, you can design solutions that more completely and efficiently satisfy the customer, leading to better products with higher usage and retention.
But like any representation of the customer or end-user, JTBD requires solid data from effective research to accurately communicate users’ high-level goals.
