10a. What Customers Want

The thesis of Jobs to Be Done (JTBD) is that by considering what progress customers are trying to accomplish when purchasing products, product developers can better understand why customers do what they do, and thus design better products during new product development.

This JTBD framework is presented as an alternative to the “simpler” approach of simply identifying customer requirements or needs.

JTBD advocates consider ‘just focusing on needs’ to be too ambiguous.

An excellent book on JTBD is called What Customers Want. Here’s a big-ass quote that pretty much distills the entire book (formatting is my doing).

“To execute their innovation processes successfully, companies must obtain three distinct types of data.

They must know which jobs their customers are trying to get done (that is, the tasks or activities customers are trying to carry out)the outcomes customers are trying to achieve (that is, the metrics customers use to define the successful execution of a job); and the constraints that may prevent customers from adopting or using a new product or service.” — Tony Ulwick, What Customers Want

Three key things: jobs, outcomes, and constraints.

By focusing on these three things systematically, product developers have a much better chance of designing products that deliver significant value.

The Trifecta: Jobs, Outcomes, and Constraints

These three data sources represent the primary means by which companies can create new and significant customer value: by helping customers perform ancillary jobs, new jobs, or more jobs; by improving customers’ chances of getting a specific job done to satisfaction; and by removing obstacles that prevent customers from doing a job at all.” Tony Ulwick, What Customers Want

Ulwick is building on the Jobs to Be Done theme we’ve been discussing by introducing the concepts of outcomes and constraints.

Outcomes are the specific metrics that customers use to measure the performance of their products.

Constraints are things that would prevent a customer from using a new product.

Ulwick stresses that better products are made primarily by delivering better outcomes, and that product developer should systematically design for improved performance in important and underserved outcomes.

If that doesn’t make a ton of sense right now, it will soon. In the next few sections, we’ll cover:

• What are the outcomes?
• How to discover outcomes?
• Which outcomes are most important

Enjoy!

Main Source: What Customers Want — Tony Ulwick.

10b. JTBD and Outcomes

We are talking about Jobs to Be Done and how it can be more effective than just thinking about customer needs in general.

In What Customers Want, author Tony Ulwick says product developers should consider what job the customer is trying to do, what outcomes they’ll use to measure success, and what constraints exist that would prevent them from adopting a product.

Let’s talk about outcomes.

What is an Outcome

“Customers use a set of metrics (performance measures) to judge how well a job is getting done and how a product performs . . . We call these metrics the customers’ desired outcomes.” — Ulwick

The outcome is the fundamental measurement used to evaluate how well a product performs in some dimensions of the job for which you hired it.

Example outcomes from a dishwasher:

• How clean the dishes are
• How easy it is to load the dishes
• How quietly it runs
• How reliable the latch is
• How easy it is to repair the latch when it turns out not to work
• How long you wait on hold when calling for the repair of said latch
• How completely disdainful the customer service rep is about your broken latch and inability to clean your dishes

Sorry, I recently had a dishwasher repair incident, and I got a little carried away there. You get the point.

Outcomes Are Like the Performance Review for Your Product

When a company hires you to do a job, they’ll usually tell you how you’re doing. You’ll likely be rated on the quality of work, timeliness, attitude, and you might even have goals and other KPIs against which your performance is evaluated.

Imagine doing the same thing with your products. Imagine sitting down and giving a performance review to your dishwasher, your smartphone, the hotel you just stayed at, or that website you’re interacting with. What elements of a performance would you talk about?

Those elements are outcomes.

This image depicts me giving a performance review to my dishwasher. This is what it looks like to take an analogy too far.

Outcomes and JTBD

Ulwick makes a pretty compelling argument that when you develop a product, you should establish what “outcomes” the customer is looking for, and then focus your efforts on improving those outcomes.

“In other words, companies need to figure out what jobs customers want to get done and how they measure success in getting a job done before they can determine what solutions customers want.” — Tony Ulwick 

What Customers Want

It seems pretty damn obvious, and to some extent, it is.

ODI, or Outcome-Driven Innovation, is a framework for innovation

It’s not all that different than Quality Function Deployment. QFD takes customer needs and maps them onto product specs. It’s a framework that helps the developer to clearly consider which benefits are most important to the customer, allowing them to design accordingly to maximize benefit.

Let’s continue to unpack this concept in the next section.

10c. How to Find Outcomes

Ulwick says that for even simple jobs like “drinking a milkshake” or “using a handheld saw,” there are likely 50–150 outcomes that consumers use to measure performance.

And that number can grow for more complex jobs – jobs like “teaching someone about product development through a series of quick funny posts,” which seemed easy at first, but is actually a lot more complicated and time-consuming than you realized!

150 outcomes for using a g-damn hand saw. How the F are you supposed to identify all of them?!

Identifying Outcomes

I wouldn’t say that Ulwick offers a novel insight into how to discover outcomes. It’s pretty much as simple as this:

• Market Research
• Design Thinking type ethnography
• Consider the entire process of acquiring and using the product

Let’s go through those in reverse order because, well, no reason…that’s just how it came out when I wrote it.

Consider the Whole Process

First, break down how your customer will interact with the product. Think REALLY wide. How will she first learn about it? How will she dive deeper to learn if it’s right for her? How will she test or sample it? How will she buy it, unpack it, and set it up? How will she use it? Maintain it?

