Development Costs | Traditional vs. Lean
Our previous article, “Lean & Affordable Product Development” revealed our approach that doesn’t require big budgets because our focus is to solve the functional problem first with a reference for the desired aesthetic employing DFM, rapid iterations, and economic manufacturing techniques. The approach is sensible and efficient regardless of budget size. Let’s take a deep dive into one of our latest projects to reveal the “Tale of Woe” so many entrepreneurs, inventors, and start-ups learn the hard way when following traditional industrial design product development.
The Stealth Consumer Product Example
The image above is the rendering of the product in its market testing form and is a real-world classic example. It is a complex product. It has a control board, power inverter board, electromagnetic piston, a capacitive sensor, and more that all have to be developed in parallel and packaged together in a tight, sexy, and IP66 waterproof case.
The cost to dress-up and make a solution super sexy is far less than the cost to engineer a high performing solution with a low BOM cost. Our lean and affordable product development saved the client from having to abandon his idea due to outrageous development costs if he pursued it the traditional way (form before function).
This is how it would have played out if we followed the traditional industrial design path:
LEAN PRODUCT DEVELOPMENT THAT IS AFFORDABLE
We are not dream-crushers here, we are dream-makers and this is how it really went down:
FINAL THOUGHTS
There is a DFM manufacturing theme throughout our website for a reason. We want potential customers and clients to understand that they can have an economic and lead-time advantage working with a team that spent a large portion of their careers on the shop floor and therefore can guide them along the most efficient and cost-effective path.
So why are most firms and universities using/teaching the traditional industrial design process one may ask? It’s two-fold. First and foremost, they never put their own net-worth on the line to develop their own idea or as a business owner. If they had, they would have learned the economic lessons the hard way at the expense of their well-being.
Second, they have very little experience in the myriad of manufacturing disciplines. Start-ups and inventions are not imagined from the manufacturing shop floor. They never made parts with CNC machines, never ran a sheet metal press, never operated a wire EDM, never polished 10,000 small caps by hand to understand the cost, time, and just how dangerous optimistic BOM costs are.
Fun-Facts
While Ryan T. worked at Tesla Motors (employee #24), all the different powertrain groups struggled to meet deadlines and objectives for their respective technologies throughout the development of the Tesla Roadster. Ryan T’s battery enclosure struggled much less and hit most of the targets because he took a requirements-driven approach when the other groups did not. Constantly preaching to his mentor Dave Lyons to require the other groups to do the same, it never transpired and it was a struggle to the end (production).
However, guess what was implemented for the next vehicle program called, “Whitestar”? You guessed it. A dozen system engineers were hired and a full-blown systems/requirements-driven strategy was implemented from the very beginning for that next vehicle, which became the infamous Model S and the automobile of the year; arguably one of the greatest automobile in history.
Dave told Ryan, “You were right man, I never want to go through that again and we are going full-blown requirements-driven all the way!”
Our design, build, learn mantra comes from Dave who was the director of Engineering at Tesla. Prior, he was also the Program Manager at IDEO for 13 yrs beforehand. IDEO is a global leader and one of the most revered design firms in the engineering and design community.
Lastly, the requirements-driven development philosophy stems from an earlier mentor Bill Brooks. He was the director of engineering for NASA for over 20 years and Ryan T. adopted it ever since working with him at inTest.