Once upon a time, the Universal Spaghetti Sauce Company's management began using cross-functional teams to design new spaghetti sauces. Supersauce was the first team to use this approach. Its sad story started when it met to develop a specification for its product.
Marketing noted the fast growth of both the vegetarian and meat-lovers segments and aimed to be the first company to bridge the two. Finance said the cheapest ingredient was water and suggested increasing its quantity. Engineering claimed more water would change the consistency of the sauce, but adding corn starch could counteract it. Manufacturing favored this, saying tomatoes were hard to handle and that cheese attracted mice.
After long hours of negotiation, all agreed on a new specification. Each group won on certain issues and lost on others, but everyone felt a balanced set of compromises had been made.
Unfortunately, the resulting product failed to satisfy customers. It had too much meat for the vegetarians, but too little for the meat lovers, and too many artificial ingredients for the health-food fans. And, it was too expensive for customers who wanted a cheap meal. The team was puzzled by how its consensus process had produced such a bad outcome.
To understand what happened, we must distinguish between two types of problems we face in product development. Smoothing noisy data is the first type. By averaging the estimates of 100 people for the U.S. population, we're more likely to get a correct answer than by using the estimate of a random individual. In such circumstances, consensus works in our favor.
The other type of problem occurs when the value of the outcome is determined more by the degree of alignment between multiple decisions than by the exact direction in which they're aligned. For example, one can contrast the tight alignment of design decisions on the Palm Pilot PDA with those made on competing devices based on Windows CE. The Palm Pilot combined simplicity of operation, long battery life, and reliability, while Windows-CE PDAs were feature-rich, complex, unfocused, power hungry, and unreliable.
Nowhere is this tendency of consensus producing bad decisions more dangerous than in the product specification process. Although groups have advantages over individuals in terms of collective intelligence and available information, they virtually never achieve the same degree of alignment. Because most products are designed for segmented markets—those composed of individual segments, each with a different need, value, and preference—alignment is critical.
In such situations, we don't want an unbiased design, but rather one that's tightly aligned toward a specific goal. For example, an imperfect sports car sells better than a car that perfectly balances the characteristics of a minivan with those of a sports car. Blending the needs of different segments together frequently produces a design that meets the requirements of none.
How can you maintain design integrity when you must use a group to define requirements? First, anchor the design on a real customer who represents the segment for which you're designing. Next, define clear functional performance benchmarks to guide design tradeoffs. Also, make sure the ultimate responsibility for design integrity lies with a single individual. In product development, too many compromises can lead to a compromised design.
Reprints
