Image Image Image Image Image Image Image Image Image Image

The Triz Journal | January 20, 2017

Scroll to top


Product Dev Versus Lean Product Dev

| On 01, Jan 2010

Message: 1406
Posted by: Suzanne-Texas
Posted on: Monday, 25th August 2008

What's the difference between Product Dev and Lean Prod Dev?  Is it reasonable for Product Dev to be Lean when you're hopfully looking to be innovative?

Message: 1410
Posted by: shyam gopal
Posted on: Tuesday, 26th August 2008

Princinples of Lean adapted and applied to product development is technically Lean product development. Many a times it might not be simple one to one transalation from manufacturing, where Lean originated, to product development. But many including the basic principle of identifying value added (VA)and non value added(NVA) and eliminating the former can be applied to product development and to any process for that matter.

As for Lean product development being innovative, I dont see why not. Innovation will be the outcome of the VA activities in the process. NVA will still be present and could be trageted by lean to improve the efficiency of the innovation process. This is a very simplistic answer to your question, I know. What do others think?

Message: 1417
Posted by: tyro
Posted on: Tuesday, 2nd September 2008

I think one will be more innovative if he incorporates Lean concepts into the Product Development Process.

Innovation will not be hindered with Lean – in fact, it might even clear out your way of non-value adding activities – giving you a clear sight of innovative ideas.

For me, innovation generally means being more efficient, more effective and more productive than what is currently a standard in the industries. Lean paves the way towards the innovation you are looking for.

Message: 1418
Posted by: Tony
Posted on: Tuesday, 2nd September 2008

Will somebody please tell me what a lean product development organisation structure and process looks like that may differentiate it from current best practice. How does this have a significant impact when at the leading edge of technology development that is driving future market wants and needs? Or are we just using buzz words to look smart!!! Convince me.

Message: 1420
Posted by: Katherine Radeka
Posted on: Thursday, 4th September 2008

There is a lot of confusion out there about what lean product development is and how it can help, especially those companies at the leading edge of innovation.

For those companies, lean product development can help them commercialize their cutting-edge innovation into streams of new products by helping them more effectively utilize their customer and technical knowledge base.

Although lean product development has its roots in Toyota, the practices of lean have been found in companies as diverse as HP and 3M in their best years, Google and Apple today.

It works by revisiting the assumptions embedded in current best practice in product development on the best ways to manage the work of product development. The practices of lean product development challenge a lot of those basic assumptions from the perspective that the goal of any organization is to deliver maximum customer value for maximum return.

Exactly HOW this works – how organizational structures and processes change – is far beyond the scope of a post. The best source is Lean Product and Process Development by Dr. Allen Ward – published last year by the Lean Enterprise Institute.

In your future explorations, please keep one thing in mind:

Lean product development evolved from the Toyota Product Development System similar to how Lean Manufacturing evolved from the Toyota Production System.

However – and this is key – they are not the same. They evolved side by side, they support each other, but they are not the same.

If your internal lean experts are telling you something different, you are right to be skeptical.

Message: 1421
Posted by: Karthikeyan Iyer
Posted on: Monday, 8th September 2008

Underlying Lean Product Development is the concept of Set-based Concurrent Engineering, or to make it easier to understand “Elimination of the Weakest”. This looks quite counter-intuitive to those of us who have always used the “Survival of the Fittest Approach” in the typical “Requirements-Design-Code_test” cycle. At every stage we chose one amongst various alternatives and move ahead. In the “elimination of weakest” approach, at every stage, the weakest alternative is eliminated and all other (feasible or promising) alternatives are carried forward. Most project managers find this approach counter-intutive and infeasible at the outset. Most would be unwilling to try the approach in LIVE projects. The typical argument is that working on all alternatives simultaneously will consume too much effort (just not possible!). However, Toyota does it quite successfully. The secret unknown that we overlook in traditional approaches is the amount of “rework” that needs to be done towards the end because we chose an alternative too soon based on incomplete evidence (earlier on, there just isnt enough data to predict the outcome).

