Step 1 Define the market

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?

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.

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.

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.

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.

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…

Step 2 Create a job map

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.

Step 3 Uncover the customer’s outcomes

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?