If your IT shop is "customer-driven," you may have to haul it in for a tuneup. That's the message from Anthony W. Ulwick, CEO at software and consulting firm Strategyn, in this month's Harvard Business Review, where he explains the dangers of developing products and services based on what customers say they want. Ulwick talked with Computerworld's Kathleen Melymuka about how to determine what customers really need.
Q: You dare to question the vision of the customer-driven company?
A: Although the vision is worthy of pursuit, companies are often confused about what it means to be customer-driven. Many companies think they are customer-driven because they give their customers the features, functions and solutions they ask for. This is not being customer-driven; it is being customer-led.
Being customer-driven requires a firm to understand what the customer is trying to achieve and to devise features and solutions that deliver the greatest degree of satisfaction features that may be outside the customers' knowledge base and beyond their initial comprehension. After all, how many customers initially asked for transistors, a 32-bit architecture or fax machines?
Q: Why is it dangerous for an IT project manger to listen to customers too closely?
A: It is important to listen closely to the customer, but the trick is to know what to listen for and what to ignore. Since customers are rarely accomplished programmers or engineers, or familiar with the latest advances in technology, their ideas are often confined to something they have seen before maybe in other products. Giving them what they ask for is likely to result in a "me-too" product.
A qualified programmer is more likely to devise a breakthrough solution, but only if the customers' desired outcomes are understood.
Q: What is the input you really want from your customers?
A: You want them to tell you everything they are trying to achieve when using a specific application, product or service what we call their "desired outcomes." In the software environment, you typically obtain at least two sets of desired outcomes: one on the function of the application itself and the second on the software interface.
In some cases, you may want to obtain desired outcomes on the architecture as well. When discussing the interface, for example, users' desired outcomes may include quick access to all options, minimal exposure to unnecessary functions and quick recovery in the event an input is made in error. Their desired outcomes may be satisfied with a drop-down box, hidden menu items and an "undo" button. Typically, customers have anywhere between 25 and 100 desired outcomes.
Q: You describe a methodology for focusing on the outcomes customers desire rather than on the solutions they think they want. How do you plan an outcome-based customer interview?
A: The objective is to capture a complete set of the customer's desired outcomes. To achieve this objective, it is important to interview the most diverse set of customers. This may include users in different occupations, assignments, locations or positions, or customers that use the product for different purposes or in different environments.
Q: What's the role of the moderator in customer interviews?
A: The moderator's role is to ask the questions needed to uncover the customer's desired outcomes, listen carefully for the customers' desired outcomes, and document and validate the outcomes with the customers. More than anything else, the moderator must be a good listener.
Q: Describe how a good moderator might turn a vague customer statement into something useful.
A: Let's use the interface as the example. The user of an application might say, "I want a drop-down list that shows me all the files I recently accessed." The moderator may ask, "How will this feature benefit you?" The user may say, "The list will make me more productive." The moderator may dig deeper by asking, "How would this listing make you more productive?" The user may respond, "Well, it would make it faster for me to access the files I use all the time."
The moderator may conclude with, "OK then, would it be fair to say that your desired outcome is to minimize the time it takes you to access the files you use most often?" With the user's confirmation, this would be accepted as an outcome.
If this level of understanding were not available, the programmer would most likely have given the user a listing of the files recently accessed. [But] the operations performed most recently and those performed most frequently are two different things. Many products today fail to make this distinction.
Q: Does a moderator require special training?
Yes. Success is dependent on some basic knowledge and practice. The moderator must know the difference between an outcome and a solution and be able to focus specifically on the collection of desired outcomes. Since the natural tendency is to focus on solutions, this may take a little time. A successful moderator must be able to let the customer talk through a situation to identify the actual desired outcome.
Again, the key is to be a good listener to know what to look for and what to ignore.