Brian Davis and his design team are developing a new video toaster for Video Appliances Company. They spend two weeks working very closely with Daniel Seligman, vice president of new product development. Mr. Seligman is a highly creative individualthe classic idea manand he offers several novel suggestions for features that should be built into the product. Davis accepts the suggestions and begins building a prototype. Two months later, Seligman visits the design shop to see how the video toaster is progressing. While viewing the nearly finished prototype he becomes very excited. Ive just got a brainstorm! Lets include voice synthesis, so it can talk to the user. The design team members, recognizing that this suggestion would require a major redesign of the product, look at Brian Davis with apprehension to see his response to Seligmans suggestion. Well do it, says Davis, and the design team members groan inwardly. Three months later, Seligman returns to the design shop to review the nearly completed prototype of the talking video toaster. The demonstration he sees causes him to jump with glee. This is great! he says. This is the stuff of science fiction! You know we should carry it one step further than we have. What we produce should not only be a talking video toaster, but it should be a complete multimedia control center for everything related to video. Look into this, will you, Brian? Brian nods his head in agreement while performing some lightning calculations in his head. He guesses this latest request will extend the project by at least nine months and will require doubling the design team staff, at the very least.

Would you have recommended using a prototype? Why or why not?

Would time-boxed scheduling help control the development time of the product? How would you apply it?