Product Development Process and Time to Market

Too often, we think that rapid, effective product development is simply a matter of having a good product development process. Although the process is important, it is only the map for the journey. We also need a clear, stable product specification; an effective, empowered, time-to-market team; consistent, stable staffing; an effective means of identifying and resolving project risk; and other processes, such as procurement and production, that dovetail well with product development.

Here is some guidance on building an effective product development process. Our experience here is quite similar to that of consultant Bob Neel, who wrote of the "Seven Sins" of concurrent engineering processes  in the Fall 2000 newsletter of the Society of Concurrent Product Development.

Your procedure needs to be flexible and adaptable, because every project has different needs. You can determine the project's objectives through an economic analysis (Chapter 2 of Developing Products in Half the Time). If the process isn't flexible, you will be doing unnecessary work on each project --  especially the small ones -- which is bad news for the schedule and the budget. A rigid, bureaucratic process also encourages developers to go by the book when they should be using their own judgment. To encourage independent thinking, call it a guideline rather than a procedure. See pages 171-173 of Developing Products in Half the Time for an example of a flexible process.

To be "lean," the guidelines must be written by your best developers, who know from experience just what should be in them. If people from departments such as quality or regulatory write them, they will look impressive but will not fit the way that the work is actually done. By having the actual developers write them, ownership and usage will be stronger too.

However, make sure that your guidelines are cross-functional in scope and are created by individuals from key departments. Bringing innovation to market is not solely an R&D function.

Don't assume that the guidelines will be right the first time you write them. Run some pilots or "beta tests" (see Chapter 15 of Developing Products in Half the Time) before you institutionalize them or train you staff broadly in using them.

Keep your guidelines short. A five-cm (two-inch) thick book is intimidating, especially to your most creative developers. This will led to disuse. Write them in everyday language and an active voice. Publishing only an online version will make them less intimidating, because users will see only the page that they currently need.

However, provide lots of hands-on help, such as examples, templates, and references so that newcomers know what is expected.

Lastly, regard your guidelines as dynamic and update them regularly (see our article on continuous improvement).

Chapter 9 of Developing Products in Half the Time offers additional information on establishing an effective product development process or refer to our other publications. Also consider the downsides of stage gate processes. And remember that in the end, appropriate, motivated people are more important than even the best process.