Flexible Product Development: Building Agility for Changing Markets

Written by: Preston G. Smith. Jossey-Bass, 2007. 286+xiii pages.
Reviewed by: Beebe Nelson

Flexible Product Development begins with a definition of flexibility, an explanation of its importance, and an account of its roots in agile software development. Preston Smith has learned from the software industry and has put together an approach that will be useful to product developers in almost any industry that I can think of. He introduces it as a "toolbook," a how-to book, and it will appeal to those in the trenches and on the teams of product development. It will also prove useful to managers as they contemplate the ways flexibility might add to their competencies and capacities. In addition, as Smith cautions in his final chapter, the best way to implement these changes is with a combination of top-down strategies and bottom-up tactics.

In the first chapter the reader gets a feel for Smith's approach, an approach I find refreshing and enlightening in an age of overhyped claims for this or that author's (usually repackaged) "brand new and guaranteed" methods and processes. Smith has assembled both theory and tools to help us increase flexibility, which he defines as "the ability to make changes in the product being developed or in how it is developed, even relatively late in development, without being too disruptive" (p. 2). Everyone would like more ability to do that, but unlike many authors, Smith does not overpromise: It would be easy to conclude that the more flexibility, the better. But "flexibility can be expensive, so it must be used with discretion (p. 7). At the end of the first chapter, Smith provides a "Project Analyzer" to help product developers pinpoint where more flexibility will be most beneficial and to identify where it might be harmful, for example, :avoid the areas with systemwide impact" (p. 9).

Smith does not set up straw men that his approach is always better than. For example, while he worries about the approaches (e.g., Six Sigma, PACE, StageGate®) that seek"to reduce product development to a predictable activity" (p. 3), he also tells us that "none of these approaches is misguided or has net negative effects" (p. 4). He also generously credits those who have devised similar approaches and provides data wherever he can. For example, he cites studies by Barry Boehm on the cost of change in software development. He is careful to call our attention to the fact that Boehm's data have limited application in fields other than software, but he advises us to prefer this data to undocumented "rules of thumb:" Please question your sources on the cost of change," he warns (p. 10).

After the introductory chapter, he provides chapters on customers and product requirements, modular product architecture, experimentation, and set-based design. These read like a well-researched primer on product development practices, always described with an eye to how they can be used to increase flexibility. The chapter on customers and product requirements comes early because understanding what creates value for customers is central, in Smith's account, to increasing flexibility (and still meeting your desired targets). In this chapter Smith describes the practice of using customer personas and employs cases that enable product developers to specify the product at a high enough level so that changes can be incorporated during development. In the chapter on experimentation, he describes how new prototyping technologies have transformed product developers' ability to run tests and experiments early in the process and eloquently describes the difference between "experiments," which add to knowledge versus "tests," which confirm what we already know.

Although these chapters show how the practices contribute to flexibility, Smith continues to add words of caution. For example, "You must ensure that you have the capacity to make many more prototypes. If not, you will choke on front-loading before you experience its benefits (p. 100). And "set-based design works at Toyota partly because of its unique culture. It is hard to tell how difficult it would be to implement elsewhere" (p. 124).

Chapters 6, 7, 8, and 9 cover teaming, decision making, project management, and product development processes. Smith makes the point that most of our practices do little to improve flexibility. We overburden our teams and make it hard for them to meet together. We prize aggressive decision making when a better rule for flexibility is to put decisions off as long as possible. We want to create complex and predictable project plans, but if a project needs to be flexible that means it will change. Smith recommends two- or three-stage planning: a detailed schedule close in and higher- level plans further out.

A flexible product development process cannot over specify a project's activities, timeframes, and outputs. Rather, it should help teams do "basic activities in proven, consistent ways" while allowing teams to "rearrange these parts in varying combinations" (p. 207). This allows for iterative and incremental development, and a key to such development is frequent customer feedback.

Smith, like many companies and consultants, equates phase and review processes to the management of work flows. This leaves out the most powerful part of well-implemented product development processes, which is the management of business case decisions, combined with decisions about portfolio (match with strategy) and pipeline (match with resources). Overinsistence on building project management into the product development process can increase rigidity, whereas focus on the business case from review to review can leave the developers—the team—with the flexibility to make decisions and changes to the project as needed as long as they can still present a satisfactory business case.

Smith's book is about work and work flows. I would have liked to see him suggest that the product development process has, as its most important component, the managing of business decisions. When product development processes are understood in that way, there is no reason why Smith's good advice about flexibility can't be combined with phased business reviews, thus reaping the rewards of agility along with the rewards of sound business judgment. (I find it interesting that the terms business and review do not show up in the index.)

Although this book is intended mostly for people who would actually implement flexible practices in their work (i.e., teams), it contains value for managers and executives as well. Smith repeatedly warns against overloading resources and provides a compelling graph that deconstructs the "myth of capacity" (see p. 223). Any manager that reads this book carefully should realize that giving people more work is very likely to slow down the process and to reduce flexibility.

In the final chapter, Smith tells us that his description of the book as a toolkit is"misleading":"It is the underlying values and principles that are critical to becoming flexible. (p. 231). I believe that any careful reader of Flexible Product Development will emerge with a clear sense of those values and principles and enough enthusiasm for what Smith recommends to take his advice and go ahead and implement them. As he warns, "Unless your flexibility improves, you have wasted your time reading this book" (p. 231).