Yet, it wasn’t always that way. Earlier in my career, I did what all the experts tell us. ‘Used all their product development tools, engineering formuli and problem solving tactics; like brainstorming, mind-mapping (I was particularly big on mind-mapping), trying 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.

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 innovation, 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” and “rebuilds” 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 making a series of tools, to help our product development teams (working groups) at General Dynamics, so they could quickly look up the ‘improvement principle(s)’ that could solve their current problem; design constraint, functional limitation, 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 development teams into a 1-hour principle driven problem-to-solution session. All 28 teams came up with innovative solutions to their problem(s). All 28 teams, with their improved devices and systems passed checkpoint reviews and 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 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 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% successes (with some statistical confidence) and with 0 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. Waisting 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 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 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!