This is a cross posting from a question I received over at the Lean Edge website from Joel Stanwood Partner at Industrial Operations. “How should we take Lean into Product Development?”

Toyota or Lean Product Development is a really large discussion topic. In all honesty I cannot begin to do justice to the entire content or even really suggest where to begin without greater knowledge of your situation. I’d want to assemble a better understanding of the situation before spouting off advice. For starters I will offer up some of my standard words of caution and then try to offer some historical perspective on the matter. Then I will offer up what I can in terms of limited practical advice.

In general however attempting to apply basic lean tools off the shop floor (value stream mapping, one piece flow, kanban, pull, level, takt time, etc.) to product development or many engineering realms is usually a recipe for frustration at best and disaster at worst…It is like forcing a square peg into a round hole. The great mistake of many lean advocates has been to contort tools or concepts from the shop floor of Toyota and force similar copies of them into ways Toyota frankly does not use them. This mistaken approach always seems to put the solution or technique out in front before understanding the situation or actual goal. We can always create some analogies and examples to create parallels (e.g. standardizing work practices, process map work flow, etc.) but I think that often also creates more confusion than it actually helps. Step one is always properly understanding the background and defining the problem or opportunity space. That is one of the common distinctions I frequently caution about regarding “Lean” and actual “Toyota” practices.

Consequently before starting with the “solution” of what tools or resources to use I suggest backing up and defining what exactly is the problem and or opportunity space your organization is facing? There are endless buzzwords and concepts that will be throw out in your direction (chief engineer, target costing, Obeya, genka kaizen, set based design, etc.) for lean product development which can quickly distract you from your purpose. The only way to counteract this unfortunate situation is by remaining crystal clear on your actual situation and goals. For example I doubt Steven Jobs ever sat around wondering what lean product development was…he was too busy driving his vision of a greater product for the customer. Sakichi Toyoda was the same way with his desire to create a better loom for less money for the Japanese market.

So in terms of questions:

• Is the driving need in your situation higher profitability? Then some of Toyota’s common methods (which they did not create) for value engineering, value analysis, value improvement, target costing, etc. may be of relevance to your case.

• Is the driving need to increase productivity in product development?

• Is the driving need to shorten the lead time to market?

• Is the driving need to improve product quality and customer satisfaction?

• Can you create new exciting features beyond that of the competition?

• Is the driving need to offer more product options?

• Is the driving need to create new products for new markets or customer segments, etc?

For these cases different needs require different approaches. In the end it is somewhat useful to know what Toyota does (or what other people believe what lean product development is) yet it is far more important to grasp your own customer needs and facts of the current situation. “Depart from needs” was the only sage advice Taiichi Ohno would offer on matter such as these. However that is not what people want to hear in most cases and they desire to know something of Toyota’s (i.e. lean) practices for comparison.

Interestingly improvement in product development in Toyota can be traced to the origins of the company when they reversed engineered competitor products and learned how to make similar copies. The loom business started this way as did the automotive side of the company. We greatly undervalue the importance of these learning activities in the west and often apply derisive terms toward that style of knowledge acquisition. Toyota also learned historically by failure and tenacity in most of its product lines. Early automotive exports to the United States in the late 50’s and early 60’s for example were shaky and underpowered at best however the company managed to learn from these attempts and improve.

Although not sexy in terms of explanation Toyota applied the original Deming wheel for decades (and continues to do so today) in product development. We forget that the original cycle that Deming emphasized in his 1950 JUSE seminars in Japan was originally 1) Design the product, 2) Produce the product, 3) Sell the product, and 4) Research the market acceptance and then take follow up actions which would start the cycle all over again at a higher level. In translation into Japanese this generically became known as Plan-Do-Check-Act or Plan-Do-Study-Act as Deming later alternatively suggested. This in turn was all based off of the original Shewhart cycle of 1) Specify, 2) Produce, and 3) Inspect approach which he articulated decades earlier. His intent was to create something akin to the scientific method for manufacturing for quality improvement, etc. Regardless of what the improvement cycle is called some version of this approach must be applied in a standard fashion or sustainable improvement is not possible in any field.

Toyota of course from repeating this learning cycle has become relatively strong for their industry in many areas of product development. However they would also be quick to point out their competitors have some advantages as well in certain areas. Toyota certainly developed pockets of technological expertise in automotive product development related areas in terms of product quality, productivity, lead-time, safety, cost, and reliability. It would take 20 pages to even begin to adequately explain some of these. Toyota also has developed systematic ways to develop engineers who stay with the company in product development over their career life cycle. The company also has of course honed its software tools (CAD, CAE, CAM, databases, etc.) for designing, developing, analyzing, testing and communicating, etc. as well as various hardware tools. Toyota’s system of engineering drawings alone takes several years to learn and master in sufficient detail to sufficiently understand. Supplier integration and exchange of key personnel is another factor in Toyota’s success. Standard components and thoughtful derivations of these items are also significant. Careful controlled introduction of new technology is part of their equation as well. I could go on listing some other things but I don’t know that it would actually help unfortunately…

Sadly I think we are still facing a massive knowledge and skill deficiency when it comes to explaining what Toyota factually does in product development and production engineering. Both areas are extremely critical to Toyota’s overall success if you study the last 50-60 years of their corporate history. It is not just a great tale of factory improvement. The most interesting learning points to me at least are wrapped up in history and actual cycles of learning by doing, reflecting, problem solving, standardizing, improving, and trying again. The company embodies the original Deming cycle very well. Generally Toyota highly focused on quality at an affordable cost first in product development, then productivity, and then later on reduction of lead-time in the system. Lately the focus has been increasingly on cost and quality again.

At the risk of offending friends and colleagues if you put a gun to my head and forced to me recommend one book or resource to *start* with for “lean” product development it would be Matthew May’s “The Elegant Solution: Toyota’s Formula for Mastering Innovation”. It is not a technical book on product developing. It is simply about innovation and this book better resembles the spirit of what I am attempting (quite poorly I suspect) to explain and emphasize as a starting point. You can get into details later. Don’t bother too much worrying about what is someone’s pet definition of lean product development or jump into techniques, buzzwords, or tools, etc. in the beginning. If you grasp the basic concepts in this book and can then articulate your own problems or opportunities you will be on the right track and more likely to generate results. Then of course you must relentlessly execute some version of the original Deming cycle and develop people for your system. The rest is proper execution of first principles for improvement which are generally universal.