How to use the jobs to be done (JTBD) framework to identify outcomes

The jobs to be done (JTBD) framework helps product teams discover what people are trying to accomplish when using your product. It’s a way to structure your discovery efforts around identifying outcomes and problems rather than features and solutions.

This article explains the JTBD framework and how you can use it to learn more about your customers and their impression of your product, including examples of how the framework has been used in real product teams.

What is the jobs to be done (JTBD) framework

Jobs to be done (JTBD), a term coined by Clayton Christensen, is the idea that people 'hire' products to get a particular job done. This reframing of customer discovery comes from the desire to understand why people choose to buy a product—and their desired outcome after using it—rather than trying to figure out what products people use based on shared characteristics (aka personas).

The JTBD framework provides a structured way to apply JTBD theory to your customer research. When you use the framework, there are two interpretations of jobs to be done you need to consider:

Jobs-As-Activities

The Jobs-As-Activities interpretation of JTBD is when customers buy a product to do work with that product. They see it as a means to an end: your product is a tool to get things done. 

According to this interpretation, the JTBD framework provides a way to categorize, define, capture, and organize your customer’s needs, and tie performance metrics to their 'jobs', or what they're trying to accomplish.

Examples of Jobs-As-Activities could be: 

• Listening to music, when the product is a music streaming service

• Drilling a quarter-inch hole, when the product is an electric drill

• Reading a book, when the product is a tablet 

With the Jobs-As-Activities approach, performance metrics are from the customer's perspective: have they been able to do the work—the job—they needed to do with your product?

As a product manager, if you subscribe to the Jobs-As-Activities interpretation, use the JTBD framework to improve the effectiveness of your product, and how customers experience it. You can get actionable feedback to explore things such as:

• Do some customers struggle more with using your product to accomplish a certain job than others (for instance, novices versus experts, older versus younger)?

• Is it possible to eliminate the need for particular inputs or outputs to your product in order to accomplish the job?

• Is it necessary that people execute all steps for which they are currently responsible? Can you automate some activities or shift them to someone else?

• In what contexts do people most struggle with using the product to accomplish the job today? Where else or when else might people want to execute the job?

Jobs-As-Progress

The Jobs-As-Progress interpretation of JTBD is when customers want to make a positive change in their life. They buy your product hoping it will make their life easier or more pleasurable, which may include enhancing or avoiding future work.

According to this interpretation, the JTBD framework provides a way to understand why someone buys your product. Understanding their pain points and desired outcome from this perspective helps you identify new ways to think about your product.

Examples of Jobs-As-Progress could be:

• Improving a commute, when the customer buys music to avoid boredom and make their commute more pleasurable 

• Improving their home, when they buy the electric drill to install a shelf on their wall to avoid clutter 

• Increasing their knowledge, when the customer buys ebooks to avoid having to travel to the bookstore

With the Jobs-As-Progress approach, performance metrics focus on whether the customer has made progress towards or accomplished their desired outcome.

As a product manager, if you subscribe to the Jobs-As-Progress interpretation, use the JTBD framework to help customers make a change in their life, by exploring why people select the products they do and do not use to reach their desired outcome. To build that understanding, ask questions aimed at understanding people’s search to find solutions that fit their JTBD, such as:

• What other solutions did you try before selecting our product?

• What did and didn’t you like about other solutions you tried?

• If you could no longer use our product, what would you use instead? 

How product teams use the JTBD framework

The real value of the JTBD framework is that it provides guidance on how to perform customer discovery, especially in user interviews. The guidance for customer discovery is particularly helpful for planning and conducting research, a common product management challenge.

Let’s take a closer look at how you can use the JTBD framework to structure your interviews and identify outcomes.

How the JTBD framework helps you structure user interviews

The JTBD framework provides guidance in three key areas to help you structure user interviews:

1. Why are you doing interviews?

2. Who are you going to interview, and what information do you need?

3. How should you interview them?

1. Why are you doing interviews?

As a starting point, understand why you are doing interviews in the first place. Conducting interviews without an underlying reason takes a lot of time and can produce extra data that gets in the way of making product decisions.

There are generally two reasons why you want to do user interviews:

The first reason to do interviews is to figure out why people use your existing product, and how you can improve the product for them. Typical scenarios include:

• You see customers are buying your product, but you’re not exactly sure what they’re using it for. You want to better understand their jobs to determine if your product can help them get their job done more efficiently. 

