Jobs to Be Done (JTBD) in UX Research

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
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:

  • What is the Jobs to Be Done (JTBD) framework in UX?
  • How does JTBD differ from other mental models in UX research?
  • Pros and cons of (or arguments for and against) JTBD
  • How to research and design for JTBD in UX
  • Jobs to Be Done (JTBD) examples and templates

What is the Jobs to Be Done (JTBD) framework in UX?

Example of JTBD: Even though customers buy carbon skateboards with swiss bearings, titanium hardware, hollow trucks, and polyurethane wheels, they really want this: to do a kickflip.
Source

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:

  • Users don’t hire HubSpot to provide CRM software and marketing automation. They hire HubSpot to grow their business. 
  • Users don’t hire Spotify to browse, download, and stream media. They hire Spotify to easily and affordably listen to the music they love during the most mundane—and the most important—moments of their lives. 
  • Users don’t hire Verizon to make phone calls. They hire Verizon to reliably connect with their loved ones, no matter how far away they might be.
  • Users don’t hire Research Hub to automate screening, scheduling, and reminder messages. They hire Research Hub for the peace-of-mind that all the logistical aspects of a study are handled—without the time-suck of doing it manually.
Real-world jobs to be done examples: Users don’t hire HubSpot to provide CRM software and marketing automation. They hire HubSpot to grow their business. Users don’t hire Spotify to browse, download, and stream media. They hire Spotify to easily and affordably listen to the music they love during the most mundane—and the most important—moments of their lives. Users don’t hire Verizon to make phone calls. They hire Verizon to reliably connect with their loved ones, no matter how far away they might be.Users don’t hire Research Hub to automate screening, scheduling, and reminder messages. They hire Research Hub for the peace-of-mind that all the logistical aspects of a study are handled—without the time-suck of doing it manually.

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. 

💡Pro Tip: User Interviews is the fastest way to recruit participants for any kind of research. Talk to sales or sign up for a free account today.

📃 What does a JTBD deliverable look like?

A user’s “jobs to be done” are characterized by social, emotional, and functional dimensions. 

Jobs to be done breaks down into functional and emotional aspects. The emotional aspect is comprised of both personal and social dimensions.
Source

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.

🤝 How does JTBD fit into UX research? 

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.”

🧠 How does JTBD differ from other mental models in UX research?

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. 

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. 

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.”
💡 You’re probably familiar with personas—but have you heard of the anti-persona? Learn more about these less-than-ideal persona types and how to communicate with them

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. 

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.”
📑 144 (Mostly Free) Templates and Examples of Customer Journey Maps

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. 

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.”

Pros and cons of the JTBD framework

Pros of JTBD: * Outcomes over features: Teams that focus on achieving outcomes, rather than adding features, can design better, more effective solutions that help users achieve those outcomes.  * The need behind the need: JTBD describes the user’s real need, or “the need behind the need” which can help you design solutions that more fully and efficiently meet those needs. For example, for a travel ticketing website, instead of “I need to buy plane tickets,” the real JTBD would be “I need to travel across the country as quickly and easily as possible.” * High-level strategy and innovation: Because you’re focusing on the user’s ultimate end goal instead of the feature or functionality, you can take a higher-level approach to product development, designing solutions that fit seamlessly into the greater context of users’ lives.  * UX metric for existing products: Even if you already have solutions on the market, digging into the users’ true JTBD can help you evaluate how well those existing solutions “get the job done,” informing UX improvements down the line.  * Stakeholder communication: JTBD helps you communicate with stakeholders in a language they understand.   Cons of JTBD: * Doesn’t (necessarily) promote empathy: As Page Laubheimer of Nielsen Norman Group says, “While JTBD do include some key considerations about the emotional and social context of a user goal, they generalize them among the entire user base, and therefore miss that key sense of context about users, and lose the opportunity to create empathy among the design team.” * Lack of defined JTBD research process: One criticism of JTBD is that the creators don’t explicitly outline the right research process to uncover a user’s JTBD, suggesting that research isn’t an important part of the framework. However, we believe that the lack of a defined process doesn’t mean research isn’t part of the equation—it’s up to researchers to define the right path (and we’ve suggested some approaches in the section below).  * Confusion, controversy, and different perspectives: Some consultants have tried to position JTBD as an alternative to UX, which steps into dangerous territory—JTBD should not be used instead of UX, but rather as a tool to inform UX teams.  * Not as practical for highly complex products: As Jared Spool says in his article for UIE, “Jobs to be Done can’t help with most complex products and services in the world today. Sure, we could apply it to specific features or functions (and maybe we should more often than we do).... The gimmick of Jobs To Be Done only works in certain situations. However, we have to build innovative products that deliver compellingly great user experiences even when JTBD isn’t the right approach.”

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:

  • Outcomes over features: Teams that focus on achieving outcomes, rather than adding features, can design better, more effective solutions that help users achieve those outcomes. 
  • The need behind the need: JTBD describes the user’s real need, or “the need behind the need” which can help you design solutions that more fully and efficiently meet those needs. For example, for a travel ticketing website, instead of “I need to buy plane tickets,” the real JTBD would be “I need to travel across the country as quickly and easily as possible.”
  • High-level strategy and innovation: Because you’re focusing on the user’s ultimate end goal instead of the feature or functionality, you can take a higher-level approach to product development, designing solutions that fit seamlessly into the greater context of users’ lives
  • UX metric for existing products: Even if you already have solutions on the market, digging into the users’ true JTBD can help you evaluate how well those existing solutions “get the job done,” informing UX improvements down the line. 
  • Stakeholder communication: JTBD helps you communicate with stakeholders in a language they understand. 

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:

  • Doesn’t (necessarily) promote empathy: As Page Laubheimer of Nielsen Norman Group says, “While JTBD do include some key considerations about the emotional and social context of a user goal, they generalize them among the entire user base, and therefore miss that key sense of context about users, and lose the opportunity to create empathy among the design team.”
  • Lack of defined JTBD research process: One criticism of JTBD is that the creators don’t explicitly outline the right research process to uncover a user’s JTBD, suggesting that research isn’t an important part of the framework. However, we believe that the lack of a defined process doesn’t mean research isn’t part of the equation—it’s up to researchers to define the right path (and we’ve suggested some approaches in the section below). 
  • Confusion, controversy, and different perspectives: Some consultants have tried to position JTBD as an alternative to UX, which steps into dangerous territory—JTBD should not be used instead of UX, but rather as a tool to inform UX teams. 
  • Not as practical for highly complex products: ​​As Jared Spool says in his article for UIE, “Jobs to be Done can’t help with most complex products and services in the world today. Sure, we could apply it to specific features or functions (and maybe we should more often than we do).... The gimmick of Jobs To Be Done only works in certain situations. However, we have to build innovative products that deliver compellingly great user experiences even when JTBD isn’t the right approach.”

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. 