This brings me to the link between Lean Thinking as applied to processes and to product development. Lean Thinking, at an abstract level, looks to reduce or manage complexity (complexity impacts the end-value substantially). One of the elements of what makes things complex is ambiguity.

Typically, product design is a complex series of activities, with unpredictable outcomes at each level (each level builds on the next – you only have visibility to about one and a half levels forward in time). Whenever there is ambiguity, complexity is best resolved by freedom or a divergent approach. If you are searching for something and you have no short-cut clues, you tend to start with a broad view. SImilarly, when requirements are ambiguous or design outputs are unpredictable, Toyota goes with a set-based approach, covering all bases, delaying decisions till such time when there is sufficient data to form a conclusion. Testing is via prototypes, not through mathematical models.

At the same time, processes warrant a different approach. Ambiguity of outcome is not the case here and the task are repeatable and predictable in nature. What changes is demand pattern and service rate. Toyota, through the well known Lean manufacturing tenets (value stream, waste elimination, workload leveling, 5S, SMED, visual controls, single-piece flow, pull and built-in quality attemtos to reduce ambiguity in service rates by tighter controls, reducing the number of transactions, reducing the variability between transactions, bringing them all to a constant rhythm. When someone goes off-beat, it can be easily detected.

If you notice, the same philosophy manifest itself in different forms depending on the nature of the problem. In fact, beyond processes and products, the same philosophy (simplicity, elegance and perfection) drives Toyota Way at an organizational culture and strategy level, again manifesting tself differently in the form of respect for employees, suppliers and partners, long-term philosophy and humility.

While Lean manufacturing tenets (workload leveling etc. can be applied to product development as well (benefits are greater if the product development requirements are not ambiguous), Lean Thinking has a larger meaning, which acts a guideline for application in any context, without getting tied down to only the specific tenets articulated for specific contexts.

Message: 1424
Posted by: Brian Kennedy
Posted on: Sunday, 14th September 2008

Several good answers above, but I'd like to focus in on the questions that Suzanne asked starting this thread:

> What's the difference between Product Dev and Lean Prod Dev? What's the difference between Product Dev and Lean Prod Dev? What's the difference between Product Dev and Lean Prod Dev?

Given the “Lean” name, the obvious answer is “elimination of waste”. In traditional Product Development, there are two huge forms of waste:

(1) making decisions without KNOWING they are the right decisions; we call this “design-then-test”, which is the predominant paradigm in product development worldwide; the result is often the dreaded “loopback” (schedule slips, engineering changes, recalls, etc.), where you realize late in the process that this isn't going to work for your customers… very expensive source of waste; many companies' engineers spend 75% or more of their time in loopbacks; Toyota insists upon KNOWING before they make design decisions (we call this “test-then-design”), resulting in almost no loopbacks… they consistently meet schedules with products that consistently satisfy the customer.

(2) lost knowledge… reinventing the wheel… re-solving the same problems; we learn a lot in every product development cycle… that's good; but we re-learn a lot of the same things that we learned in prior cycles… that's waste; Toyota has established mechanisms that reliably flow the lessons learned into all future projects… they ensure their knowledge is maintained and reused.

> Is it reasonable for Product Dev to be Lean when you're hopfully looking to be innovative? Is it reasonable for Product Dev to be Lean when you're hopfully looking to be innovative? Is it reasonable for Product Dev to be Lean when you're hopfully looking to be innovative?

Are you truly being innovative if you are reinventing the wheel? If instead, you leverage all the past inventions and innovations and lessons learned … and build upon those rather than reinventing those… that's a whole different level of innovation. (Sound like TRIZ?)

If you come up with innovative solutions that you think might work but there's a lot of unknowns, the “innovative manager” in most product development organizations might decide to be bold and “go for it”. Is he being more innovative than the “prudent manager” who says, “we don't know how to do X and Y yet, we can't move forward with that until we do know”? Most would argue that the latter thinking will result in less innovation.

Consider the two paths: with the bold path, you proceed into design hoping (expecting) that you'll innovate as necessary to make it work; your path ends up guided largely by the premature decisions you made, and much of your innovation is put into how to get the most out of the corner you painted yourself into.with the prudent path, you focus on testing X and Y to where you do know how that works; with that knowledge, you then work out a design that you KNOW best satisfies the customer interests; then you move into the actual detailed design of the product; with this path, your engineers' innovation is not being consumed getting out of the corner, but rather is being used against a wide open canvas with all the knowledge they need to truly innovate on how best to satisfy the customer.

Engineers on both paths may all feel like they are being innovative and overcoming great challenges.For the companies involved, one will be coming out with far more innovative solutions than the other; and more importantly, those innovations will be directly impacting customer satisfaction.

Net answer: Lean Product Development, done right, helps take innovation to a whole different level!

Message: 1425
Posted by: Ellen Domb
Posted on: Monday, 15th September 2008

Great discussion, Brian.   I agree with everything you said, and I'm waiting to see your next posting.   Brian and I were participants in the Lean Product and Process conference in April this year.   For those looking to learn more about lean product development, and the relationship with TRIZ and other innovation methods,  I recommend it strongly,

Message: 1432
Posted by: donhall
Posted on: Sunday, 21st September 2008

Innovation is often stiffled at suggestion levels: 1.) if the suggestion comes from outside the “clique”, 2.) outside the educational acceptance venue – non-engineer, non-etc.,3.) if good suggestions are continually ignored, the source is / may, be forever closed mouthed, 4.)innovation processes are often fragmented, too cloistered, too un-mentored, 5.)innovation reeks of caring and caring is many organizations is subjected to “back biting”, etc. 6.) where is the REWARD factor for many who would propose innovation, 7.)innovation is the true natural breeder for further innovation … maybe the nutshell time has arrived, in Kaizen type short innovation will be invited or denied by the enterprise makeup, by the mechanism of consideration, by the credentials of the submitter (what, never published in a peer-reviewed journal?)