• You notice that customers have stopped using your product. You want to investigate what caused them to stop in order to identify changes to encourage usage.

• You suspect that your product may be trying to address too many different jobs, doing none of them well. It’s easy for a product that's been around for a while to try to be too many things for too many people. The result is that the product becomes bloated with features and not really efficient for anyone.

The Jobs-As-Activities interpretation is applicable in these scenarios. You conduct interviews to gather actionable feedback on your customers' experience with your product.

The second reason to do interviews is to understand what your customers are trying to accomplish, and what a product might look like that can help them. Typical scenarios include:

• You need to develop a completely new product. To determine if a product will be valuable, you need to understand what people are currently using to get a job done, and what they think of those current solutions

• You want to create a new complementary product. You may realize that a current product can only help your customers go so far towards what they’re trying to accomplish, and you want to understand what they need to progress to the next step and achieve their desired outcome.

• You find out that people use your product in unexpected ways. You want to understand what people are trying to accomplish with your product with these new uses so you can determine if there are new opportunities.  

The Jobs-As-Progress interpretation can be helpful in these situations. You conduct interviews to gather data about people's progress and what drives them to change their behaviors.

2. Who are you going to interview, and what information do you need?

The JTBD framework’s focus on understanding what your customers seek to accomplish helps you determine the right people to interview and the information you seek. The reason for conducting interviews plays a big factor in determining who you talk to and the information you collect:

• When you want to understand why people are buying your product, talk to people who recently purchased your product within the last couple of months. Ask them questions about their buying process to understand their thought process. When you understand what made them decide to buy your product, you’ll understand what they intend to use it for.

• When you want to understand why the amount of time people spend using your product has changed (or stopped altogether), talk to people who have recently changed their usage patterns. Ask them questions like “When did you change how you use [product]?” and “What were some of the factors that drove this change?”

These questions help you understand the factors that drove their behavior change to slow down or stop using your product. This group may also be helpful to understand whether your product is trying to do too many things. You can use product feedback to help identify some customers that may be potential interviewees.

• To understand jobs to be done that a new product might address, talk to the people who use products that you think might be competitors of your product. Ask them questions about their buying process, and ask them why they choose a competing product. These questions help you understand their job through the lens of products they currently use to do that job.

• To identify complementary products, talk to people who show regular use of your product but may have inquired about additional capabilities. Ask them questions like “What other products do you use in conjunction with [product]?” These questions help you understand the job they are trying to get done and where your product may fall short.

• To identify new opportunities, talk to people who you know are using your product in interesting ways. Ask them to walk you through a scenario that exhibits the unique usage pattern to understand why they use your product in the way they do.

3. How should you interview them?

When you talk to people about how they use a product, they'll probably tell you what they think you want to hear. It’s very difficult for people to predict the future 🔮 so instead of accurately predicting their actions—what they might use your product for—they’ll try to give 'the right answer' even though a right answer doesn’t really exist.

To avoid this problem, ask people to tell you stories:  

• What's something they've accomplished with the product?

• When was the last time they used the product, and how?

• How often do they use the product? How does it fit into their routine?

• When was the last time they were frustrated by the product? What happened?

Focus on real situations where they've changed their behavior or accomplished something as a result of using your product. This will help you understand the product experience at a much deeper level and uncover customer pain points you may not have been aware of before.

How the JTBD framework helps you identify outcomes

In addition to helping you structure user interviews, the JTBD framework helps you clearly identify what users and customers need—and why—rather than just what they think they want. 

When you interview people and ask them about the jobs they're trying to get done, they might also describe solutions they're currently using. You’ll need to dig a little bit to understand the underlying job so you can identify potentially different solutions.

Kyle Luther Anderson, a product management leader and coach, pointed out that the JTBD framework helps product teams identify the assumptions they have about their customers. When product teams explicitly state those assumptions they can gather information to confirm or invalidate those assumptions.

“Your organization has assumptions about what the customer wants, about their unmet needs, and what your customer considers a successful outcome. Oftentimes an org doesn't state assumptions explicitly, and many companies are pretty bad about putting those assumptions to the test.

But a PM needs to think about whether they have tested those assumptions with real customers. Have you validated those assumptions? Do you have evidence to support opinions? Do you know the backstory of the customer and the context around the job they're hiring a product to solve? 

The value of using the JTBD framework is what comes from those questions you ask, what you learn in unbiased research, and really focusing on the customer problem or opportunity.”

