I recently had the chance to attend The Management Roundtable’’s conference on Fast and Flexible Product Development. Conferences are great ways to tap into the zeitgeist of the product development community – to take the pulse of what’s happening with the very best in product development.

While the topics presented were as varied as the speakers, some general themes did emerge. Of particular interest to me was the shift in how people are thinking about the development process itself. While product development has been the subject of much improvement through the years, that improvement hasn’’t always happened at a constant rate. It does seem that every few decades, many little changes add up, leading to a major paradigm shift. I get the sense that this is what’’s happening right now.

Starting in the late 1960s, companies began to move their development processes towards a more phased approach, best exemplified by the StageGate™ methodology. Characterized by clearly defined task sets and interim evaluation milestones, the phased approach sought to map develop- ment to a linear – and therefore predictable – work stream. Firms that adopted this methodology found that they could better manage the process, reduce Time-to-Market, and improve the overall consistency of their output. In the wake of this new methodology, a whole new discipline of Project Management arose to help shepherd developers to a successful outcome.

Unfortunately, every solution has its trade-offs, and the phased approach is no exception. Many of these drawbacks were a direct consequence of the method’s origins. When companies sought to sort out their development problems, they drew upon the same frameworks that had been employed to sort out their manufacturing systems. As Don Reinertsen has pointed out, these manufacturing roots continue to influence how the process works today. To the extent that production-oriented ideas are applicable, the system works, but where development is different from production, the system fails. For instance, while a universal process helps to regularize approaches, it may also discourage innovation and individual creativity.

Thankfully, human beings are clever enough to improvise on a theme when required, and as long as there have been rules, there have been people who break them. Even as the ink was drying on the first explicitly-defined processes, developers were straying from the plan. In some organiza- tions, actual work diverged completely from declared intentions, and we saw the emergence of “underground processes.” The best professional project managers recognized this as a good thing, and they began to see a process map as only a basic approach that needed to be tailored to a particular situation. It’s fascinating to see how this change in project management paralleled changes in manufacturing systems – particularly the shift in the factories from a focus on pure quality and repeatability to flexibility and customization.

This change in thinking represents a new sophistication in how the product development process is perceived. For instance, one of the greatest changes in the past ten years has been the realization of the importance of iteration and prototyping. Michael Schrage and David Kelley have been two of the greatest proponents of prototyping. Michael spoke at the recent conference, while David was quoted often in absentia. Both have helped companies to realize how rapid creation and testing can provide critical feedback early in the process increasing the chances of success. As David so memorably puts it, companies need to “fail faster to succeed sooner.” Thanks to their efforts, prototyping has experienced a revival – and it is just a revival, as students of Ben Franklin and Thomas Edison are quick to point out.

As helpful as this revival is, it has posed a tremendous challenge to those responsible for looking after the process. After all, one of the primary goals of good product development is to shorten development time and conserve resources by minimizing rework. And yet, the whole point of iteration seems to be about doing the same thing again several times with the intention of getting better each time. These two ideas suggest a potentially contradictory message. How can iteration be so good if rework is so bad? I posed this question to several people at the conference, including both academics and practitioners. Some said there was no difference. Others said it was a question of semantics. Neither option satisfactorily explained why iteration is “good,” while rework is “bad.” Finally, Rich Gioscia, Manager of Design at Palm Computing, offered the clearest answer: rework is doing it again when you thought you were done. Iteration is doing it again when you knew you needed to learn more.

It suggests a larger point, which is that product development is also a process of knowledge development. That’s why we iterate and that’s why we account for it. A smooth-running manufacturing system doesn’t require, or even assume, that its participants are learning and adapting. If anything, learning and adapting is challenging for manufacturing. When development processes emulate manufacturing in this way, without accommodation for learning and correction, they become highly rigid. I’m sure that we haven’t seen the last of this topic. Indeed, most firms have yet to fully incorporate effective iteration and prototyping into their development processes. Some very good firms still embrace process maps that are explicitly linear, relying on a footnote that says something like, “Of course, in practice, it’’s much more iterative than this.” Little by little, though, most of us are starting to figure out the best way to account for iteration, to balance discipline with flexibility, and recognize product development for what it is – a process of learning. Watching that evolution is interesting enough to make me look forward to my next conference.