Why a McDonalds Milkshake Story Should Reshape Your Custom Software

When fast-food powerhouse McDonald’s wanted to increase its milkshake sales, they did the seemingly sensible thing—researched milkshake-buyer demographics, built focus groups, and collected input from customers about everything from taste, to viscosity, to price.

They implemented the changes recommended by their customers, sent “better” milkshakes out into the world, and waited for sales to spike. Instead, sales remained bewilderingly the same. There was no significant increase or decrease.

What went wrong? According to Harvard Business School professor Clayton Christensen, they began with the wrong question. McDonald’s had asked its customers what they liked about milkshakes. But they failed to ask why they were buying them.

Understanding the “Jobs to Be Done Theory” 

Understanding the motivations for customer choices—the why behind the what—is the central theme of Christensen’s 2005 paper, “The Cause and the Cure of Marketing Malpractice.”

In it he states, “When people find themselves needing to get a job done, they essentially hire products to do that job for them… If a [business owner] can understand the job, design a product…to do that job, and deliver it in a way that reinforces its intended use, then when customers find themselves needing to get that job done they will hire that product.” 

In other words, if you need a quarter-inch hole in a piece of wood, you’re likely to “hire” a drill with a quarter-inch bit to take care of that job. But if someone designed a phone app that could zap holes of any size into pieces of wood, would you still go out and buy a drill? Probably not. You would choose to “hire” the app for the job of making holes.

A company could pour millions into designing the most amazing drill ever made, market it beautifully, and people all over the world would continue to happily zap holes with their phones, because no one ever really wanted a drill. They wanted holes.  

This outcome-driven theory is known as the “Jobs to Be Done” theory (“JTBD”) because it’s built around a central question: What is the job a person is hiring a product to do? What is the job to be done? In the realm of software, the JTBD could be timely communication, making data available to those who need it, or reducing friction within transactions, to name only a few.

But pinpointing the real job that a product is hired to do can be elusive, and asking the wrong questions is a fast way to arrive at a wrong conclusion. McDonald's erroneously thought the job to be done was improving their milkshakes. How can you prevent a similar mistake in your organization?

Understanding Customer Needs: Decoding the Milkshake Mystery

When McDonalds hired Christensen to sort out their milkshake mystery, his team started without any assumptions. They stood in a McDonald’s restaurant for 18 hours, taking careful notes about every customer who bought a milkshake. They wrote down the time, what the customer was wearing, who they were with, whether they dined in or ordered take-out, and what else they bought. Essentially every detail was recorded.

Soon, patterns began to emerge. Over half the milkshake sales were made before 8:30am. The customer was alone. They didn’t buy anything else, and they took their milkshake to their car and drove away. 

The next day, Christensen’s team went back and began asking the morning buyers why they were buying milkshakes. What job did the milkshake do for them? Turns out, these customers had one thing in common: a long, boring commute. They needed something to interact with as they drove and wanted to feel full until their first break. Other snacks were consumed too quickly or caused a mess. On the other hand, the milkshake lasted for the whole trip and fit right in the cupholder. It accomplished the job they wanted done better than other options.

Who could have predicted that McDonalds wasn’t competing with the chocolatiness of Burger King milkshakes or the viscosity of Wendy’s Frostys, but were instead competing with the convenience of bananas and the satisfaction of snickers bars? 

Why Demographic Data Isn’t Enough: Deciphering Customer Behavior

This brings to attention an important point: demographic data alone cannot accurately determine a customer’s intent. A person’s needs drive their behavior, even within structured environments.

For example, if the database your organization uses is old and difficult to navigate, people may resort to using post-it notes to store information. The JTBD for them is, “have the information I need at hand for when I need it.”

If a post-it note does that job better than your company’s software, it’s time to make a change.

Identifying User Intent for Better Product Development

Identifying the intent of your users is the first step towards building a better product, and that starts with empathy. Whether you’re a CEO, a manager, or a UX designer, if you want to be effective at your job, you need to identify their job. You have to discover what need, desire, or objective they hope to satisfy.

Far too often, businesses will rush this fundamental research phase and dive right into applied research, the way McDonald’s did. They will identify and propose a problem statement, but without proper fundamental research the problem statement is filled with assumptions, and applied research (the expensive stuff) heads toward a likely dead-end road.

Crafting the Right Problem Statements for Outcome-Driven Solutions

A team might form a problem statement such as:

There is no drop-down option to indicate the status of a task.

This seems straightforward, but what is the real JTBD here? Is it to label tasks with their status? Or is it to move tasks forward to the next stage? A better problem statement could be:

We need an efficient way to communicate to the next person in our workflow that a task is ready for them. 

The second problem statement is open to an array of possible solutions, whereas the first is extremely limited.

Imagine working off of the first problem statement, spending the resources that it takes to develop and integrate a new feature into the system, only to discover that while a dropdown is convenient for the person finishing the initial phase, the next person in the workflow must login to a system that they don’t actually use just to see the status of a task. This is not a particularly efficient solution, and probably did nothing to address the actual JTBD, which is effective communication.

To be truly outcome-driven, it is important to check for assumptions in your problem statements before talking to your stakeholders. They are eager to share their stories of pain and success, but what they actually tell you will depend entirely on how they are prompted. Forming robust problem statements will allow you to test solutions that address their actual needs and contribute to improvement across company systems. 

Helping You Achieve Your Goals

Jobs that need to be done encompass everything from large organizational goals down to specific smaller tasks, with many other JTBDs in between.

In light of those insights, at The Smyth Group, we pride ourselves on avoiding assumptions by asking the right questions. We build tools to help clients make achievements on the way to accomplishing their goals. We can help you assess the problem areas in your system, identify the JTBD, and develop a custom software solution for your business.

If you would like to learn more about our process and how we can help, please contact us for a free consultation.