For more reading: ​​Kyle got so excited about the topic that he wrote up his thoughts on LinkedIn.

When you should and should not use the JTBD framework

Like every framework, the JTBD framework is well suited for some situations—and not as well suited for others.  Before you start using the framework you need to decide if it will work for you. Here are a few things to consider:

Why your product team should use the JTBD framework

As described above, the JTBD framework provides a way to structure your customer and user research so you can identify their needs and understand necessary outcomes.

The framework's focus on outcomes rather than outputs means that you measure progress and success based on solving a problem or helping your customers accomplish something (outcome) vs merely tracking features delivered (output). The focus on outcomes ensures that you only deliver features necessary to help people get their job done. You avoid delivering features that aren’t needed and potentially help get the product into your customer’s hands sooner.

The JTDB framework also helps you make sure you focus on the right outcomes. Your customers probably have several problems that could be solved, but only a few might be blocking them completely. When you can solve the really troublesome problems for your customers—and provide a lift to your business—you have found the right outcomes. Remember, just because you can solve a problem, doesn't mean you should.

You may also want to use the JTBD framework if you’re looking for a way to structure your exploration of your customer’s experience purchasing and using your product.  Often a guide to that exploration can help you identify opportunities faster than just 'winging it'. 

Why the JTBD framework doesn't always work

The JTBD framework isn't as simple as creating 'job stories'—aka 'job statements' which provide a way of describing customer jobs in the form: “when [situation] I want to [motivation] so I can [expected outcome].”

When JTBD first came to the attention of product managers, some practitioners suggested that describing these job stories could directly replace user stories as a way to organize your backlog.

Unfortunately, if you simply rewrite a user story in this format, you haven’t taken advantage of the aspects of the JTBD framework that help you understand your customer’s needs.

Because there are different interpretations of what a job is, your team can get wrapped up in semantic arguments instead of guiding productive activity. But don’t worry about which interpretation is right; instead, consider which interpretation is helpful in your given situation:

• If you’re working on a new product, you want to know the progress people are trying to make, and you’re better off trying to understand the process they used to pick their current solution. You’re following the Jobs-As-Progress interpretation. 

• If you're working on an existing product, you want to know how to improve people's experience with that product.  You need to understand how they currently use the product, so you follow the Jobs-As-Activity interpretation. 

Finally, frameworks are really helpful when you understand how they work. But if you don’t quite understand the framework, you can misuse it and end up wasting your product team’s time, and potentially come to the wrong conclusions. The JTBD framework is backed by complex theories, so there’s a bit of a learning curve.

How to apply the JTBD framework in 4 steps

It’s possible to dive in too deep on jobs to be done theory and lose sight of why you wanted to use the framework in the first place: to better understand and empathize with your users, and identify what they're trying to accomplish with your product. 

Follow these practical steps to use the JTBD framework productively:

1. Identify the customers' jobs to be done

Interview your customers to find out what they're trying to accomplish, problems they're trying to solve, or pain points they’re trying to avoid. 

If you’re working on a new product, focus on cases where there are insufficient solutions available to help people accomplish those outcomes. 

If you’re working on an existing product, find the areas in your product that cause your customers the most difficulty or present the opportunity for new solutions.

2. Categorizing the jobs to be done

Once you’ve identified the customer jobs through your research, categorize your jobs into similar groups. For example, if you do jobs to be done interviews for the scenario where you’re working on a new tablet, you may discover jobs such as:

• Reading a book

• Reading white papers

• Reading long-form magazine articles

• Watching a movie

• Watching the game

• Playing solitaire

• Playing sudoku

• Reading email

You may decide to group those jobs into a few similar groups such as:

• Read something to increase my knowledge

• Watch something to pass the time

• Play a game to pass the time

• Get some work done when I’m away from my computer

When you can combine jobs into similar groups, you avoid duplicative analysis and you have fewer jobs to choose from when it comes time to prioritize which ones you’re going to tackle.

3. Determine which jobs to be done your product should address

For a product to be successful, it can’t be everything to everyone, so you need to decide which job you’re going to fulfill and then strive to fulfill it. Identifying the job you’re working on (and the ones you aren’t) is an important way to provide focus.

Take a look at the categories you identified in the previous steps and put them in an order by which job people most want to accomplish. That order may be clear from the information you collected from your customer interviews.

