News Stay informed about the latest enterprise technology news and product updates.

'Understanding the customer is the wrong unit of measurement'

CIOs often are advised to think of their users (a sleazy term if there ever was one) as customers. Harvard Business School professor Clayton Christensen has news for you: “Understanding the customer is the wrong unit of measurement,” he informed CIOs at the recent Gartner CIO Leadership Forum in Scottsdale, Ariz., on disruptive innovation.

Christensen, author of The Innovator’s Dilemma, offered the following story to show why he feels that way: He and a colleague were hired by a well-known fast food chain to find a way to boost its sales of milk shakes. The chain asked the people who purchased its milk shakes — aka focus groups — for suggestions on how it could improve the shakes so that customers like them would buy more.

“They got clear feedback,” Christensen said. The chain duly improved the product per the customers’ suggestions, but this turned out to have no effect on sales or profits. Understanding the customer was getting them nowhere.

Companies, and by proxy, CIOs, explained Christensen, typically define the markets they serve by customer category or product category: low-, middle- and high-income households, for example; or compact, midsize, full-size and luxury cars. They can win a product category by making a better thingy than everybody else. Based on market research, they develop products for their average customer (and hope the outliers will buy it too.) If you are a customer, Christensen postulates, you don’t think of yourself as a category: “Stuff just happens to you, and you hire products and services to do jobs for you.” Understanding the customer (in the traditional sense) is the wrong unit of measurement.

“My colleague and I decided the fundamental question was, ‘What job are customers trying to do when they come here to hire a milk shake?'” Christensen said.

To answer this question, Christensen et al. manned the fast-food restaurant for 18 hours, taking data on everyone who bought a milk shake: what time they came in, what they were wearing, whether they were alone, whether they bought the milk shake with food, and so on.

They discovered that about half the milk shakes sold were bought before 8 a.m. The milk shake was the only thing these customers bought. They were always alone, and they always got back into a car with the milk shake and drove off. So, what job were these early birds hiring the milk shake to do? As it turned out, they all had the same job: a long, boring drive to work. They needed something to do while they were driving to keep them interested, Christensen relayed.

The chain’s viscous milk shake took 20 minutes to suck up through a straw. The customers were not particularly hungry when they bought the shake, but knew they would be by 10 a.m. “‘Who cares what the ingredients are?’ they said. ‘All I know is that I am full all morning, and it fits right into my cupholder,'” Christensen said.

Peter Drucker was right when he said that the customer rarely buys what the company thinks it is selling, Christensen told the CIOs. He suggested that CIOs try the following: Rather than think about their IT products and services in terms of product or customer segments, or customer reports, they should figure out the job their customers are trying to get done, figure out how to get the job done perfectly, and design and buy accordingly.

It’s not products that make a company [read: internal IT shop] very hard to compete against. After all, those are easily copied, Christensen said. Instead, it is providing experiences that customers can use.

I thought that was useful advice, and so did many of the CIOs in the audience, as today’s story on the CIO’s dilemma shows.

And the fast food chain’s dilemma? Why I should care, I don’t know; but it occurred to me that it could expand its customer base for milk shakes to people on long trips by increasing the size and narrowing the straw.

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

I'm not entirely sure I understand the question. If you are asking whether retrospectives can be a useful tool for identifying what went well and what a team might want to change, my answer would be 'maybe'.

It depends a lot on the dynamics of the team and how well they do or don't interact together, the information and experiences shared in the retro, and how interested the team is in using that information for changing aspect of how they work on the next iteration.