But, it wasn’t always that way. I used to do what all the experts tell us. ‘Used all their product development and innovative improvement tactics, like brainstorming, mind-mapping (I was big on mind-mapping), creativity,  wondering, guessing, thinking outside the box (whatever that means). And, I wasted untold time and money on trial & error, experimentation and TAFT final product validation testing that tried our budget and nerves to the end. 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 will not work.” He also told his Menlo Park development specialists and engineers (which he called “sloggers”) to “experiment on everything”.  And that became the R&D model for innovation for the next hundred years.  Using those methods I certainly had my share of “start-overs” and failures and layoffs, as the companies I worked for had their failed attempts. Companies like; CMS Petrographics, Signetics Semiconductor, John Deere, Hughes/Baker EIMCO, GE-Healthcare and General Dynamics Defense Corporation. I had a few real successes too, but my failure/success ratio, when you count “start-overs” and “reworks” as failures, was easily 80/20, or worse, right?

But, then in May of 2010 I made the biggest discovery of my engineering career. My discovery was this: You can solve development problems and come up with an epiphany for what the customer will need next, by one of two methods;

1. You can guess, wonder, brainstorm, or experiment on everything. (the average time to an effective epiphany is 5-80 years, according to Steven Johnson, “How We Got To Know”), 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 making a series of tools, so that our product development teams (working groups) at General Dynamics could quickly look up the ‘improvement principle(s)’ that could solve their current problem; design constraints, functional limitations, reliability, safety, usability (HFE) problems, etc..

Over the next 5-6 years I helped 26 different design & development teams with what they were describing as an “unsolvable problems”.  I would invite each development teams into a one-hour principle driven problem-to-solution session. All 26 teams came up with innovative solutions to their problem(s). All 26 teams, with their improved devices and systems passed checkpoint reviews and were then Adopted by our Customer, the US Army.  All 26 are now helping in the Battle Field, saving the U.S. Army $233 million, over the legacy equipment 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 they had been struggling with for month or years and did it in less than an hour.  The significant point here is, that across those 26 project teams I coached, all 26 improved products were adopted by our Customer, because each one brought improved functionality or improved value to the customer.

The significant point is that we had broken or reversed the 80/20 Rule of failures. Rather than 4 failures for every success, we had achieved 26 successes and 0 failures. That’s 100% successes with 0 failures,

Speaking with statistically Confidence, we can say 25 successes before a failure, which is a 4/96 rule of success, only 4 failures per 96 successes. And, I could see why: We had moved from the painfully slow and failure prone, 100 year-old, innovation methods of guessing how to improve the system. We were NOT wasting time brainstorming, mind-mapping, nor “thinking outside the box”. 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 had solved our current problem type thousands of times before. How would your success ratio and profits over the past couple of years have improved, if you had created 26 project successes and 0 failures? Or, even 25 successes for each failure.

Well, that motivated me to take 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!