Yet, it wasn’t always that way. Earlier in my career, I did what all the experts tell us.  I used all their product development tools, engineering formulas and problem/solving tactics; like brainstorming, mind-mapping, fish-bone diagrams, etc.. I was particularly big on mind-mapping). I helped teams try to be creativity; wondering, guessing, thinking outside the box (whatever that means). And, I saw a lot of money wasted and untold time wasted on trial & error, experimentation and TAFT final product validation testing that pushed our budget and nerves to the end.

You may remember, it was the great experimenter-inventor-product developer Thomas Edison, who said, “I haven’t failed 9,999 times. I’ve just found 9,999 ways that it won’t work.” Edison also told his Menlo Park development specialists and engineers (which he called his “sloggers”) to “experiment on everything”.  And that became the R&D model for the next hundred years.  Using those methods I certainly had my share of “start-overs”, reworks and failures. ‘Even layoffs, as the companies I worked for suffered these failed attempts. So, I had to move from Signetics  Semiconductor, to John Deere, from Hughes/Baker EIMCO to GE-Healthcare and then to General Dynamics Defense Corporation. Those layoffs and moves are painful. I had a few real successes too, but my failure/success ratio was easily 80/20, when you count “start-overs”, “reworks”, “rebuilds”, or “loss of next phase funding” as failures.

But, then in May of 2010 I made the biggest discovery of my engineering career. My discovery was this: You can solve development problems, design and system constraints and come up with epiphany-type-solutions, for what the customer needs, by one of two methods;

1. You can guess, wonder, brainstorm, or experiment on everything. (the average time to an effective epiphany is 15-80 years, according to Steven Johnson, “How We Got To Now”), or
2. You can simply read over the correct principle upon which the needed improvement is predicated, and the epiphany comes almost immediately. 

So, I started creating a series of tools to immediately provide the “correct principle(s), to help our product development teams (working groups) at General Dynamics, so they could quickly look up these ‘improvement principle(s)’ to solve their current challenge; design constraint, critical functional failure modes, reliability, safety, usability (HFE) problems, etc..

Over the next 5-6 years I helped 28 different design & development teams with what they were describing as difficult or “unsolvable problems”.  I would invite each team into a 1-hour session to play what I called “the innovation game”. I applied method #2, above, and the team would almost immediately come up with the epiphany (solution). All 28 teams, with their improved devices and systems passed checkpoint reviews and all 28 systems were then Adopted by our Customer, the US Army.  All 28 are now helping in the Battle Field, saving the U.S. Army $233 million, over the legacy systems they had been using.

The one significant point here, when it comes to helping you, is Not that we saved $233 million. Nor is it that we solved challenges the engineers had been struggling with for month or years, nor that we solved each problem in less than an hour. The significant point here is twofold;

A. That across those 28 project teams I coached, all 28 improved products were adopted by our Customer, because each one brought improved functionality or improved value to the customer. 

and

B. That we had better than reversed the 80/20 Rule of failures. Rather than 4 failures for every success, we had achieved 28 successes and 0 failures. That is, statistically, at least 96% success rate (with some statistical confidence) and zero failures,

And I could see why: We had moved from the painfully slow and failure prone, 100 year-old, innovation methods of guessing and trial-and-error. Wasting time on brainstorming, mind-mapping and “thinking outside the box” was pretty much out the window. We didn’t waste time coming up with and experimenting on creative options. We had moved to a whole new level of time-saving performance and success, by simply and quickly applying correct principles that solved our current problem type, hundreds, if not thousands, of times before.

How would your success ratio and profits, over the past couple of years have improved, if you had created 28 project successes and 0 failures? Or, even 26 successes for each failure. (calculate it)

Well, that results motivated me, big time. So, I took early retirement, so I could document and share these principles, methods, and procedures with you, with young product & systems development engineers, innovators, and with those who fund these developments!