How to research and design for JTBD in UX

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:

  1. Identify jobs users want to accomplish.
  2. Analyze and define each JTBD. 
  3. List users’ desired outcomes.
  4. Write a Jobs to Be Done statement. 
  5. Identify the competition.
  6. Evaluate and prioritize opportunities. 
  7. Design solutions to satisfy users’ desired outcomes.
  8. Track and measure changes in the user experience post-launch. 

1. Identify jobs users want to accomplish.

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: 

  • What other solutions did you consider before trying the product /service?
  • If this product/service wasn't available to you, what would you do instead?
  • When did you first realize you needed something to solve your problem?
  • What did you imagine using this product/service would be like?
  • Did you have any anxiety about purchasing/using this product/service?

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. 

🛑 No participants? No research. Recruiting reliable, high-quality participants is key to collecting useful JTBD data. Get started with these 8 uncomplicated customer recruitment strategies for product managers, UX designers, and marketers

2. Analyze and define each JTBD. 

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: 

Aspiration (goal) = be a healthy person. The big job (objective) = get outside/exercise. The little job (activity) =go on a hike. The micro job (task) = find a pair of hiking boots. Jobs-to-be-done framework example

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:

Image showing how the main job to be done breaks down into smaller jobs and micro-jobs which make up the steps to completing the main job

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):

Jobs to be done example for the problem "my website sucks." When my website sucks (situation), I want to redesign the site (motivation), so I can look better and convert more leads (outcome), making me feel proud of my brand and confident (emotional job), and other see that I'm driving the company forward (social job).
🚨 Bias poses a major risk to every analysis. Learn how to identify and minimize bias for better (more ethical) outcomes.

3. List users’ desired outcomes.

After analyzing your research, you should be able to come up with a list of users’ desired (and undesired) outcomes, including:

💰 Speaking of costs and inefficiencies—what is the relative ROI of DIY recruitment, agency recruitment, and recruitment tools like User Interviews or UserZoom? Explore our comparative analysis of the ROI of user research and recruiting tools.

4. Write a Jobs to Be Done statement. 

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. 

Jobs to be done template: I want to (desire/motivation) when (situation/context), so that I can (outcome/result) without (pain point/constraint). Statement example: I want to listen to my favorite songs while exercising so that I can feel motivated and inspired without having to listen to commercials or skip songs I don't like.
Source

5. Identify the competition.

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:

  • Competitor brands/products
  • Manual or makeshift solutions 
  • Off-brand use cases 

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. 

6. Evaluate and prioritize opportunities.

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.

📚 Related Reading: Tips for Prioritizing the User Research Projects that Drive Product Strategy, by Lead UX Researcher Ashley Tudor

7. Design solutions to satisfy users’ desired outcomes.

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:

  • Under what circumstances would the user consider the job successfully “done”?
  • How can we remove existing obstacles to achieving the desired outcome?
  • What solutions can you provide that satisfy users within the social, emotional, and functional contexts of the job?
🎙️ Researching and designing meaningful user experiences is tough. Hear Senior Product Designer & Researcher Susan Rice discuss how she juggles it all on the Awkward Silences podcast

8. Track and measure changes in the user experience post-launch. 

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. 

🧠 Learn more: How to Track and Measure the Impact of UX Research

Jobs to Be Done (JTBD) examples and templates

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. 👇

Jobs to be Done examples

Jobs to Be Done templates

🏗️ After you’ve determined the job-to-be-done, it’s time to start building solutions. These 128 prototype templates and examples will help you get started.

In a nutshell

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. 

Subscribe
X

Research like the pros

Get the full course and exclusive pro tips delivered straight to your inbox.
Thanks! See you in your inbox 👋
Oops! Something went wrong while submitting the form.