Jobs to be Done 101: Your Interviewing Style Primer

At first, I resisted Jobs to be Done.

I didn’t understand how to use it. I didn’t see what it added over traditional generative interviews.  It had a lot of buzz, and it was totally out of my comfort zone. 

Fortunately, not too long ago, I was reintroduced to the concept and have grown to be more open-minded about different user research methodologies. And it didn’t take me long to balk at my own unwillingness to learn something new. I picked up two books: Jobs to be Done by Tony Ulwick and Competing Against Luck by Clayton Christensen.

In the weekend it took me to devour them, I was not only a convert, but also as excited as a kid in a candy shop. The methodology offered us something special—and I couldn’t wait to put this into practice. 

Psssst. We sat down with Jobs to be Done (JTBD) creator, Tony Ulwick, to discuss the intersection of qual research and the methodology. Watch it for free here. 

Understand: What exactly is Jobs to be Done?

Surprisingly, this is a controversial question. Since JTBD was loosely written about as a theory, there are many different views on what Jobs to be Done is and how it should be interpreted. 

Some people view Jobs to be Done as a well-branded repackaging of concepts already known to the research community, like task analysis. Others believe it’s a totally new, innovative approach for how to think about your users and their decision-making processes. 

I'll stay away from controversy. Instead, I’ll cover the basics and explain how you can let JTBD guide your user interviews.

Jobs to be Done encompasses the concept that users are trying to get something done, and that they “hire” certain products or services in order to make progress towards accomplishing goals.

Usually, we all want to be better than we are in a given moment. We all have goals that lead us closer to our ideal self. So, we will look for and purchase certain products or services when our current reality does not match what we want for the future. In addition, we'll also switch to a new product or service when our current solution is no longer sufficiently getting us towards our goals. 

Mainly, I use Jobs to be Done to answer the following questions about users:

1. Why did a user start looking for a particular product/service? What was the trigger?
2. Why did a user hire (purchase) a product/service for the first time?
3. Why and how did a user switch between two (or more) different products/services?
4. How did a user search for new products/services?

When you boil it down, as researchers, we're simply trying to understand the hiring and purchasing patterns of our users, what conditions have to exist for a user to start using product X, and why they would then switch from product X to product Y.

Implement: Framing interviews with Jobs to be Done

Structurally, getting started with Jobs to be Done is relatively similar to how you would begin a classic generative research session. I usually slot 60-90 minutes for the interview time, as sometimes it can take a while to get comfortable—especially if you are new to this interviewing technique.

I recruit a bit differently, however. I usually screen for: 

1. People who just recently started using our product/service 
2. People who have just recently stopped using our product/service 
3. People who have not yet used our product/service

With these groups of people I hope to understand:

1. Why people switch to our product/service
2. Why people switch away from our product/service
3. What people who have not heard about our product/service are trying to accomplish, and how they're currently doing that
4. What pushes/pulls people into using our (or a competitor’s) product/service

As you can see, switching behavior is extremely important, as is the concept of being pushed or pulled into a product/service. A lot of these interviews are focused on why people are switching from one product/service to the next, and what happened to make them say: “Hey, I need a better solution.” 

And this is where Jobs to be Done gets hard. You can’t simply ask a user why she switched to a different product or service. If you do, you won’t get to that deeper goal that is actually driving this behavior. I’ll use myself as an example.  

I just recently switched to all-vegan cleaning products. This was a huge pain to do. First, I live in Germany, and my level of understanding the German language is not at the point where I can distinguish exactly what product ingredients mean—and online translation often comes up with some ridiculous suggestions. Second, it's a lot of money to switch from the store-branded name to vegan products. Third, it takes a lot of research and time to find vegan cleaning products that actually work. 

And if you ask me why I decided to do this, I would tell you: I want to contribute to helping the environment. While that’s true, it’s a surface-level answer.

If you dig deeper, you’d realize that I deeply care about animals. And my decision-making process actually took place over several years. I realized that I not only wanted to be more environmentally and animal-friendly, but I also wanted to be seen as more conscious and aware of my impact on the world. I was embarrassed at how much of a conflict I had between loving animals and using or eating animal-based products. And I was finally pushed to the decision because I was sick of my cognitive dissonance. 

But if you asked me about it point blank: that’s probably not what I’d tell you. 

In order to understand deeper goals and behavior, we need to entice users into telling us stories surrounding why they are deciding to do something. Similar to generative research, we need to probe, but we need to do so in a specific way.

My interview scripts have always been relatively bare-boned, as I usually have several high-level questions I want to ask. I let the interviewee then lead the direction of the conversation. I try to focus on the “switch event” that leads a participant to make a change.

These are the main questions I always include:

• What other solutions did you consider before trying the product /service?
  • What were you trying to find when you were considering those solutions?
  • What were you trying to solve?
  • Tell me about how you looked for these products/services.
• What other solutions have you actually used?
  
  • What did and didn’t you like about other solutions you’ve tried/used?
• If this product/service wasn't available to you, what you do instead?
• What solutions have the people you know tried or used?
• What are you doing now compared to the past?

Since most of our memories are recalled through associations with people, places, smells or sounds, I often ask users what time of day it was, if they were at home or at work, if the TV was on in the background, and who they were. This helps get them into the mindset to tell stories that bring up feelings associated with the experiences. 

Once I understand the different competitors, and potentially grasp the switching behavior, I start trying to dig deeper with more emotionally questions like: 

• When did you first realize you needed something to solve your problem?
  • Did you talk to anyone else about what choices you were considering? What was this conversation like?
  • Was anything recommended to you?
• What did you imagine using this product/service would be like?
• What did you want from the product/service?
• Did you have any anxiety about purchasing/using this product/service?
  • Was there anything that made you nervous about using it?

While conducting the interview, listen for motivations or pain points that led to a switch:

• Push of the situation: What was it about their particular situation that led them to look for a new solution?
• Pull of the situation: What was it about the new solution that made them want to try it?
• Habits holding them back: What habits do they have that may prevent them from trying a new solution?
• Anxieties of the new solution: What anxieties did they have about trying or using a new solution?

This takes a lot of practice, so I do recommend trying these techniques internally with your company or with friends before venturing out to the world of your users.

Act: Why is Jobs to be Done worth doing?

For me, Jobs to be Done has brought a whole new perspective to user research, and unearthed different ways I can help companies succeed. As anything, it isn’t a magic potion. In fact, it’s a descriptive theory. It does not prescribe a certain way of doing things, and it's not explicit in what you should do to change. 

Mastering this technique is tricky and takes a lot of practice. Oftentimes, people don’t actually understand why they did something and are not able to analyze themselves in an unbiased way. 

Jobs to be Done suggests that users want to make a positive change in their lives, and the way they do that is through progress. If we, as researchers, focus on what the positive change is, and how to help users make that change, we can easily get them users towards their desired goal in a much more efficient and enjoyable way.

With this information, we can build powerful products with useful features that speak directly to our users. We can help transform our users into their ideal selves.