Preston Smith's Corner

Revisiting Iterative Product Development

1999 Product Development Management Columns

As product developers have gotten more sophisticated, they have often worked to get away from developing products piecemeal. Nowadays, they do more planning in the fuzzy front end, they visit customers early in the development cycle, and they define the proposed product more clearly before they start designing.

Consequently, it may seem strange that I would propose returning to “old” ways. However, this is exactly what software developers have been doing over the past few years. Software development projects have been notorious for yielding buggy products, slipped schedules, blown budgets, and, in general, commercial failures. The blessing disguised in all of this is that the situation was so unacceptable that a great deal of effort has gone into software development methodology over the past couple of decades. Their solution, for many years, was a “waterfall” process, in which one phase spilled into the next phase in a well-defined but sequential progression. This gradually weaned developers away from an undisciplined hacking approach to coding.

The hardware-development equivalent of a waterfall process is a stages-and-gates process, which is the basis of most companies’ hardware development processes today. In fact, research by Robert Cooper, among others, suggests that a gated, sequential process is an earmark of successful product development.

Meanwhile, software developers are moving from their waterfall process to an iterative process. This is quite different than hacking, however. Iterative software development follows a discipline:

There are generally three to six preplanned iterative loops.

  • The first loop provides only the most basic functionality.
  • Successive iterations yield versions that have additional features and options or are more robust or fault-tolerant.
  • Each loop results in executable code.

Initial iterations are planned to:

  • Assess high-risk areas (for instance, a new technology)
  • Get basic functionality into users’ hands to test assumptions
  • Initiate long-lead-time items (for example, enclosure tooling, in the case of hardware)

illustration of iterative development

Lest we give the software folks too much credit for this revolutionary approach, we should note that they had a powerful ally in the object-oriented programming techniques that have come into use recently. Such objects (more precisely, classes) are built to be self-contained, employing standardized interfaces. This makes it far easier to develop systems iteratively once certain initial architectural planning has been done.

An iterative approach can also be used for hardware products. For example a motor vehicle manufacturer develops new products using what they call generational prototypes. These start out as crude models with many parts borrowed from existing or competitive products. Through each generation the prototype gets closer to the final production model.

The advantage of the iterative approach is that it provides opportunities to learn earlier and faster. This learning is particularly valuable when the project involves high technical risk or when subjective consumer or user factors are at play. Because product development is basically just a process of learning, increasing the rate of learning has much to do with time to market.

Iterative development depends on having a modular product architecture, which allows modules to be pulled out and replaced by other modules. Such modules are central to object-oriented software, but they can be arranged in many hardware products also with some thought. However, these modules also have their price. Although modules and iterative development are wonderful tools for accelerating product development and for adapting products to changing customer needs, this approach is not ideal when lowest unit manufacturing cost is the goal. In this case, a sequential process using an integral architecture will be cheaper.

One last observation. What iteration really provides is flexibility. This can be a blessing in changing markets and technologies. It can also be a curse if it is abused, for example, by routinely avoiding making decisions just because iteration facilitates procrastination.

For more on product architecture, see Chapter 6 of Developing Products in Half the Time, and to determine whether cycle time or manufacturing cost is driving your project, see Chapter 2 of the same book.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

Learn about our other services

For more information, contact:

Mary Drotar, Partner

Strategy 2 Market, Inc.


or complete this contact form

Note: As this is an archive of Preston’s New Products Dynamics Website, some off-site links may no longer exist.

Scroll to Top