Jobs to be Done Case Study
fromAtoB

If you asked anyone at fromAtoB what the purpose of was our platform, you would hear similar quotes:

"An online ticketing platform" or "a way to search for cheap tickets" or "a way to compare tickets to find the cheapest route."

fromAtoB is, in fact, all of those things. We had nailed down an internal definition of what we did as a company. We sold cheaper tickets, with different and creative routes. We wanted to provide our users with all the options (efficiency, price, comfort) they needed to make the best travel decision. 

Unfortunately, the cart came before the horse. In user research terms, the company and technology came before the user. Before I joined, there was some user research done in the form of usability testing and trying to gain a deeper understanding of users. But the organization still believed, as many companies do, that the user revolved around the product. 

What I wanted to do was switch that mindset upside down and propose a Copernican Revolution - the user stands in the middle, and businesses revolve around them. The user is the shining sun, and products are the planets that revolve. I no longer wanted fromAtoB to stand in the center of the universe; I wanted our users to be in the center of our business. 

Who was involved?

There is nothing better than employing a framework that spans the entire organization. For this project, I was the sole and lead researcher, but I worked with designers, product managers, marketing, customer support, and some interested developers!

Reasons behind the method

After weighing the pros and cons, I decided to use the Jobs to be Done framework for a few different reasons

 

  • Jobs to be Done allowed us to research users agnostic of the company. We were able to focus solely on the user's needs, problems, and goals

  • We were able to reframe solutions into problems/opportunities, which is the starting point for valuable development. JTBD enabled us to view the users from a more goal-driven lens. We were able to understand users' motivations and drivers of their behaviors. We could then speak to these needs with features, marketing, and customer support

  • This framework gave us a holistic view of our users. We could understand their world outside of our product, and how our product could potentially fit into their day-to-day life. We stopped forcing a product on to users and, instead, fit it into the jigsaw puzzle of their life

  • The holistic nature of understanding our users also allowed us to work more cross-departmentally. We stitched together the entire experience and broke down silos between departments

  • We understood the value we brought and the areas we were unable to provide value. With this realization, we could focus better on what truly mattered to our users

Jobs to be Done is not a single methodology or technique but, instead, a way of thinking and mindset. With JTBD, our understanding of the fromAtoB platform evolved from "a cheap online ticket comparison platform" to "enabling users to get to their destination." 

There are, of course, some cons to Jobs to be Done: 

  • It was a new concept, and while it is easy to understand, it is challenging to master

  • JTBD requires a huge mindset change that the organization must grapple with and, eventually, accept 

  • A lot of education goes into what JTBD means, and "how-to's." I won't cover that portion in this case study, but I am happy to answer additional questions

Overall, however, Jobs to be Done helped us reframe our mindset and the way we saw our users. Ultimately, this led us to be much more successful.

Executive Summary

Job preformer

 

A person searching for and booking trip

 

Main job

 

Booking a trip

 

Deliverables

 

  • Needs statements

  • Forces diagram

  • Personas

  • Switch timeline

  • Customer journey map

 

Needs statements

 

  • Minimize the time it takes to book a roundtrip plane ticket for a family 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 as a group

 

Forces diagram outcomes

 

  1. We could easily see the moment when people start struggling, and ways we could potentially address that struggle

  2. Marketing language changed to alleviate anxieties around booking with a third party, and also about the time crunch that comes with booking a trip

  3. Customer support highlighted what would happen if something were to go wrong during the trip, and what exactly we can do to help as a third-party provider

  4. We found how important it is for users to be able to make comparisons (prices, transport, times) and created prototypes to test with users

 

Persona outcomes

 

  1. We were able to narrow our decision-making to serve our primary customer better

  2. Designers felt more comfortable making design decisions, knowing what the user expected

  3. Product managers were better able to make feature decisions, and could A/B test two different variations with more confidence 

  4. The entire organization better understood our primary user, which resulted in more specific marketing campaigns and better copywriting throughout the website

 

Switch timeline outcomes

 

  1. A holistic view, agnostic of our solution, of the purchasing journey for booking a trip

  2. The early iterations of our customer journey map 

  3. Showed the team that users did not revolve around our product and were considering many other options outside of fromAtoB

 

Journey map outcomes

 

  1. Identified gaps in the overall journey, particularly those that are painful for users

  2. Highlighted areas for new and innovative opportunities on how to solve user's pain points and anxieties 

  3. Got the team thinking outside the box of what we currently offer. We considered ways we could alleviate the anxiety users go through beyond the time they are on our platform

  4. Helped the organization work cross-departmentally on solving problems by mapping the holistic experience people went through when booking a trip. Teams realized how important it was to create a coherent and jointed flow, from marketing to customer support

  5. A customer support playbook was created to face the most common pain points

Overall process

Objectives

Ultimately, the reason we did this research was to create successful solutions for our users. As a business, we want to increase revenue while also increasing user satisfaction. We had the following objectives:

  • Identify opportunities for innovation 

  • Examine and address the market to provide value

  • Understand users' needs, pain points, and overarching goals to align our platform

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

For this particular project, we found a difference between leisure travel, obligatory travel (such as traveling to see family), and business travel. For this case study, we will focus on leisure travel.  

