I recently
found myself in a heated discussion with a colleague concerning the design of a new product. I usually agree with this person, who I consider to be very bright and who normally offers many good
ideas. In this instance, however, we didn't see eye to eye. I'd propose an idea, and she'd point out flaws in the approach and then present her own idea from a totally different perspective. At
one point, I felt she'd completely lost sight of the customer. I later reflected on this meeting and tried to understand our stalemate. At first, I thought our different
backgrounds must have been the problem, but then I had one of those brilliant flashes of the obvious: We had totally different paradigms on how to design a new product.
Years ago I experienced a similar impasse while developing a workshop with David Garvin of Harvard University. He and I had agreed to conduct the workshop together at a national health care
conference, and we'd allocated an afternoon to outlining the schedule and deciding who would teach what. It soon became obvious that one afternoon wouldn't be nearly enough time; we couldn't
agree on anything. David suggested that we take a break and think about what the real problem was. In this case, he had the blinding flash of the obvious: Both of us were fine
teachers, but we had totally different teaching styles. He started with a theory and then used examples and case studies to illustrate it. I did the opposite, starting with a story, an example or
a case study and then using theory to explain how this worked and finishing with a generalization of the theory. After discussing this observation, we proceeded quickly. Rather
than trying to integrate our methods, we split the workshop into two large blocks, and I taught one half while David taught the other. This way we could each use the teaching styles we were
comfortable with. Since then I've come to use both styles. Sometimes one seems more appropriate than the other for certain situations. In the case of the product-design
wrangle I first described, my colleague and I were working within different paradigms. Through the years, I've evolved my thinking to an extreme customer focus. Working at Bell Labs, and then
later at Juran Institute, with many clients, I've seen product-design methodology change completely. During the 1970s and early 1980s, Bell Labs, as well as most other U.S. design labs, was
technologically driven. We were so fascinated with our new technologies that we rushed forward with new products but spent little time learning what customers truly wanted or needed. In fact, for
many years, designers were forbidden to talk with customers; that was marketing's job. Some of our mistakes wasted hundreds of millions, even billions, of dollars. Notable examples include the
Picturephone and the original business information systems software. There's a wonderful museum of failed products in Ithaca, New York, full of examples of other companies' blunders.
But we all learned. Slowly the best U.S. companies became customer-focused. At Bell Labs, we reorganized the business information systems development effort and brought people from
telephone companies together with the proposed system's customers to work on the design teams. These people made up half of the development teams. They knew exactly what they needed and how the
system should work. As a result, the second-generation product was a smashing success. Those of us who've lived through this transformation in design methodologies possess
totally different thinking habits than those who haven't. My colleague and I were on different wavelengths: I was thinking of the customer and trying to define needs and wants. Once we had agreed
on what the new product would do, we'd start working on how to deliver it. After we understood the delivery methods, we'd start working on how we could produce the product. She was starting from
exactly the other end, focusing on how to produce the product and how to deliver it. The production and delivery problems she saw were leading her to define a different product, one for totally
different customers than I was thinking about. Many companies have formalized their changes in design methodologies by adhering to concepts (such as quality function
deployment) or, more recently, Six Sigma methodologies (such as "critical to customer"). These tools allow us to work through problems in standardized ways, with everyone focused on the same
problem at the same time. Despite these concepts, however, the communication problem my colleague and I experienced occurs frequently, and not just in the design arena. Those
of us who've learned new methods or approaches to problems often don't stop to think about other team members who approach problems in totally different ways. As a result, we create endless
arguments and misunderstandings. That's why I'm convinced that our new understanding of quality management and training is so important. Whether we call it Six Sigma or some other name,
standardizing our methodologies, training and language is critical for organizations to move forward quickly.
About the author A. Blanton Godfrey is dean and Joseph D. Moore Distinguished University Professor at North Carolina State University's College of Textiles. Prior
to his current assignment, he was chairman and CEO of Juran Institute Inc. E-mail him at agodfrey@qualitydigest.com . |
