Shop PDMA >

Serious Play: How the World's Best Companies Simulate to Innovate

Serious Play: How the World's Best Companies Simulate to Innovate


Schrage, Michael

Serious Play: How the World's Best Companies Simulate to Innovate

Michael Schrage
1999, 233 pages, hardcover (0875848141)

Michael Schrage's new book takes on at least three compelling product development issues under the banner of its playfully serious title.  One concerns the implications of our increasing ability to prototype, model, and "show and tell" as we move through the process of bringing ideas into marketable products.  The next concerns the nature of the corporate culture needed to take advantage of this ability.  And the last concerns the nature of innovation, which for Schrage is more like play than like work as we usually think of it. Despite its subtitle, this book is not a "how to." It is better read in a spirit of reflection, and it will make the most sense to product developers and managers who can bring their own experience to bear on Schrage's commentary.  It will appeal most to those who have thought, or who would like to think, about the nature of innovation, design, and modeling as business practices.

Product developers are working with new tools, and they are developing different kinds of products in response to different kinds of market and technology forces.  Schrage's book invites us to consider how these forces come together to create a radically different product development process and culture, and to question whether we have shaped our organizations optimally within these.  A key question that he asks is whether, in a given culture, prototypes are made chiefly in order to prove the design, or whether they are an integral part of the process of discovery and innovation. (This relates to the distinction he makes between whether an organization is spec driven or prototype driven - see page 72).  I have a fairly typical product development process outline in front of me right now.  In Stage 2 - Product Design - one of the key deliverables is "Functional Prototypes." These are to be used for testing and evaluation.  Such prototypes usually are required as part of the phase/ review process and are used in that context to ensure that the team is "on the right track," developing a product that meets the original definition.  It is nearly gospel that product definition is done early, and changes to the definition should be few and managed.  Prototyping is rarely used to iterate the design throughout the process.  New information from prototype testing that might alter the scope of the project is generally considered to be a red flag.

But, according to Schrage, we may be entering an era in which we need a more fluid concept of process time.  Schrage quotes lansiti: "As the pulse of the project, prototypes punctuate the effort by integrating architecture and technology into a coherent package" (page 87).  This is a very different way of thinking of the relationship between work and time.  "How organizations choose to manage time," Schrage tells us, "strongly influences how they manage prototypes" (page 85).  In slower companies - Schrage notes IBM, AT&T, General Motors, and Johnson & Johnson - the mean time to prototype is months slower than in the faster cultures such as Sony, 3M, Microsoft, and LSI Logic.  The implication is that paradoxically, in order to get to market quickly, some companies are breaking the old rules by prototyping and experimenting much further into the development process.

Schrage paints a delightful picture of the iterative, interactive nature of design by prototype.  For instance, prototyping can define a different and essential role for customers.  "The most important member of [the prototyping] community," Schrage observes, "must be the customer.  The customer must have an opportunity to play with and relate to prototypes as they evolve" (page 92).  One software design firm, Cambridge Technology Partners, "gets clients to collaborate on rapid prototypes of the systems they want built" (page 127).  CEO Jim Sims reports "it's rare that companies end up building the apps they came in thinking they would build. . .. What usually happens is that the team discovers what they really want as they build their prototypes." According to Schrage, "the solutions emerge from the evolution of the prototype, enabling clients to usefully surprise themselves" (page 128).

Firms use "virtual" prototyping and "palpable" prototyping; they use narrative, role play, and story boarding; they use process flow design and scenarios and spreadsheets.  Reflecting on the nature of the prototyping medium, Schrage asks whether "Detroit's lagging competitiveness in the 1980's [can] be blamed in part on its prototyping media" (page 79).  "Their clays were crafted with little thought of assembly lines. ... [They] often generated more contention than innovation" (page 137).  He answers his own question: "Absolutely.... The medium's message [was] look but don't touch" (page 79).  Toyota, in contrast, worked in a computed-aided design (CAD) medium in which the clay model became the output.  "To no one's surprise, Toyota's speed-to-market proved twice as fast as General Motors throughout the 1980's and early 1990's" (page 80).

One of Schrage's chapters is entitled "Our Models, Ourselves."  Models are not just chosen to represent the problem we are trying to solve.  They also reveal the ways in which we choose to go about the problem, the assumptions we hold, and the paths we would not go down.  The use of models can submerge assumptions, as when the Navy refused to allow into its war games the possibility that one of its aircraft carriers could be sunk.  Using models and prototypes in the spirit envisioned by Schrage and outlined in the final chapter, "User's Guide," "demand[s] honesty. [The rules] force people to look at themselves through their prototypes.  All too frequently, firms don't like what they see.  So they ignore it, suppress it, destroy it, or dismiss it as an aberration" (page 201).  Modeling and prototyping, scenario planning, and narrative and story boarding all create little slices of virtual reality.  We may choose to suppose that these slices do in fact represent reality, as managers do when they believe that the answers to their business questions are simplistically contained in their spread sheets.  Or we may, more powerfully, recognize that the very models we use can reveal to us the nature of our fundamental assumptions.  "Models serve us best when they challenge our assumptions," Schrage claims on page 120.  Models can help us to see what those assumptions are, if we will be open to the view.  The thing is, "organizations are often the last to recognize the cultural imperatives that guide them" (page 94).

Schrage uses many terms almost interchangeably: prototype, model, heuristic, and scenario are a few; narrative, role play, rehearsal, CAD, and model shop are a few of the ways in which these are done.  And Schrage comments on their use both in product development and in business concerns.  This adds a quality of un-pin-downableness to the book: Just what is he talking about?  The business decisions that are the subject of spreadsheet scenarios?  The interactions that are occasioned by scenario planning?  The new product tradeoffs that come from good prototyping?  All of these, and sometimes in ways that are mixed together.  Making these distinctions more clearly would add to the usefulness of Schrage's thinking for product developers and managers. 

In fact, Schrage is largely preaching to the choir.  Those who use rapid prototyping and who view the world as one glorious experiment will find in this book much to help them formulate their arguments in favor of a prototyping culture.  These readers will relate to Schrage's opening claim: "I have always enjoyed rehearsals more than performance" (page ix).  The appeal to those who are more driven to the bottom line may be weaker.  Schrage asks many questions in the course of the book and typically tells us in response to his own questions, "there is no inherently right answer" (page 99).  At the book's end, he admits "concluding a book with questions might be seen as unfair" (page 200).  Well, maybe not unfair.  But, for many readers, there will be a superfluity of insights with very little guidance as to how to apply these in action.  Nonetheless, the shift in point of view that Schrage's book occasions should give managers and product developers a chance to view prototypes and prototyping differently, to ask different questions themselves, and to find new and more effective ways of designing the use of prototypes in product development and in the organizational culture.

Beebe Nelson

InterMatrixPDP, March 2000