Getting started with Jobs to be Done

Jobs to be Done (JTBD) is one of those controversial topics like personas or the NPS. Some people hate Jobs to be Done, some swear by it, and others are confused about how to do it. Because it’s a polarizing framework, there’s a lot of contradictory information out there. For example, when I first dove into Jobs to be Done, my Google searches left my head spinning. One person said it was a useless tactic, another noted that you had to form job statements in one particular way, and another said that the switch interview was the only thing you should be doing when it came to JTBD.

Because of this, I bounced around, not knowing how to use the JTBD framework properly. So, I avoided it. Whenever a stakeholder recommended or mentioned using Jobs to be Done, I shied away, stating that a different methodology would be better. My biggest fear was undertaking a JTBD project and, in the end, not finding any jobs. 

Eventually, I couldn’t hide from JTBD any longer. A project came along, and it was the perfect opportunity for Jobs to be Done, even to the point where I didn’t believe my arguments against using the framework. So, I rolled up my sleeves, read way too many books and articles, and set forth into the JTBD universe. I came out on the other side and want to help you do the same.

First, what is Jobs to be Done?

Jobs to be Done is not a magic pill or some completely new and unheard-of methodology. I don’t even classify JTBD as a methodology, but more of a framework, as the method you use during JTBD is one-on-one interviews. Instead, Jobs to be Done is a framework and mindset you use when interviewing users or non-users. At the beginning of the project, you decide to overlay this framework on your approach and deliverables. 

Jobs to be Done looks at people and the things (jobs!) they try to accomplish. It is product-agnostic research. Let’s take an example:

My big goal (main job) is to cook a meal for my family. Within that larger goal, there is a process I might go through, such as checking for allergies, deciding what to cook, and buying groceries (smaller jobs). With these smaller jobs come needs, such as minimizing the amount of time the meal will take to cook or increasing the likelihood people will like the meal. 

So, you take a larger goal, break it into smaller parts, and look at the needs associated with smaller parts. Now, this is taking a complex framework and simplifying it. Additional caveats include what job level you want to look at, such as a vast, aspirational job versus preparing a meal. Choosing this is deciding the level at which you want to innovate. I always avoid going for overly aspirational jobs because it can be challenging to focus. 

So, let’s see how this works in the real world.

How to use Jobs to be Done

When to use JTBD

When I worked at a travel company, we decided Jobs to be Done would be a great next step for the organization. I chose to use JTBD for this project to understand our users’ goals and needs, agnostic of our product. It wasn’t about how our product fit into their lives (or didn’t), but rather how they thought about, made decisions, and considered travel on a higher level. 

It also enables you to innovate by finding and examining peoples’ actual needs and building solutions based on that. 

For this project, our objectives included:

• Identify opportunities for innovation 

• Examine and address the market to provide value

• Understand users’ needs, pain points, and overarching goals outside of our product 

• Create a positive movement in success metrics for the business (in particular, we looked at increasing conversion rate, click-thru rate; and reducing bounce rate and customer support calls)

Our main job was booking a leisure trip. 

Segmenting before JTBD

Before jumping right into JTBD, you need to do some segmentation, just like any other generative research method. As I was looking at travel, I decided to segment between leisure travel rather than different types of travel, such as for work, visiting family, etc. Essentially, I focused on people who were going on a holiday. I also limited it to people without children as we found, in previous research, a massive difference in the way people think about and decide on leisure travel when including children. I then focused on the person exploring, searching for, and booking the trip as it would get me the most information on the journey. 

Since this is generative research, you need a larger sample size per segment (another great reason to segment!). The ideal range is no less than 12 and no more than 25. For this project, I spoke to 15 leisure travelers. 

Conducting JTBD

As I mentioned, JTBD is a framework, not a method. One of the most common methods used for JTBD is 1x1 interviews. In-depth interviews allow you to use open-ended questions and explore these concepts from an unbiased point of view. 

Some sample questions you can use to understand “jobs” are:

• What are you trying to accomplish? What tasks are involved in this?

• What problems are you trying to resolve?

• How do you get started?

• What is the previous/next step?

• How do you feel at each stage?

• What do you dread doing? What tasks do you avoid?

• What is most frustrating?

• What hacks or workarounds do you use?

• How does the environment or others impact you getting X job done?

Finding jobs

Since our big job was booking a leisure trip, we had to find the process and smaller jobs associated with this bigger goal. So, after the research, we went through and highlighted everything that contributed to that primary goal, such as:

1. Searching for a trip 

2. Comparing trip options

3. Coordinating with others about the trip options

4. Choosing the ideal trip (considering: time, length, price)

5. Purchasing the trip

Many other jobs came from the study (I once had a JTBD with over 100), but the best thing you can do is break up the main job into smaller steps. Once you finish the research, go through and pick out all the different things people tried to do to achieve that goal and focus on those. 

Creating needs statements

Needs help us understand why people act the way they do while trying to accomplish their primary job. Need statements concern getting the main job done and are success criteria a user will face while completing the job. The way we formulated needs statements based on Lance Bettencourt’s and Anthony Ulwick’s desired outcome statements:

direction of change + unit of measure + object + clarifier 

• Direction of change is how the job performer wants to improve conditions.

• Unit of measure is the metric for success (such as time, effort, and skill)

• Objects are the objects/concepts that the job will impact

• Clarifiers are contextual clues that provide descriptions of circumstances surrounding the job

We created these need statements based on those smaller jobs we identified above. So, the smaller tasks that contribute to the main job get converted to needs statements:

• Minimize the time it takes to book a roundtrip plane ticket for a leisure vacation

• Maximize the ability to compare different aspects of a trip 

• Increase the likelihood of booking the best trip option for the destination

• Reduce the risk of a problem occurring during a trip 

• Minimize the effort it takes to coordinate with other travel companions when traveling with others

Grade yourself

These needs statements then become your inspiration for innovation and creating solutions. With these needs statements, you understand what the user is trying to accomplish in a given situation. The next step is to grade yourself on how your organization or product does/does not support people’s needs.

For example, let’s take: maximize the ability to compare different aspects of a trip. Based on our current platform, I would rate from one to five how well we do or do not support the user during this step, one being completely unsupported to five being completely supported. Using this, you can see the gaps in how you help people (or don’t) with their needs and begin to innovate and improve.

Prioritizing needs statements

If you have a bunch of needs statements and have graded yourself, you might have to take one more step to prioritize which are most important to your users. For this, you can send out an opportunity gap survey to help prioritize the most important statements. In this survey, you ask the participant to rate each statement on two scales:

1. The importance of the statement

2. The satisfaction of the current offering

For example:

Minimize the effort it takes to coordinate with other travel companions when traveling as a group

• How important is this to you? (1 = very unimportant; 7 = very important)

• How satisfied are you with the ability to get this done? (1 = very unsatisfied; 7 = very satisfied)

Use these answers to calculate your opportunity score, which is the importance minus the satisfaction. The higher the opportunity score, the higher the priority. 

Innovating and improving

Once you’ve done the above, the fun part comes. I take the top three unsupported and most prioritized needs and hold an ideation workshop. During this workshop, you begin to design potential solutions to your users’ needs. Then, you run a series of usability tests to ensure you are on the right path. With this approach, you are prioritizing and helping to support the most critical needs of your users, creating a more satisfactory product. 

If you’re looking for a great (and non-controversial) resource, check out Jim Kalbach’s Jobs to be Done Playbook. This book helped me connect the dots and conduct better JTBD research.