Timeline:

We were trying to pivot and create several new features in the coming month. Overall, the entire project, end-to-end, took about six weeks. 

Discovering jobs

Main job & job performer

Our first step was to go hunting for users' jobs. We used previous generative research to determine the main job performer and the main job. We did this by sitting together and reviewing the previous research to see the types of users we encountered most in our generative projects. 

We decided to focus on the person who was searching for AND booking a leisure trip. This decision of focus was because this type of trip (leisure), and this type of customer (the one searching and booking), was our most revenue-generating.

Main job performer: people who are searching for and booking the travel

Main job: Book a trip

Recruitment

We used HotJar and LinkedIn to recruit our users. We wanted a mix of users and non-users to ensure we were also getting insights from those unfamiliar with our product. 

  • We conducted a screener survey, which included questions such as:

    • "When was the last time you booked a leisure trip?"

    • "What types of transport methods have you used in your previous travel?"

    • "What websites/apps have you used to book travel?"

    • "How was your last booking experience for a leisure trip?"

  • 17 participants: a mix of people from Europe (primarily Germany) and the United States

  • A combination of remote and in-person interviews 

Methodology

We used in-depth interviews to understand the user's motivations, pain points, and needs. In-depth interviews allowed us to use open-ended questions and explore these concepts from an unbiased point-of-view. We used questioning techniques, such as TEDW. Some of the sample questions 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?

For each of these questions, we use "how" and "why" to more deeply understand the user's mental models. Asking users "why" they do something gives us a higher-level overview, and asking "how" gets us more specific information on the task or concept.

Other methodologies included:

  • Surveying

  • Concept testing of the journey map 

  • Workshops

Needs statements

 

Needs help us understand why a person is acting the way they do while they are trying to accomplish their primary job. Need statements are concerning getting the main job done, rather than about a requirement or a particular solution. The needs are success criteria that a user will face along the way of completing the overall job. 

The way we formulated needs statements were 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 will be impacted by the job

  • Clarifiers are contextual clues to give descriptions of circumstances surrounding the job

We created these need statements based on the main job and all the factors that go into completing that job. As a reminder, the main job we focused on was book a trip.

We (me, designers, and product managers) came together in a workshop to brainstorm the different needs statements. The workshop had the following steps:

  • I put the formula, a few examples I had created on my own, and the main job on a huge canvas to remind us what we were looking for

  • We combed through the research, each creating as many needs statements as possible in 15 minutes 

  • We then clustered similar needs statements

  • We clarified any confusing or incomplete needs statements 

  • We combined similar needs statements to avoid repetition

Below are some examples of need statements we created from the workshop:

  • Minimize the time it takes to book a roundtrip plane ticket for a family 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 as a group

After we found the needs statements, we sent out a survey to help us prioritize the most important. We used each of the needs statements and asked surveyors 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)

These answers allowed us to calculate our opportunity score, which is the importance minus the satisfaction. The higher the opportunity score, the higher the priority. 

Needs statements outcomes:

  1. We were able to understand the different needs/factors associated with the user getting the main job done, agnostic of fromAtoB

  2. We quickly found unmet needs and prioritized them 

  3. We created several features to satisfy the unmet needs of the users

Forces diagram

 

We wanted to look into what made people stay with their current solutions and what made them consider switching to ours through the forces diagram. 

A forces diagram helps us identify what pushes people away from an existing solution and what pulls people towards a solution. This diagram shows us where we could potentially enter the market with innovative ideas to help draw people towards our platform. 


Here is how we got to the forces diagram:

Stakeholders involved: me and designers to review

  1. Pulled together the qualitative research from the in-depth interviews in four different areas

    1. Push: What are the current struggles when trying to book a trip

    2. Pull: What works well with the current ways you book a trip

    3. Anxieties: What concerns are there about trying to book a trip in a new way

    4. Habit: What would you miss about the current way you book a trip (if you had to switch)

  2. For each interview, I created a forces diagram. I then overlaid each graph to find the top 5 trends in each box

  3. Brought together all of the patterns into one single diagram

*Note: This is a sample and not the exact diagram used

*Note: This is a sample and not the exact diagram used

Forces diagram outcomes:

  1. We could easily see the moment when people start struggling, and ways we could potentially address that struggle

  2. Marketing language changed to alleviate anxieties around booking with a third party, and also about the time crunch that comes with booking a trip

  3. Customer support highlighted what would happen if something were to go wrong during the trip, and what exactly we can do to help as a third-party provider

  4. We found how important it is for users to be able to make comparisons (prices, transport, times) and created prototypes to test with users 

Personas

 

Before I started, there were no personas or segments. We were trying to design for everyone, which was not ideal. We didn't understand who our different users were and how to serve them best. I wanted to create some direction for our teams about our users in a digestible way. These personas were a communication tool to summarize information about users in a way that was accessible for everyone on the team


We went through the following steps when creating the personas (it included many iterations):

