I have written this book to enable you to develop more successful products and services and to do so consistently. I have used the qualifier "more" because, since you picked up this book, you probably already do develop products that succeed in many ways. You may want more customers, or stronger customer loyalty, or fewer unprofitable products. To Satisfy and Delight Your Customer can help with any of those desires, but it doesn't intend to be a substitute for good engineering and manufacturing; it does describe a detailed, sensible process to get the best from your talented people, enabling you to develop products that will succeed. The process has two core elements: It helps you get the best from teams, and it enables those teams to base design choices on detailed customer benefits.

I'm a physicist. That's an odd background for the author of a book about satisfying and delighting customers. My interest started with eighteen years in research and development at Rockwell International's Science Center. Over those years, I moved from research on post-manufacturing inspection to process control to design to studying the customer. That sequence of interests followed the widespread recognition in the quality world that corrections are more effective and less expensive early in the product development process.

Along the way, I managed and watched others manage complex projects involving people in different companies, in different disciplines, and with different goals. At times, I saw people from marketing, engineering, and manufacturing struggle with conflicting objectives such as salability, performance, and manufacturing cost without a way to find the best combination. I also occasionally saw talented, committed people become disappointed and frustrated by projects whose failure could have been foreseen and prevented if they had understood the customer's real interests.

In response, several colleagues and I began to look for better product design methods. We recognized many potential benefits from concurrent engineering, which began as a method for teams to design a product and its manufacturing processes simultaneously. This method enabled teams to develop a product that was easier to manufacture and that was, therefore, of higher quality and lower cost. Today, concurrent engineering has come to mean any development method in which a team designs product and process together to best meet all the issues that influence the customer during the product's life.

In looking for effective ways to do concurrent engineering, I spent five weeks in 1989 as a guest at Fiat's Central Research Laboratory. Fiat was one of the two largest car manufacturers in Europe at the time and was itself searching for ways to defeat expected Japanese competition. There I discovered a method called Quality Function Deployment (QFD).

I immediately saw two immensely valuable characteristics in QFD. First, QFD focused on customer benefit. That principle appealed to me. Second, QFD provided people in marketing, engineering, and manufacturing a systematic process to reach consensus on detailed decisions. It was the structure I sought for concurrent engineering. I learned Quality Function Deployment, applied it, taught it, and shared it with other colleagues in other divisions of my company and in other companies.

I learned from all of them. As I gained experience, I discovered problems: how strongly QFD depends on thorough, accurate knowledge of the customer, how difficult it is to compare alternative designs, and how easily a team can drown in details. I constantly asked myself, "Where does this task or this process add value? What enables the process to succeed? How can it be more useful?" I found solutions to those problems, and I share them with you in these pages. I believe in QFD more than ever, and I hope you will, too, by the end of the book.

Before I turned to QFD, I was a theoretical physicist. Theory in physics does not mean, as is popularly supposed, "wrong" or "irrelevant," though it and I have often been one or both of those at various times. It means, rather, an effort to develop methods to predict future experience from past experience. Since no situation exactly matches any previous situation, we are all theorists. We differ, as theorists, in our subject matter, in the boldness of our goals, and in our success at recognizing what matters and what does not.

This book reflects my theoretical preferences, my desire to understand and explain why something matters and something else does not. This may be unwelcome to some readers. It is my impression that readers usually want an expert to provide a specific, detailed formula for success, but my experience that a rigid formula will break down easily when confronted with the inevitable variations of the world. So I have tried to meet both needs by providing a clear process, accompanied by an explanation of the reasons for each component of that process to let you adapt it to your own world.

I have worked hard to make this book accessible to all of you, across a wide range of types and sizes of business. I have tried to reduce the mystery by being explicit, by mentioning when a practice isn't based on rocket science, and by telling you what things can be changed and what you will gain or lose. That's a tall order, and I know I will have failed here and there. My Internet address is 71064.3573@compuserve.com; tell me what you liked and what you didn't.