Message: 1434
Posted by: Kelly
Posted on: Sunday, 28th September 2008

Could you please explain what you mean by innovation reeking of “caring”? And why that is subject to “backbiting”?

Message: 1435
Posted by: Jim Carter
Posted on: Tuesday, 30th September 2008

“innovation reeking of “caring”” is often described as “having a Champion for the project” in the change management accounts. Someone in power has to pay attention to the issue, and attention of those in power is accompanied by “backbiting” or other means of organized subversion in many organizations.

Message: 1439
Posted by: Kelly
Posted on: Monday, 6th October 2008

I would not have expected the championing of a project–innovation included–to be stifling.  I suppose that I am idealistic in the respect that if something is being championed then trying to prevent it (ie, stifling it) actively in any way would be a fast way to lose a job.

Message: 1462
Posted by: Tom
Posted on: Sunday, 26th October 2008

By my count, there are at least three schools of thought on what Lean PD is. One school, championed by the Lean Enterprise Institute, is that Lean PD is Toyota's implementation of PD. As another poster noted, one of the core tools is concurrent set-based design, though there are other interesting features of their PD process. Another school takes Lean PD to be product development for lean manufacturing; developing products that support the elimination of the seven wastes in manufacturing. The third school attempts to apply the principles of Lean to PD, identifying and eliminating waste. As another poster mentioned, the main waste is loss of knowledge, and this can be measured as monetary loss using cost-benefit analyses such as NPV. One of the main proponents of this approach is author and consultant Donald Reinertsen. There may be a fourth school, which applies the Lean Manufacturing improvement tools directly to PD, attempting to eliminate the seven wastes. Whether or not this counts as “Lean PD” is open to debate. I believe this approach to PD process improvement would work well when there was a lot of low-hanging fruit, but would go badly wrong when applied to stringently; PD is not like manufacturing.

To summarize, “Lean PD,” as a discipline, is not standardized. The main reason for the differing opinions is that the drivers of successful PD (Lean or otherwise) are poorly understood. It is probably best to study the best practices in PD, understand the financial drivers for your organization (i.e. PD project expense; piece cost; time to market) and work to implement those improvements that would improve your fincials.