Stakeholders involved: designers, product managers, marketing, and customer support

  1. We decided to focus on the leisure trip job performer. The person who was searching for and booking the trip

  2. We decided on the criteria to use during the workshop, which was the essential information to highlight in the persona. We did this by each member of the workshop outlining what they would like to use the persona for. We had also surveyed the company on what they would use the personas for. We settled on the following points:

    1. Values, pain points, needs, tools, tribes (based on Amadeus travel tribes)

  3. Each stakeholder generated as many post-its for each point mentioned above

  4. We then clustered the information into an affinity diagram of each point

  5. We clustered similar information

  6. We highlighted the most common (top 5) patterns under each point

*Note: This is a sample and not the exact information used

*Note: This is a sample and not the exact information used

Personas outcome:

  1. We were able to narrow our decision-making to serve our primary customer better

  2. Designers felt more comfortable making design decisions, knowing what the user expected

  3. Product managers were better able to make feature decisions and could A/B test two different variations with more confidence 

  4. The entire organization better understood our primary user, which resulted in more specific marketing campaigns and better copywriting throughout the website

Switch timeline & JTBD Customer Journey Map

 

We also listed out the different stages people went through when thinking about booking a trip. These stages helped us from the beginning of our customer journey map. We started with a switch timeline, which gave us the step-by-step documentary of users' purchasing journey. 

I went through the following steps when creating the switch timeline:

Stakeholders involved: me and designers to review

  1. Gathered all of the research surrounding the purchasing behavior from the in-depth interviews 

  2. Created switch timelines for each interview to find the most common patterns and trends during the process

  3. Distilled the patterns into one comprehensive timeline that covered the majority of use cases. Some outliers were present in the research, and we kept those insights to tackle later on

*Note: This is a sample and not the exact timeline used

*Note: This is a sample and not the exact timeline used

Switch timeline outcomes:

  1. A holistic view, agnostic of our solution, of the purchasing journey for booking a trip

  2. The early iterations of our customer journey map 

  3. Showed the team that users did not revolve around our product and were considering many other options outside of fromAtoB


Once we created the switch timeline, we flushed it out to create a more significant customer journey map. The customer journey map reflected the process users went through when finding a way to book a trip and the actual flow they encountered on fromAtoB. We highlighted:

  • Emotions felt during the discovery and purchasing journey 

  • Pain points, obstacles, and frustrations encountered

  • Tasks completed during each of the stages

  • Other tools users would potentially be involved in

  • How well our offerings satisfy/help users at each stage (self-grading on a scale of 1-5)



The reason we chose to focus on a customer journey map was to bring the organization into the research. So far, we had a lot of information on how people were booking travel, agnostic of fromAtoB. We wanted to ground the insights and findings in a tangible way for the company. This concrete visualization aided in people seeing how we could improve our current experience and offerings to align better with user's needs and expectations.


We went through the following steps when creating the customer journey map (it included many iterations):

Stakeholders involved: designers, product managers, marketing, and customer support

  1. Decided to map the journey of the main job performer, which was the person searching for and booking the trip 

  2. Gathered the qualitative data from the in-depth interviews

  3. Uncovered a pattern within a series of steps users went through affinity mapping the most common journey users took. We listed all the steps we heard, tallied up the most common, and assigned common phrases to each

  4. Assigned emotions, pain points, goals, and tools to each phase through affinity mapping the most common trends in the research

  5. Used a scale from 1-5 to grade how well we were serving user's goals, and helping through any anxieties under each phase

  6. We included iterations of the customer journey map at the end of our user interviews to get direct feedback from users on what they thought

*Note: This is a sample and not the exact journey used

*Note: This is a sample and not the exact journey used

Customer journey map outcomes: 

  1. Identified gaps in the overall journey, particularly those that are painful for users

  2. Highlighted areas for new and innovative opportunities on how to solve user's pain points and anxieties 

  3. Got the team thinking outside the box of what we currently offer. We considered ways we could alleviate the anxiety users go through beyond the time they are on our platform

  4. Helped the organization work cross-departmentally on solving problems by mapping the holistic experience people went through when booking a trip. Teams realized how important it was to create a coherent and jointed flow, from marketing to customer support

  5. A customer support playbook was created to face the most common pain points 

What’s next & reflections

 

What’s next

JTBD was an excellent framework to work with and gave us many insights. It helped in several ways:

  1. By identifying the needs and jobs, we brainstormed several different solutions to some of the pain points we encountered from our users. We created prototypes and tested them with users. We continued to iterate on these concepts.

  2. We prioritized the features with the jobs we found. Understanding the prioritization and importance from users helped the product team create a jobs- and user-centered roadmap  

  3. We started to change our marketing language to target the jobs users face, instead of merely marketing our product as a "cheap online ticketing platform."


Reflections

  1. Jobs to be Done is fantastic, and I love using this way of thinking, but it is a challenging skill to master

  2. Much education was needed to highlight the value of Jobs to be Done

  3. There was a lot of convincing on why we were spending weeks on this project

  4. I was fortunate to work with stakeholders who gave me the green light quickly to move forward

  5. Getting stakeholders involved in workshops took some time, and I had to start with fewer people and then grow the invitations. However, many stakeholders became extremely interested and joined the innovation

  6. It was great to see projects, prototypes, and experimentation coming straight from research insights