See what I mean? Think about every step. This step is the customer journey.

Now, within each of those steps, start to discover outcomes. You can do this by guessing, but realistically, you should probably talk to the customer!

Market Research

What Customers Want will not introduce you to some novel way of talking to customers. It’s the basics. Interview your customers. Talk to them in groups and individually.

Ask for input without leading the customer toward a particular agenda or thesis you might personally have; don’t bias your interviews.

But you’ll also have to prompt people.

In many instances, Ulwick says customers don’t even know the outcomes they’re measuring until you help them discover them. You may need to prompt the customer more and more to discover the outcomes she cares about.

Design Thinking

Ulwick also advocates the Design Thinking approach to observing customers in their natural habitat. Recall we call this anthropology or ethnography.

We’ve talked about Design Thinking extensively already, so I’m not going to cover it again.

In Summary . . .

The main point here is that Ulwick’s approach — using Jobs and Outcomes — is a new perspective and framework.  Still, it doesn’t necessarily introduce some new-fangled method for learning about your customers.

Learning about your customer’s needs, or learning about outcomes, requires similar activities

There’s no real hack for “getting out of the building” and learning about your customers.

10d. Defining Outcomes and Identifying Underserved Outcomes

Two more key things you need to know about outcomes (outcomes are how customers measure the performance of a product).

• Underserved outcomes
• How to spec a product using outcomes

What is an Underserved Outcome?

An underserved outcome has two qualities.

• First, it is an outcome that is important to the customer.
• Second, it is an outcome that is not being satisfied with current products.

Think of an underserved outcome as a glaring weakness in an employee.

“Joe Bus-Driver was hired to drive a bus, and while his overall work ethic is strong and he shows up on time, an important part of his job is not crashing his bus off of bridges, but unfortunately, Joe keeps crashing his bus off of bridges.”

Since “not crashing the bus ” is a metric you deeply value as the person who hired Joe to do his job, it’s an important outcome.

And since Joe is not meeting this outcome satisfactorily, then “not crashing the bus” definitely qualifies as an underserved outcome.

What to do about Underserved Outcomes?

Ulwick’s advice vis a vis underserved outcomes? They are incredible opportunities to add value.

Underserved outcomes are the biggest opportunities for innovation and added value.

Product developers should attack them.

Ulwick’s playbook is basically this:

• Identify all of the outcomes associated with a product’s performance in doing a job
• Identify how satisfied customers are with current products in each given outcome
• Focus on improving underserved outcomes with your new product

Again…sounds simple, right?!

Minimize or Increase Outcomes

Ulwick also advises that it’s best to define outcomes such that they can be minimized or increased.

Why? Two reasons. First, this helps distinguish outcomes from other generic constraints. “Cost less than $10” is not really an outcome — it’s a constraint.

Second, framing every metric to be minimized or increased is a way of soliciting input from your customers that does not introduce confusion or bias (for example, using the word “eliminate” in a survey instead of “minimize” might signal that zero is the target when it’s actually not).

Example Outcomes using this Minimize or Increase approach:

• Increase my ability to cut a straight line
• Minimize the amount of time I feel bored with nothing to do in my car
• Increase the feeling of connection I have with my friend
• Increase the entertainment value from a milkshake
• Increase the temperature of a cup of coffee
• Minimize the time required to make a cup of coffee.

Is That All?

We’re going to recap this section on Outcomes, What Customers Want, and JTBD in the next section, as well as provide additional links for further reading.

10e. What Customers Want Recap

Before recapping Jobs to be Done and Outcomes, I actually need to cover one last new thing related to Outcomes: constraints.

Constraints

A constraint is a requirement that must be met. It’s something that — if not met — would prevent customers from adopting your product.

For example, when shaving, a razor must be able to withstand a wet environment without rusting.

You could define this as an outcome — “minimize rusting” — but it’s really just a constraint.

“Must cost less than $10” might be another constraint on a razor. It would be weird to write this as an outcome. It’s really just something that would otherwise entirely prevent a customer from adopting your product.

That’s all. The key idea here — don’t confuse constraints with outcomes.

Key Take-Aways from Outcomes, JTBD, and What Customers Want

Here’s the list

• Ulwick recommends thinking about a product as doing a job for you.
• The product’s performance is measured in specific outcomes. There are also constraints that just simply must be met.
• Identify the outcomes by breaking down the product experience and talking to your customers.
• Identify which outcomes are both important but poorly executed. These underserved outcomes present the biggest opportunity for new innovation.

And we didn’t discuss this, but it’s important: the insights that come from focusing on outcomes and JTBD are great for product development, but they are also fuel for advertising.

Outcomes are what the customer cares about, so when you advertise or promote your product, talk about outcomes! (Duh.)

In other words, JTBD and Outcomes are frameworks that should not only help you to develop products but also help you to advertise them more effectively.

That’s JTBD and Outcomes, Distilled! Further reading below if you want to dive deeper.

Reading on JTBD

Know Your Customer’s Jobs to be Done — Clayton Christensen

The “Jobs to be Done Theory of Innovation — Clayton Christensen

Milkshake Marketing — Clayton Christensen.

Marketing Malpractice — The OG JTBD HBR Article