2004 Product Development Management Columns

 

Should Product Specifications Be "Frozen?"

A decade ago, most product developers agreed that a product specification should be written at the beginning of development, "frozen," then adhered to. This follows a basic management principle of say what you'll do, then do what you say. Increasingly, however, we are finding that frozen specs are neither practical nor wise.

First, the practical side. Don Reinertsen, in the May 2003 issue of PDBPR, revealed that fewer than five percent of developers have complete specifications when they start designing, and he has amplified on this finding at Management Roundtable conferences. Reinertsen's data come from over 500 developers in a broad range of industries over a ten-year period. Why do developers do what seems so contrary to good practice? If they waited until they had all the answers, they would be late to market.

Alan MacCormack, a professor at Harvard Business School, revealed even more astounding data at a recent Management Roundtable conference (see also the August 2003 issue of PDBPR). He studied the Internet software industry, which is subject to high market uncertainty. He found that the products that were most successful commercially were the ones where the developers didn't try to define the product in advance but instead put an early beta version of their best guess into developers hands and then were prepared to modify it based on user feedback. Ironically, senior managers at the companies using these early betas judged these projects failures, because they were chaotic to manage. But if you judge them based on commercial success, the picture changes completely.

Now let's look at the wisdom of freezing the spec, even if it were possible to do so. I recently worked with a project team developing a robotically controlled vehicle. Based on customer needs, this organization, following good practice, wrote a specification using a multifunctional team. Among other things, the specification called for a 15 mile-per-hour speed capability. It turned out that although the customer wanted it, the 15 mph was devilishly difficult for the designers to achieve. Normally, being "team players" and good engineers, they would have worked doggedly to make it go precisely 15 mph

In this case, however, the organization wisely chose to have the marketing member of the team lead it. Unlike other teams at this company, where engineers led the teams and they worked in relative isolation from marketing, this marketing member was intimately involved in the team's design progress. Seeing the engineers devoting a great deal of time to the speed capability, he reassessed the vehicle's mission and found that it could function acceptably at a lower speed. This allowed the engineers to proceed with other features that were more important to customer satisfaction. Thus, this team was also able to develop a product with higher market value while saving both time and money in engineering labor.

A word of warning. There is a price to be paid for this apparent win-win situation. In the case of the robotic vehicle, not only was the organization reluctant to repeat this success, it pulled the marketing member off the team before the robotic vehicle project was complete. Why? The marketing member was spending 60 percent of his time leading the team, which meant the he wasn't spending 60 percent selling products - his defined job. Until this firm redefines marketing's job descriptions, they are unlikely to repeat their success.

I believe that this simple case study illustrates where we stand today regarding frozen specs. Although the evidence is mounting that they are not very effective, many organizations are unwilling to depart from a comfortable command-and-control, say-what-you-will-do, then do-what-you-say approach.

In short, the flexibility needed to operate effectively in today's dynamic world comes at a clear price in organizational change.

Return to top  |  Return to Publications  |  Return to Home