Lean Product Development: It’s Not About Toyota

Our primary goal in product development is to make good economic choices.  All proxy objectives, such as innovation, waste reduction, design for manufacturing, etc. Should be viewed as secondary.  They are a means to influence overall economic outcomes, never an end in themselves.—The Principles of Product Development Flow: Second Generation Lean Product Development by Donald Reinertsen (Celeritas Publishing; 2009)

Don Reinertsen doesn’t mince words: “If someone tells you today that they have a mature implementation of lean product development, you are dealing with either a fool or a liar.  It’s just not there.  But this is sort of the good news, as well: There is an enormous opportunity.”

Reinertsen has been teaching and writing about lean product development (LPD), about shorting product development cycles, since the early ‘80s, when he was a consultant with McKinsey.  In fact, he was dealing with LPD even before it was termed such: “Back in ’91, I started writing about how we could take the ideas of what was called ‘just-in-time manufacturing’—we didn’t have the term lean manufacturing back then—and apply them in the world of product development.  Eventually I wrote the book Managing the Design Factory [1997] and talked about applying the ideas of manufacturing in product development.”

Since then, things have taken off in the field, such that Reinertsen says that there has been the development of three schools of LPD.

1. The Toyota Does It School.  Reinertsen explains that the rationale is simply that (i) Toyota is the master of lean manufacturing; (ii) Toyota knows more about lean than any other company; (iii) “If Toyota does product development, and if lean is good, then Toyota must be doing lean product development and any behavior used by Toyota constitutes lean product development.”  Or, said more simply: Look at what Toyota does (or what is thought that Toyota does) and replicate it.

2. The Repackagers.  This school, Reinertsen says, “either repackage lean manufacturing or rebrand whatever else they have as ‘lean.’”  Here it is a case where things like Taiichi Ohno’s seven wastes of manufacturing are relabeled as “Lean Product Development Wastes.”  Or there are those who are proponents of phased-gate development processes, and who then say that it is lean product development.  “It is a bit like saying that you have ‘green toxic waste.’  You may want to call it ‘green,’ but it is still toxic waste.”  He, evidentially, is not a proponent of this school.

3. The School of Flow.  This is the school he belongs to.  He explains that some of the underlying logical and mathematical structures of lean manufacturing can be applied to product development.  But this is not a case where it is blind allegiance to what is thought to be the Toyota method, nor is it one where lean manufacturing methods are brought wholesale into the development realm.

A Fundamental Difference.  “The obvious issue is that the economics of product development are radically different than the economics of manufacturing.  In manufacturing, variability is always bad.  There is no economic value created by variability.”  In fact, this is a waste to be driven out of the manufacturing system, pace Ohno.  “In product development, there is bad variability, but here is the variability that comes from innovation.  That’s good variability.  You cannot try new ideas without introducing uncertainty in the outcome.  If you try to eliminate all uncertainty in the outcome, then you get very risk-adverse approaches that drive innovation out of the product, and then you have a problem differentiating your product and getting an adequate margin for your design.”  If you’re doing what you’ve always done, or what your competitors are doing, then your process may not have variability, but as Reiner ten points out, innovation that comes from variability can “generate preference and price premiums.”  In manufacturing, variation generates. . .scrap.

Toyota Does It. . .Right?  Well, Reinertsen actually doesn’t think that Toyota is actually doing LPD in all instances, particularly in its set-based engineering approach.  In it, he says, there are multiple solutions pursued in parallel.  This then leads to a convergence, or the elimination of those that aren’t as good as the one that is ultimately selected for full development.  “If you understand anything about manufacturing, you know that just-in-case manufacturing is waste.  You don’t build extra inventory in a process to deal with uncertainty.”  Yet, he goes on to explain, this is what is happening with the set-based approach.  The multiple developments are simply a version of “just-in-case.”

Where’s the Inventory?  Of course, unlike in manufacturing, when excess inventory takes the form of racks, stacks or piles, there is typically no obvious evidence of it in product development: “It’s bits on a disc.”  No one sees it.  So what do managers do?  They continue to load up the developers and engineers: “We tend to believe that there is only one form of waste: An engineer who is not busy enough.  Therefore, if we stack up a lot of work in front of each engineer, we can ensure that each stays busy and we won’t have any waste.”  If only.

What gets created, he says, are queues of work, also known as “work-in-process inventory,” even though it is invisible.  It carries a cost.  An issue is that of cycle time.  According to Reinertsen, if people performed a sensitivity analysis on a development process, determining the consequences of missing the schedule, performance goal, unit-cost goal, or expense budget, they would discover “the time factor is worth a lot of money.”  Yet by doubling the amount of work that is given to product developers, the cycle time is being doubled, and there is a concomitant financial penalty.  Time and inventory are money.

Another PD Difference.  In manufacturing, work is generally scheduled on a first-in, first-out (FIFO) basis.  This is sensible, Reinertsen says, “when all of your jobs have the same processing time and the same delay costs.”  But FIFO isn’t applicable everywhere.  “What would you say if you went into a crowded emergency room and the person managing the intakes said, ‘We handle people on a first-in, first-out basis’?  You’d say those people are insane.”  And this can be the case in product development.

Reinertsen says that there are other scheduling algorithms that can be beneficial, that sometimes it makes more sense to do the shortest job first while in others to do the one with the highest cost of delay.  He suggests that by taking an approach used in the world of computer operating systems, where the sequencing issue is a key consideration, there may be advantages for throughput.  (E.g., in the round-robin scheduling approach, a processor is given a job to complete in a set period of time; if it isn’t complete, then the processor moves on to the next job; by continuing this approach, the shortest jobs are always completed before the longer.)

It is this borrowing of methods from domains other than lean manufacturing that leads to what Reinertsen terms “second-generation lean product development.”  Consider variability.  In some instances, eliminating it simply isn’t an option.  Reinertson cites telecommunications: “Those networks are designed assuming that we cannot eliminate the variability.”  Customers will call whenever they want.  Customers will talk for as long as they want.  This builds on work on queuing theory that was initiated by a Danish mathematician, Agner Karup Erlang, in 1909.

Of these approaches, Reinertsen says, “Many of them are much more sophisticated than the ideas that exist in the world of lean manufacturing.  They’re exploitable, as well.”

There’s a lot of exploitation that remains to be done: “When I do courses I ask people how long they’ve been trying to apply lean methods in their product development process.  The average answer is six months.  The median answer is ‘I haven’t even tried doing it.’”  He adds, “And these are the folks at the leading edge.”