How to get results from Jobs-to-be-Done interviews
Gaining a deep understanding of the customer's job-to-be-done requires unique interviewing skills and techniques. Here are the methods that will get you started
Jobs-to-be-Done Theory is integral to successful product planning — the ability to conceptualize a product or service that will win in the marketplace BEFORE it is approved for development/design. Applied correctly, it results in predictable innovation, as products and services are certain to address unmet customer needs.
Jobs-to-be-Done Interviews solve the puzzle of understanding customer needs
Before a company can determine which needs are unmet, it must first uncover all the customers’ needs. Most companies struggle in this effort and in many cases company managers can’t even agree on what a “need” is. Fortunately, customer needs can be effectively defined and successfully captured through qualitative Jobs-to-be-Done interviews.
Jobs-to-be-Done interviews have a specific goal — to gain a deep understanding of the job the customer is trying to get done. Consequently, when conducting these interviews, the focus should not be on the buying process, the day of purchase, customer behavior or the product. Instead, the focus should be solely on understanding the core functional job the customer is trying to get done.
I’m a practitioner of Outcome-Driven Innovation® (ODI), a methodology that predates JTBD Theory, and was integral in the development of the theory’s core tenets. The research methods included in the ODI process enable a researcher to gain a deep understanding of the customer’s job-to-be-done because they seek to uncover the metrics that customers use to measure success (or dare I say “progress”) when trying to get a job done. These uniquely defined needs are called customer desired outcomes.
Desired outcomes are the building blocks of predictable innovation
Understanding the job-to-be-done at a deep level is like assembling the pieces of a puzzle. When all the pieces come together, you have a complete and granular understanding of the customer’s job-to-be-done. As is the case when assembling a puzzle, there is a most efficient way to gain a deep understanding of a job-to-be-done.
When assembling a puzzle, it is best to start with the frame/borders. With the frame in place you know where you are bounded. You know the playing field and you know that all the pieces are going to fit somewhere inside the frame. Next, you group together pieces that contain similar colors/patterns as you know they are going to be closely related and fit together. Lastly, you fill in all the remaining pieces.
Jobs-to-be-Done interviews solve the customer needs puzzle in three simple steps
The way we study a job-to-be-done for our clients can be described in three steps.
We first define the market we are studying as a group of people and the job they are trying to get done (create the frame).
Next, we create a job map (group together like pieces). The job map breaks down the core job into the steps that comprise the core job.
Lastly, we uncover the customer’s outcomes (needs) for each step in the job (fill in all the pieces).
This article explains all three steps in detail.
Note: if a client wants to discover and/or enter brand new markets, then we begin the process with a market discovery and selection phase. This is not covered in this article.
Identify the Job Executor
Companies have many customers and stakeholders. Unlike the B2C world, where things seem more clear cut, creating solutions for companies can be daunting. With all of the influencers, decision-makers, buying groups, end users, operators, installers and others, who do you interview?
Using ODI, JTBD interviews focus on three types of customers:
End users — These are the people who use a product or service to get the core functional job done. The end user can provide you with the performance metrics (desired outcomes) that you need in order to understand how to design better products and services. These metrics are the inputs you need to help end users get their jobs done better, more predictably, and more efficiently.
If the goal of the initiative is to create a product that gets the job done better, then the end user is the right customer to target.
People on the product lifecycle support team — These are the people who install, set up, store, transport, maintain, repair, clean, upgrade, and dispose of products. These are what we call consumption chain jobs because they relate directly to a solution (and its consumption). Not all of these jobs are relevant in every situation, but the people that perform these jobs can help you find ways to improve the overall customer experience.
If the goal of the initiative is to simplify the execution of the consumption chain jobs, then the people on the support team are the right customers to target.
Purchase Decision Makers — These are the people responsible for seeking out and evaluating alternative offerings, and then deciding which to buy. These are the people to talk to when you need to understand how to improve the buying process, and also to understand the financial metrics used to make the buying decision.
If the goal of the initiative is to sell more of what you have to the purchase decision maker, then defining a go-to-market strategy for the purchase decision maker is the right choice.
Which job is the job executor trying to perform?
Before we begin to identify possible jobs, and learn how to find them as you conduct interviews, I’d like to briefly talk about how and why we recommend that a “job” statement is constructed in a certain way. People buy products and services to get a core “job” done. That job — which we call the core functional job — is the unit of analysis when executing the ODI process.
This job becomes the focal point around which all customer needs are defined, and around which value creation should be centered. Therefore, a “job statement” needs to be defined at the right level of abstraction, and stated using a consistent structure and syntax.
Strategyn has been testing this for decades to develop and validate this structure.
Job statements possess a number of unique characteristics (the details are covered in other writings):
A job-to-be-done is stable and does not change quickly or substantially over time. The key benefit is that it is stable throughout the development and launch cycle.
A job-to-be-done has no geographical boundaries.
A job statement is solution agnostic.
A job-to-be-done is a process.
A core functional job can be studied using Six Sigma principles.
To be successful, it’s critical that the core functional job be defined properly. Having said that, you don’t need to get it perfect the first time; you’ll be able to validate it later as you conduct your interviews. To understand what job executors are trying to get done, you need to:
Ask the right question — most products only get part of a job done. In the continual pursuit of growth, we need to discover the entire job the customer is trying to accomplish; because that is how we can find growth opportunities. It’s not helpful to ask a customer “What job did you hire that product to do?” because this most likely won’t identify the entire job. Instead, ask them…
“When using that product, what are you ultimately trying to get done or accomplish?”
“Are you using multiple products?”
“What are you trying to accomplish as you cobble together multiple products and services?”
“What is the final output you’re seeking?”
Listen for action verbs, the object of the action and the contextual clarifier.
Take the customer’s perspective — when defining the core functional job, think about it from the customer’s perspective, not the company’s perspective. Just like above, too often the company’s solution perspective is far too limiting.
For example, a company that supplies herbicides to farmers may conclude that growers are trying to “kill weeds,” while the growers might say they are trying to “prevent weeds from impacting crop yields.” It’s not about what the company is providing, it’s about what the customer is trying to accomplish.
Don’t overcomplicate it — A functional job statement should not be multilayered and complex. A well defined statement is one-dimensional and simple.
Don’t include emotional jobs and other needs in the statement — when defining the core functional job, make sure it’s defined as a functional job, and not a hybrid functional/emotional/social job. A functional job does not have social and emotional dimensions; these are stated as separate job statements. Do not include vague language that can be misinterpreted in a job statement. We generally see this when needs are incorporated into the statement.
Invalid: stay awake and occupied while I make my morning commute more fun.
Valid: Stay awake during my morning commute.
Define the job, not the situation — Do not define the core functional job as a situation a customer finds themselves in. Instead, define the job around what the customer decides to do (get done) in that situation. You might be looking for something to do while waiting in line at the doctor’s office. However, looking for something to do is not the job, it’s the situation.
You might decide to “stay up-to-date on current events” or “create a grocery list” while waiting. Those are jobs.
The following is a non-exhaustive list of common verbs that can be used to “listen for” and to “construct” job statements:
Define the Market
We define a “market” as a group of people + the core functional job they are trying to get done. For example, music enthusiasts who are trying to listen to music constitute a market.
Since we know that people hire products and services to help them get jobs done, it would follow that we need to know which groups of people we want to target (e.g. music enthusiasts) and what job they are trying to get done (listen to music). This is a solution-agnostic and thereby stable view of a market over time. Regardless of the solution, there will always be a group of people who wish to listen to music.
Customers are loyal to the job-to-be-done, not to the solutions they use
By viewing the market the way we do, we have a stable lens through which to monitor the performance of the market well into the future, using the same set of metrics. When we use the lens of a product, we introduced undue variability into how the market is defined, and measured. Too often, end users are left with the task of comparing features across many solutions, that don’t match perfectly, or are simply irrelevant to them.
Worse, they can never be forward-looking.
By using the job-to-be-done as the unit of analysis, we can monitor how well customers view current and emerging solutions against a common and persistent set of understandable criteria.
Pro Tip: Look for jobs in which a single executor performs all of the steps. When multiple executors (or teams) are introduced, that generally means theses are part of the consumption chain. This is a critical component in finding the right level of abstraction
Now that we have the market defined, it’s time to decompose it…
We treat Jobs-to-be-Done as processes. It provides a clear path for innovators to understand how to make progress toward the goal of addressing the entire market with a solution; not just part of the market. Since most products only get one step done, it becomes clear to see which steps are adjacent, and how all of the steps line up with a provider’s existing capabilities.
Now that we know what the job is, we need to break it down it into steps by…
Understanding the characteristics of a job
Instead of a process map, we create a “job map.” Your job is to elicit the steps through a series of interviews. It’s critical to the process for the following reasons:
It identifies where the job begins and where the job ends, revealing gaps in current solutions.
It identifies the optimal logical flow for processes enabling it. Many processes become inefficient and iterative when an input needed early in the process is not available until later in the process. This optimal flow can often be revealing all by itself.
It defines the competitive landscape. Understanding the complete job often reveals non-traditional competitors.
It establishes a long-term roadmap for product/portfolio development. It paves the way to getting the entire job done on a single platform (or offering).
It guides the capture of desired outcome statements associated with the core functional job. This is why it is created before we capture them.
Universal Job Map to Guide Jobs-to-be-Done Interviews
Use the Universal Job Map as a guide; but note that a core functional job can have from 10–20 steps. It depends on the job. Your job is to define and validate these steps with job executors.
Pro Tip: Go into your first interview with a straw man job map that can be shared. It helps to have something to react to. A little bit of preliminary research here goes a long way
Ask the Right Questions
Keep the following things in mind as you conduct your interviews:
A good job map describes what the customer is trying to accomplish, not how they are accomplishing it (or the solution they are using).
A completed job map represents the ideal flow for the job.
A job map is not a customer journey map. It doesn’t describe the consumption of an offering: i.e., the purchase process, configuration, upgrading, maintaining, etc.
A job step statement applies universally no matter which customer is executing the job, or the product they are using to help them get the job done.
A job step is solution-free, and stable over time.
A job step “statement” is structured exactly the same way as the core functional job statement.
To begin, ask the recruit to walk you through their process:
“What is the first thing you do as you begin performing the job?“
It’s critical to understand that they will talk in solution terms. So it’s important to probe.
“What are you trying to accomplish when you do that?”
You can also ask:
“What do you need to plan for, or what decisions do you need to make before you begin the job?”
Once you’ve established where they start, you can continue to make your inquiries about subsequent job stages:
[LOCATE] “What steps do you take to locate and gather the needed inputs?”
[PREPARE] “What steps do you take to prepare or organize those inputs?”
[CONFIRM] “What steps do you take to confirm you are ready to execute the job?”
[EXECUTE] “What steps do you take to execute the core functional job?”
[MONITOR] “What steps do you take to monitor or verify the execution step is executed effectively?” “What do you track as you perform the job?”
[MODIFY] “What steps do you take to make modifications to the execution when something goes wrong?”
[CONCLUDE] “What steps do you take to properly complete the job, or prepare for the next job cycle?”
Pro Tip: Start your interview by discussing the execute step, working from the middle out. This provides the anchor for your interview, which you can refer back to
Finalize the Job Map
When the preceding iterative process is completed, it’s always a good time to socialize it with the stakeholders who want to provide better offerings to these customers. Their approval and agreement is critical before moving forward.
While it’s fine to work with a simple outline — or list — when building the steps, once finalized it makes sense to lay it out visually. Job maps are generally linear — the happy path in journey-speak — so visual representations will not have decision trees or loop-backs like a process map will. Again, this is the ideal logical flow and not a process that might have numerous constraints and/or decisions.
Here’s an example job map:
Business Professionals + Stay Informed on a Topic of Interest
How do Customers Measure Success?
Given that we use a completely unique view of what a market is, we’ve had to create our own measures of success. We call them desired outcome statements and they have a set of characteristics you need to know. They are not expressions of pain, or delight, or gains, or struggles since that would only represent one individual — and a single state of the need. They are designed to be mutually exclusive and collectively exhaustive in order to describe perfect execution of the job.
Our approach has been exhaustively tested over the years, and trust me, any variations you might come up with have most likely been proven to cause problems. So, keep the following characteristics in mind:
They are stable over time: It’s hard to hit a moving target. If you’ve worked on projects/products where the requirements evolved you’ve probably noticed this. If needs are always changing, or being described differently, then innovation will always be a guessing game. Since the customer’s core functional job to be done is stable over time, then the performance metrics attached to that job must also be stable over time.
They reveal how customers measure value: If the perfect set of need statements elaborates the metrics that customer use to measure success when getting the job done, then customer value can also be measured. Creating that value then becomes more predictable.
They enable the accurate evaluation of all competing solutions: The ultimate set of customer needs would enable a company to accurately assess how much better or worse one solution is over another (old, current and emerging).
They guide the creation of new products and services: The perfect needs statements are measurable and controllable by executors, and therefore actionable.
They prevent misunderstanding: They should be be clear, concise, accurate and stated in a way this is not misunderstood, misinterpreted or misused. They are not ambiguous
They explain all the causal factors that contribute to failure: As I mentioned above, you need to uncover all of the factors customers could use to measure success. Why? Because there is no average customer.
They are discoverable through research: They should be easily obtainable in a consistent format. Keeping them simple makes them easier to capture
They will enable to discovery of unmet needs: Performance metrics are stateless. However, they must be structured in such a way that customers can prioritize them.
They will not contribute to process variability: The statements must be structured consistently so customers do not interpret them differently when asked to prioritize them
They will unify and inform the organization: One set of desired outcomes would inform the entire downstream organization (R&D, M&S, Marketing, etc.) so all capabilities are working in concert.
What is the Structure of a Desired Outcome Statement?
Desired outcomes have a formulaic and grammatical structure that supports the characteristics outlined above. Outputs in this structure are what you are trying to capture during your JTBD interviews.
This structure, and many variations thereof, has been heavily tested over the years. More details around each of these will be available soon in the ODI Community of Practice. Each statement has a…
Direction of improvement — improvement is not static; it requires progress along some dimension. Based on years of research and testing, we always use the word minimize for a variety of reasons. In a nutshell, job executors are always trying to eliminate time, avoid problems, and eliminate inefficiencies.
A predictive metric — we use two metrics: time and likelihood. A lot of thought and testing has gone into this over the years. Other words tend to get solutiony, and make it more challenging for survey respondents. Simple is better.
Minimize the time it takes to (do something)
Minimize the likelihood that (something causes an undesirable result)
Minimize the likelihood of (something undesirable happening)
An object of control — this explains precisely what the customer is trying get done faster, more predictably, or with higher throughput / output.
A contextual clarifier — this identifies the conditions or circumstances a customer may be encountering. While it can often be left out, it helps to ensure the outcome statement is not misinterpreted.
Object of control + [when]
Object of control + [for what purpose]
Object of control + [to what end]
Examples (optional) — the perfect desired outcome statement shouldn’t need examples. However, there are situations where some words have to be more clearly interpretable by survey respondents.
Rules for constructing a valid desired outcome statement
Over the years a set of rules has evolved for creating proper desired outcomes statements; and they continue to evolve. More details around each of these will be available soon in the ODI Community of Practice.
Make sure the statements are in the required structure/format — this provides consistency from outcome to outcome.
Make sure the statements are unambiguous — if the outcome can be interpreted differently by different people, then the value of the outcome is reduced
Make sure the statements possess the required characteristics
It must describe how to the customer is measuring success
It must be measurable and controllable
It must be stable over time
It must be predictive of successful execution of the job
It must describe what the customer is trying to get done, not what they are doing
It must not reference technology or solutions
Ask the Right Questions
Minimize the likelihood of capturing an outcome statement that does not comply with all of the rules!
The good news is that you have a map to guide your discussion. It has a logical flow, so it makes a lot of sense to follow the map from beginning to end as you try to elicit desired outcomes statements. As each step is discussed, you should be listening for insights into what they are trying to achieve, or avoid; and then translate those into the proper format.
Guide them through the map asking “what do you do next, and what are you trying to achieve, or avoid?” Much like a process, the result of a job is going to be an input into a subsequent step.
Avoid discussing product features that your respondent wants to see in the next version of a product. Instead, have them focus on the following questions:
What makes [job step] time consuming? — this will lead to outcomes that begin with “minimize the time it takes to.”
What are you trying to achieve when [job step]?
What are you trying to avoid when [job step]? — this will result in outcomes that begin with “minimize the likelihood.”
What makes [job step] unpredictable? — or you you can use words like inefficient, challenging, wasteful, or inconvenient.
When trying to [job step] what makes [solution A] more attractive than [solution B]? — your goal here is not have a discussion about solutions, but to uncover desired outcomes based on an advantage or disadvantage perceived by the respondent.
Pro Tip: If a respondent expresses a vague need, ask them to describe how they define this term. It’s likely that you will need to chunk this down into a number of more discrete desired outcomes.
Pro Tip: During the discussion, many different types of needs may surface. While discussing the core functional job, the respondent may reveal a related job, an emotional job or an outcome related to a consumption chain job. Capture these and then move the discussion back to the core job.
That was pretty straight forward, wasn’t it?
Your done with the interviews, now what?
Each stage of the ODI process has a purpose that feeds into the next stage. Hopefully, you noticed that in the discussion of job maps as well. Our qualitative interviews are designed solely to build a customer value model that can be prioritized through surveys to reveal otherwise hidden opportunities.
Now you have the basic knowledge you need to begin building customer value models with Jobs-to-be-Done interviews that will set you apart from the crowded world of innovators, designers and marketers.
Your decision should be easy: go out and begin conducting JTBD interviews that build an actionable model that you can use for years to come.
One more thing: we will soon have a dynamic guide — using these same techniques — that you can use with our Jobs-to-be-Done Canvas. We use the canvas to facilitate workshops with groups — and many others are beginning to use it as well. It provides a solid roadmap for conversations with job executors. Stay tuned…
This is the best customer needs collection technique because you learn what your customers are trying to achieve and not just what they’re doing.
6 year follow up. These interviews do not uncover insights. They are designed to build comprehensive models of how a market measures success. Then we go out and measure success at scale.
If you're doing JTBD interviews to get insights, you're taking a shortcut that explains the high product failure rates. Sorry if I've offended anyone. (not really).
So when I apply these rules using AI, I'm able to generate models at scale. This has always been laborious. Glad I could help 😉