I just read a great article about the history of the development of the Swiffer Mop, “Mopping the Floor with the Status Quo“.  The creation and prototyping process was run by designers, not engineers, and it was fast:

West says the disposable cloths for the prototype were actually found in the aisles of Home Depot. “This whole thing is what you’d call a Frankenstein Model,” he says. “We had an old broom, got paper towels, we found plastic tubes to spray water on the floor. We got a nozzle from a spritzer bottle, a little electric pump. Within a day, we hacked it. We’re going to a model shop and cutting it up and getting it to fit. We created an ergonomically effective handle.”

Now, before it went into manufacturing I’m sure it got the full suite of engineering analysis, and P&G surely put a lot of work into ensuring its testing and reliability.  But they iterated the first designs quickly, beat out the initial risk that the idea would stink, and then had good reason to invest more careful effort later.

Of course, if you are going to build an optical or high vacuum system you can’t get parts from Home Depot… usually.  But just like in consumer products and software, hardware development processes are riddled with dead ends.  Hardware engineers and scientists rarely give thought early in the process to what is the smallest possible increment they can achieve that would improve their learning.  Yet even though such intermediate steps don’t even fall on the long term roadmap, they represent valuable opportunities to test your bigger picture plan and avoid dead-ends before you enter them.

There should be a balance, especially in early stage development, between progress on the development plan and activities strictly designed to reduce risks.  This includes not just management risk analysis, but little engineering experiments whenever possible to make sure you are consistently on the right track.

How much emphasis does your engineering team give to risk?