Volume 1, #2, December, 2003
Toward Designing a Flawless Product
Integrating Voice of the Customer (VOC) into Design for Six Sigma (DFSS)
"The impulse to perfection cannot exist where the definition of perfection is the arbitrary decision of authority."
Raymond Chandler, "Writers in Hollywood," Atlantic Monthly (Boston, Nov. 1945)
Whatever your philosophical beliefs about perfectionism, you'll find a lot of buzz around the concept of "zero-defect" manufacturing these days. And why not -- after all, who wouldn't want to create a perfect product?
Six Sigma is a disciplined process that helps companies develop and deliver near-perfect products and services. The idea is: if you can measure the amount of rework (number of "defects") in a process, you can systematically work to eliminate defects to get as close to zero as possible.
Initially, companies implemented Six Sigma in manufacturing operations. Design for Six Sigma (DFSS) aims to apply the process performance gains of Six Sigma to the product design stage. We believe this is a crucial shift. Companies that have wrung all available gains from their Six Sigma manufacturing efforts can see considerable additional improvements by broadening responsibility for achieving Six Sigma to product development. Even more important, from our point of view, is enlarging the arena in which companies conceive of "zero defect" products. As we see it, the very first defect a company can build into its product is creating the wrong product in the first place!
This issue of Discoveries talks about Voice of the Customer (VOC), a process for uncovering customers' true needs. Think of it this way: it doesn’t matter how perfectly your product works, if you’re building the wrong product for your customers, they won’t buy it and the product will fail, or you will waste resources reworking the product after the fact.
In the following paragraphs, we’ll talk about a specific concept: Voice of the Customer (VOC), and how integrating VOC with DFSS can help companies create the right product and avoid downstream defects.
The first "defect" -- creating the wrong product
Some examples of creating the wrong product are glaringly obvious. The proliferation of Internet-related products in the late 1990s exemplified the "build-it-and-they-will-come" mentality that so often leads to product failure. For a host of reasons -- hubris, the anxious feeling that everyone else was moving faster and if you didn’t act you’d be left behind -- companies invested huge sums building products of no value to anyone. These were the obvious examples. A subtler case might involve a service company that seeks to create a product based on its services, only to find that the value to a handful of customers was indeed unique and cannot easily be translated to a larger target market. More challenging still is the case in which a company happens to have a successful product, but can’t extend that success because it doesn’t really understand the foundation of customer value.
To create the right product, you first need to have a good product portfolio management process in place. Then the team implementing DFSS needs to come up with CTQs -- critical-to-quality parameters. CTQs are defined by iSixSigma (http://www.isixsigma.com), an online information source for Six Sigma, as "the key measurable characteristics of a product or process whose performance standards or specification limits must be met in order to satisfy the customer." Then, you’d better make darn sure you’re meeting the targets. Integrating customer input (VOC) into the front end of DFSS helps you identify CTQs up front and prioritize features in a meaningful way. This ensures that you’re reducing defects from the start (and minimizing the need to rework your requirements down the road).
My favorite example of a case where this was not done well is the Newton from Apple. The Newton’s whole reason for being was to satisfy customers who wanted to enter information without typing on a keyboard. This key customer requirement translated into the handwriting recognition feature. Unfortunately, Apple rushed Newton to market and released it with very poor handwriting recognition. Given the feature’s central importance, Apple should never have released the Newton without achieving a certain quality level -- that they set beforehand -- related to that feature. They failed because the Newton did not provide value to the customer on the single feature of their product that was most important to the customer.
A little detour -- how do you hear the customer’s voice?
Listening to the voice of the customer -- the customer’s true needs -- seems pretty straightforward. The problem is that lots of companies believe they already know exactly what customers need. After all, executives schmooze with top customers, the marketing department conducts research, and many people inside the company used to work for the very same industries to which they now sell. The problem with these approaches is that they are neither precise enough nor rigorous enough. When we talk about "listening to the voice of the customer," we mean creating very specific and detailed interviews, conducting them at the customer’s site, and then analyzing the results meticulously translating the voice of the customer into requirements. "You have to take it beyond listening to the customer to the translation stage," says Lucia Buehler, Group Product Director at Ethicon Endo Surgery, a division of Johnson & Johnson. "If you don’t go further, to ask the customer why they want something, what problem do they think it will solve, then you’re going to end up with a literal list of desires that you can’t turn into meaningful requirements." Only by systematically obtaining and analyzing the voice of the customer can you be sure you have unearthed the customer’s true needs.
Integrating VOC with CTQ
DFSS makes use of a similar concept to evaluate customer needs. As mentioned earlier, a CTQ is a measurable product characteristic that must meet a particular standard or specification to satisfy the customer. In that respect, a CTQ is like the "what to do" column that results from analyzing the voice of the customer. In PDC's Market-Driven Product Definition (MDPD) process, when we finish analyzing survey results and can prioritize customer requirements, we can look at our solution in relation to existing solutions for a specific dimension. Then we can determine, using metrics, what the target is. For example, the CTQ or what-to-do might be "create a widget that is better than best-in-class." In the case of a medical device manufacturer, the target might be to beat the best in class in terms of effort required to use the instrument. Force per pounds or number of muscles used would become the metric, which in turn determines how the company measures success: Does the resulting device actually use less force per pound than the competition?
Internal vs. external mechanisms
Many companies use purely internal mechanisms for determining customer requirements. Although they do focus groups and other classical market research activities, they haven’t learned to empathize with customer sufficiently so they can truly determine customer requirements. They’re not necessarily looking at VOC. As we mentioned earlier, even large companies who are implementing DFSS often take a manufacturing-driven approach. The impetus to reduce defects begins with the introduction of Six Sigma by manufacturing. Once they have done this -- and it can carry them only so far, since some of the defects are actually design defects -- companies realize that they also can reduce the opportunity for failure in the design process. For example, perhaps manufacturing could not consistently achieve specified tolerances, leading to a low yield in manufacturing. So the company introduces DFSS in an attempt to increase yield.
Meshing the processes and avoiding paralysis
In an ideal world, companies should plan to implement DFSS, Six Sigma for manufacturing, and MDPD or VOC at the same time. In reality, that almost never happens. Reality is messy. Your VP of quality is trying to reduce manufacturing defects. Your VP of development is trying to institutionalize a product development process. You end up with two or three different processes, each with different terminology, different goals, and different end points, but all involving the same team members. This came to light vividly at a boot camp I ran for a medical device manufacturer. During the boot camp, someone stood up and said, "I’m a pilot for the product development process. First, they told me I have to use DFSS. Its terminology and checkpoints are different than what I’m used to in product development. Now you tell me I should be doing VOC. But my charter already tells me what I should be building!"
This is a classic problem in which two different methods of chartering a team collide. Companies put a lot of time and energy into creating a charter that tells the team exactly what to build. The approach in VOC is to charter the team to build something that solves a major customer problem. Instead of saying, your job is to build a two-inch, manually operated widget that operates within these tolerances, you say, your job is to build something that will help the customer achieve X.
The problem, of course, is that if you throw too much at a development organization -- too many varying goals, too many new demands -- one of two things will happen. Either they become totally dysfunctional and do nothing, or they revert to the old way of doing things. Either way, you aren’t gaining the value you are expecting. You have to work hard to integrate Six Sigma, DFSS, MDPD, into an operating structure in which all of the components will mesh and catch and play together.
Who is driving DFSS?
GE was probably the most famous implementer of DFSS in the 1990s. According to the book Design for Six Sigma in Technology and Product Development by Clyde M. Creveling et. al., "GE management did the most effective thing a company can do to move the benefits of Six Sigma upstream into their company’s strategic business processes -- they aligned the tools and best practices of DFSS with their product development process, and they did it with rigor and discipline." More and more companies are striving to do this -- in fact, the inclination toward this has reinvigorated the quality movement. The only way for these initiatives to succeed, however, is if they are driven from above -- high above. Why? Because the benefits of investing in DFSS are not immediately evident. The benefit can come from a much higher yield in manufacturing, but a product truly designed for manufacturability may take longer to develop and cost more in terms of the skills and resources needed. Enlightened senior management with a long-term view is needed to stay with these kinds of efforts.
"It’s not a problem, it’s a challenge."
Here are a few of the challenges companies face in integrating VOC and DFSS:
- Different constituents involved. As with many process changes, integrating VOC and DFSS involves politics, organizational finesse, and empathy for the various parties involved. These may include: a quality group implementing QFD, a product development process group trying to institutionalize a product development process (and feeling they’re going to lose control), a marketing group pushing to get VOC adopted. Further muddying the waters is the "religious" aspect of DFSS: we’re doing it the GE way, and there’s no other legitimate way. Finally, there is the challenge of standardizing the terminology so everyone is not only worshipping in the same church but also singing from the same hymn sheet.
- What’s our job? Introducing VOC to traditional organizations can be a challenge. Roles and responsibilities have to change. Traditionally, and often in DFSS projects, a team charter resulting from the portfolio management process was to implement -- to actually create a particular product or set of products. The assumption was that someone else had listened to the customer, synthesized the results, and determined the best product to build. Teams have to adjust to the fact that they will be handed not a product recipe but an illustration of the current gaps in the market, and it’s up to them to determine the best way to fill those gaps.
- Carry on in parallel. Although you shouldn’t spend a lot finding out what the customer likes and doesn’t like until you truly understand customer needs (by moving VOC work early in the DFSS process), you can still do a lot of research simultaneously. Activities such as rapid prototyping can go on while you conduct VOC work, enabling you to then quickly merge customer requirements, CTQ (metrics) and your target. You can then look at alternative solutions you’ve been developing in parallel and pick one that best meets the targets.
- Engineers haven’t allocated time in the process to VOC work. Engineers often see VOC as something that another group carries out, then hands off results to them. They need to recognize that if they haven’t participated in development of customer requirements, when marketing hands results over the wall, a lot of valuable stuff ends up on the ground. The only way to avoid this is to build in collaboration and share responsibility for developing requirements. That in itself can be a major hurdle.
- Market research is threatened. VOC -- and market-driven product definition more generally -- can threaten the market research department. In some cases, they may not feel competent to be able to lead the process. In other cases, they don’t have sufficient resources. They fear facilitating the gathering of customer data at the level required for true customer needs analysis will consume too much of their time. The reality is that the teams will learn the process as they use it, so market research won’t need to remain as involved through the entire the process. Rolling it out initially requires skills and requirements they don’t have, but in long term, it can be integrated.
Conclusion
While creating products with zero defects is un realistic, reducing defects -- and reducing reworking of product requirements midstream -- is eminently achievable by integrating VOC efforts with DFSS. This is not to say there aren’t challenges all around, from the hard work of gathering customer voices and translating them into meaningful requirements, to making sure everyone is speaking the same language, to ensuring that team members accustomed to operating in isolation, silo-fashion, don’t feel threatened by their new role in and accountability for developing requirements. If you can overcome these obstacles, however, the payoff will come in opportunities to create products that are better aligned with market needs and, as a result, are more profitable.
