"A digital cup that can tell me what is in the cup, how many calories, and allow me to drink it?" .. harpoons Stephen Colbert, the late night Comedy Central comedian in his July 14, 2014 show. He then checks on a smart phone and says, "a level of information that was previously available only on the can you poured it out of….. This $199 cup took seven years to develop, longer than the time between JFK's call to put a man on the moon and the Apollo 11 landing!"
Colbert then announces his solution to the other half of the hydration equation, an e-toilet that "handles all your 1.0 and 2.0 downloads."
You can view the funny episode on youtube by clicking the image below (preceded by a short commercial).
July 2014 Stephen Colbert show @ Comedy Central. Click the image to watch the episode on Youtube
Dr. Akao, co-founder of QFD, called this "product-out" thinking, rather than "market-in" thinking. While he was not preferring one to the other, he was explaining that the QFD approaches were different.
To address product-out projects, we use Reverse QFD to first identify key customers and their needs, and then "market-in QFD" to fine tune the product so that it adds value, i.e., satisfies important customer needs better than the alternatives. (You can find more about Reverse QFD from a 2007 Symposium case study "Using QFD to Involve All Employees in the Corporate Innovation Process").
Comedy aside, a cup that can chemically analyze its contents in real time could be a valuable tool to manage water quality, inspect for leaks, identify concentrations of mixes, measure radiation in water, and similar applications. And if it could do so remotely, such a device could be located in places too toxic for people, and still communicate results to users.
What is critical in both product-out and market-in approaches is to separate product features from customer needs. This is true for both voice of engineer (product-out) and voice of customer (market-in). Both groups tend to mix them together, the result being a weaker QFD and a weaker product. In the cup example, its liquid identification sensors and algorithms, its wireless communications, its shape and design, and so forth are all features.
So how do you get customer needs when all you have are product features?
In the 1994 English edition of Shigeru Mizuno's and Yoji Akao's 1978 seminal work on QFD, "QFD: The Customer-Driven Approach to Quality Planning and Deployment" (Mizuno, Shigeru and Akao, Yoji ed., 1994, Asian Productivity Organization Tokyo, translated by Glenn Mazur), Dr. Akao explains:
"… even when a customer specifies a certain characteristic value, the wants underlying the specified value (that is, why the value was specified) must be understood. If a means of implementation or measure has been specified, the demands underlying why such a means or measure must be captured." (p. 337)
Simply put, when you have a product specification, functional requirement, or feature, you must capture why it is wanted. The best way is to ask the customer, but the development team can do this, as well. The key to the analysis is to get to product-independent benefits that solve a customer problem, enable a customer opportunity, or enhance the customer's image. We call these benefits "customer needs" in modern QFD.
Why are customer needs important to capture? Here are a few important reasons.
Most VOC (Voice of Customer) statements are problem complaints on feedback surveys or customer reviews. They attack a single problem, most of which can be addressed with simpler tools such as six sigma's DMAIC process. For example, to address a customer complaint that a hotel room had dirty carpeting, the hotelier could clean or replace the carpet.
There may be innovative solutions to a customer need, but responding to a customer demand for a product feature can limit thinking to the current paradigm. For example, a café customer may ask for a "hot cup of coffee" which is a specification, not a need. If we capture the customer need of "I am cold and I want to warm up" we have other solution paradigms besides the coffee temperature such as adding whiskey or a spice to the coffee that can warm up the customer regardless of temperature.
We could deliver the VOC and fail the need. In the coffee example, if the coffee were too hot, the customer would be unable to drink it and thus remain feeling cold.
Structuring customer needs with customers helps them to identify missing and latent needs.
Accurate prioritization requires domain knowledge. Since we (producers) are more knowledgeable about product specification, functional requirements, and features, customer prioritization of these is going to be less accurate than us. Conversely, customer prioritization of customer needs where they are more knowledgeable will be more accurate.
Whether you are using Classical House of Quality, Reverse QFD, or Modern Blitz QFD®, remember that Voice of Customer (VoC) and Voice of Engineer (VoE) must be translated back into product-independent customer needs. This will assure your QFD analysis is clean and consistent, resulting in more efficient team work, better documentation, and of course, more satisfying products and services.
This process works nicely with new Software QFD approaches as well, such as collaborative QFD and continuous QFD, the important aspects of Cloud Computing. The process discussed here is also included in the ISO 16355 being drafted for QFD.
Specific tools for capturing and translating VOC correctly into Customer Needs are taught in QFD Green Belt® program. For questions, please contact us.