Early Prototypes Can Hurt a Team’s Creativity

In product development, a popular tool is the quick-and-dirty prototype. Because simple prototypes make the abstract concrete, they can guide innovators’ conversations and focus their attention, helping them to move forward. But many companies rapidly follow them with polished prototypes—and the trouble begins. Research I’ve conducted in the auto industry shows that when people see a detailed prototype, something odd happens: They concentrate on the prototype’s form and function, forgetting to attend to any remaining ambiguities about the problem the product is meant to solve or the obstacles in the way. Instead of clarifying the path ahead, the prototype puts a halt to useful brainstorming. This occurs because when a complex technological product is under development, the groups involved often try to proceed in unison without realizing that they don’t agree about what prompted the project in the first place or what is blocking its completion. This “innovation blindness” causes conflict and delays and may sink a project altogether. How can organizations avoid this pitfall? In the early phases of development, they should retain the ambiguity inherent in any technological challenge, moving on only after everyone is clear on what problems the product should tackle and how. At one U.S. automaker I studied, a product that had been shelved because of innovation blindness was resurrected by a return to ambiguity. All the people I met with, from managers to engineers, agreed that crash-simulation analysis—slamming computer representations of vehicles into virtual walls—should play a greater role in product development, in order to improve safety and reduce costs. Many departments, working together, had come up with an idea for a computer-based tool that would increase the accuracy of analyses and help decision makers evaluate designs. But despite apparent agreement on the broad goal, basic disagreements remained. For example, one set of developers thought that what was needed to reach the goal was faster engineering. Another thought it was more-accurate data. When a detailed prototype was built, the discussion rapidly devolved into arguments. “Everyone kept saying, ‘Why doesn’t it have this feature or that feature?’” one participant told me. The haggling went on for years. “It was a brutal time,” another said. It took the arrival of a new manager—someone with a fresh perspective—to resurrect the tool. Because the manager saw a problem completely different from what the others had seen, he unwittingly reinjected ambiguity into the thinking. Wrestling with this ambiguity forced people to stop simply defending the prototype’s features. The prototype was abandoned, the groups clearly defined what they needed to solve, and the tool was built. It’s now helping engineers design safer cars and trucks. Although prototypes often make it easier for developers to translate their knowledge for one another, they can stymie progress if they become too detailed too early. Organizations need to retain some ambiguity until groups have agreed not only on goals but also on the fundamental difficulties at hand. Early on, a manager’s mantra should be: “I don’t want to hear solutions. I want to hear about the problems that our product needs to solve.”

Early Prototypes Can Hurt a Team’s Creativity

Partner Center