They can, but few product developers use them in a way that yields any real speed advantage. Consider that an ordinary prototype might take a month (20 workdays) to make, and a rapid prototype takes a day. Assuming that this prototype is on your critical path, you save 19 days, which is 4% of a two-year project — not impressive!
However, developers who apply prototypes wisely often see timesavings of 50%. They do this by viewing each prototype as an opportunity to answer a question. They ask their question clearly, build a simple prototype to answer only this question, get their answer quickly, and move on to another round of prototypes to answer the next set of questions.
That is, they view product development as a series of questions to be resolved, and they use prototypes to resolve these questions early, quickly, and precisely. Compared to normal prototyping, they “front-load” their prototyping by building many more prototypes earlier and focusing each one on a specific question. (Traditional prototypes are too infrequent and appear too late to provide effective feedback.)
Surprisingly, those who front-load their prototyping usually pay less in total for their simple prototypes than those who build a few elaborate prototypes late in development for verification.
To learn more, read some of the prototyping publications on this website, or see Stefan Thomke’s new book on contemporary experimentation.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.