If the order isn't clear from your interviews—or you prefer more quantitative insight—you can use an approach like a cost of delay analysis to compare the jobs numerically.

Once you have an order, take a look at the list considering which job provides the most value to your organization. Hopefully, the order stays the same, though you may have to adjust if you find a particular job is very valuable to your customers, but not something your product team is ready to tackle right now.

If we look at the tablet example again, you may determine from your interviews that customers would prefer to get the jobs done in this order:

• Watch something to pass the time

• Read something to increase my knowledge

• Get some work done when I’m away from my computer

• Play a game to pass the time

But as your product team talks through it, you realize you don’t have any solid partnerships with cellular service providers, so you can't guarantee that your customers will have sufficient bandwidth for an enjoyable streaming experience. Therefore, you decide the first job you’re going to tackle is read something to increase my knowledge. 

4. Actioning

The final step in applying the JTBD framework is to use the information you learned about your customers' needs and desired outcomes to develop a product that addresses users' needs. 

If you don’t have a clear idea of the solution, you may start by crafting some hypotheses about how to solve problems and then develop some experiments to test out those hypotheses.

For example, you may have a hypothesis that people want to read things on the tablet but don’t want the hassle of a bunch of different reader apps for different formats (a different app for ebooks vs PDFs vs magazine articles). So you craft an experiment where some people try the tablet with a single app that will display all different types of files. You have others try a tablet that uses several different apps to read different types of files.

As you define the experiments, you need to run and the result features for your solution, use backlog management to describe and sequence the work you need to do.

Jobs that product teams hire Hotjar to complete

During user research, the Hotjar team referred to these customer jobs to identify our collection of Hotjar use cases. We describe these jobs in a form roughly based on the job story format: "when [situation] I want to [motivation] so I can [expected outcome]."

Get inspired and discover opportunities

When product teams want to provide new solutions to problems that resonate with their users, they incorporate Hotjar into their customer usage monitoring routine to understand how users interact with their product. 

You can use broad data from tools like Google Analytics to identify a potential issue and then supplement that discovery by viewing specific cases using Hotjar. Seeing those specific cases lets you know what’s happening and provides clues in ways you can address the issue. You can also identify opportunities to make improvements to your product.

For example, Zenprint used Hotjar to “reveal what numbers don’t” and discovered opportunities to optimize.

The team uses Google Analytics to get a big picture view of what is happening on their site. When these broad numbers point to a particularly high bounce rate on a page, the team uses Hotjar Funnels, Recordings, and Heatmaps to look for specific causes of the increased bounce rate.

Once the team identifies the issues, they can split test new layouts to address the issue. This split testing led to a 7% drop in bounced visitors.

Reduce assumptions and increase confidence

When product teams prioritize their work, they use Hotjar to gather actionable feedback to validate their assumptions and base their prioritization decisions on actual evidence. 

You may assume that the layout of certain pages impacts how frequently people use a certain feature, or causes people to leave your product prematurely. When you can validate these assumptions and quantify the impact of these issues, you can be more confident in your prioritization decisions.

For example, Bannersnack (now Creatopy) used Hotjar Session Recordings to confirm that users often missed their “timeline feature.” They used this information to make the feature more visible and noticed a 12% increase in product conversion.

Get buy-in and align with the team

When product teams communicate their prioritization decisions, they use Hotjar to create a shared understanding of users’ behavior amongst the team to secure alignment and buy-in. 

Hotjar's Heatmaps, Session Recordings, and Incoming Feedback provide evidence that explains why addressing certain issues is crucial to help customers get their jobs done. This information can come in handy when you need to convince stakeholders that a change is important to improve your customer’s experience. 

For example, Hussle uses the Hotjar Slack channel integration to prioritize changes and get the entire team on board. With the channel, they spot and fix a bug once a week.

Discover issues and prioritize fixes

When product teams need to maintain products they've launched, they use Hotjar to identify issues, prioritize improvements, and improve the UX. Hotjar provides access to specific instances that bring context to broader analytics data. 

You can use traditional analytics tools to identify issues, then use Hotjar to hone in on specific cases to identify the cause of the problem. This lets you quickly address the cause of the issues and develop solutions to help customers get their job done.

For example, StudentCrowd used Hotjar to reveal that a CTA wasn't visible on certain mobile devices. The team at StudentCrowd used that knowledge to prioritize a fix to the location of the CTA and saw a corresponding  55.5% increase in conversion rate.