Lean Product Development Practices – Applying
Lean Principals and Project Management Tools to
New Product Commercialization
Christopher Haller
Development/Commercialization Program and Portfolio Management
1
Agenda
 A. Goal of Presentation
 B. Presenter Background
 C. Traditional Product Development – Guild Method or “All Hands
on Deck” Style
 D. Lean Product Development
 E. Knowledge Based Set Design in Action (Examples)
 F. Conclusions / Recommendations
2
A. Goal of Presentation
 Discuss the general concept and benefits of Lean Product
Development (LPD) focusing on four areas:




Principals of Design
System Thinking
Knowledge Sharing
Cross functional teams
 Discuss how Project Management Techniques and Lean Product
Development can be used together
 Provide examples in multiple industries around lean product
development
 Show how LPD can be applied to defining long term product
development roadmaps/product portfolios
3
B. Presenter Background
 Sat on initial teams that assembled the stage/gate processes for




both research & development and product commercialization in
Ran several pilot programs for stage/gate R&D
Became a primary Program/Project Manager
Portfolio Manager assembling Product/Technology Roadmaps
Six Sigma Black Belt and PMP certified
4
C. Classic Product Development/Commercialization
 Point based design – single solution focused
 Loop backs (rework) very prevalent
 Resources and budget typically grows as project progresses and




moves to large (manufacturing) scale
Teams become cross functional as development process matures
Technology introduction and selection often driven by schedule –
not driven by data/knowledge
Often programs are large in scale – time to market
long, cost is high and much DIP (Design in Process)
Knowledge is not shared or reused effectively
5
C. Classic Product Development/Commercialization
Guild Method
 Old Time Inventor Style – single individual or group focused
 Focused on functional style management
 Product segments developed in silos and thrown over the fence:
 Development time long, much waste during the process due to
poor communication between product development chain,
customer doesn’t always get what they want….
 Most common style at small companies, success very dependent
on having right people at each juncture of the process
6
C. Classic Product Development/Commercialization
“All Hands on Deck” NPD Style
 “All hands on deck approach” – ala the program to land a man





on the Moon by the end of the 1960s – either a crisis stopgap or
“the BIG named program”
Larger companies -> assign the majority of the technical and
business resources to a key program
Focused on a Projectized Organizational structure but usually
without a strong PMO focus (many times co-run by technical or
business leaders)
Technical leader and technologist often minimize importance of
PM and often PM relegated to schedules and action item lists
Development time is short, development cost and waste is high
in order to meet a short timeline
Many times these projects get out of control if not well managed
(scope and budget creep)…
7
D. Lean Product Development
Origins of Lean Product Development
 Much of Lean Product Development born out of the US Air Force
fighter/bomber development process used in World War 2 (this
methodology allowed us to play catch-up to a technologically
superior enemy)
 Toyota and other Japanese manufacturers given the “manual”
during the rebuilding of Japan in the late 40’s and 50’s
 Japanese companies realized that they couldn’t compete with
huge assembly line manufacturers using the classic guild style
methodologies for either manufacturing or product development
 Japanese borrowed many ideas that were part of the US Air Force
process and honed them to bring us to where “lean product
development” is today
8
D. Lean Product Development
Lean Manufacturing:
 Inventory reduction
 Increased productivity
 Reduction in scrap and rework
 Reduce lead time from order entry to delivery of product from weeks to days
 Reduce changeover from hours to minutes
 Build to Order vs. Build Forecast
Lean Product Development:
 Reduced DIP (Development in Progress)
 Increased productivity & leveraging of knowledge
 Reduced loops backs and false starts
 Reduced development cycle time
 Increase flexibility to navigate changing marketplace
 Products that meet customer expectations at maximum value
to company
9
D. Lean Product Development – Tangible Benefits
Market Research:
 Development Cycle Times reduced by 30% 1
 Resource utilization improved by 70% 1
 New product performance measures improved by 33% 1
 Product Quality improved by testing early in development cycle by 38% 2
 Market share increased from 6% to 25% in one year 2
 Toyota Prius – development cycle time reduced by 38% 3
Kodak Film Development example:
 Reduced development cycle time by 50%
 Improved physical properties over 10x in a 3 year time period
 Maintained a payback of 4x development cost over life of development (>100 M$

over a 10 year period)
Reduced variability in multiple areas over the life of the product
1 Shooting the Rapids: Managing Product Devleopment in Turbulent Environments, Marco
Iansiti, California Management Review Fall 1995
2 Product Development Practices that Work: How Internet Companies Build Software, Alan
MacCormack, MIT Sloan Management Review Winter 2001
3 “The Toyota Way,” Jeffrey K Liker [Tata McGraw Hill, 2004]
10
D. Lean Product Development
 Lean Manufacturing:
1 Going Lean Stephen A. Ruffa (AMACOM 2008)
2 http://leanmanufacturingtools.org/wp-content/uploads/2012/02/house-of-lean1.jpg
11
D. Lean Product Development
Traditional Product Development – back end loaded
 Lean Product Development:
Set Based Flexible Design
Integration Focused
Lean Product Development – Load Level Flow
Leadership
Dynamic Cross Functional
Teams
Knowledge Sharing/
Continuous Learning Process
Essentially equivalent to
flow -> fewer projects at
a time but load leveled
R&D (work is not
back end loaded) – also
projects have reduced
cycle time & DIP
12
D. Lean Product Development – Target Examples
 Automotive – Toyota Prius 10
 Automotive – Harley Davidson 8
 Pharmaceutical – Ely Lilly Chorus unit 1
 Software – Microsoft Internet Explorer 3.0 6
 Computer Hardware – NEC SX-2 Project 7
 Computer Hardware – SGI Challenge Project 7
 Photographic Materials – EK Abrasion Improvement Project
 Photographic Materials – EK Technical Roadmap Development
13
D. Lean Product Development – Set Based Flexible Design
 Use of multiple options throughout the research/development process to






arrive at the optimum answer or series of answers
Options are arrived at through brainstorming and “try-storming”
Options are assessed and eliminated based on data/observations
Attempt to drive options to fast failure to define tradeoff curves
Options are not only assessed in a controlled experimentation mode but
also in integrating or benchmark experiments/events
Multiple options may even be carried through part of commercialization
Set based design should avoid loop backs late in the design process or
during costly parts of commercialization
14
D. Lean Product Development – Set Based Design Examples
 [NEC] Many concept possibilities discussed and modeled, most promising





were investigated at the bench scale. Close to the project end, one
technical option was chosen and the design was “frozen” at this point
[NEC] & [SGI] Use a flexible model of product development where many
options are explored and carried through process – this fluid design process
allows to react to changing specifications and “surprises” throughout the
development process
[Toyota] Design groups develop sets of solutions in parallel and gradually
narrow these sets based on additional information and experiments. By
focusing on convergence of the options rather than tweaking one solution –
Toyota reduces back tracking in the process.
[Toyota] In order to maintain flexibility, design groups converge to a final
solution as close to market introduction as possible.
[Microsoft] Uses an evolutionary approach to design that is flexible and has
an architecture that is modular and scale-able.
[Eli Lilly] Chorus uses experiments to drive to fast failure to reduce the field
of options and also vet other options efficiently
15
D. Lean Product Development – Integration/System Design Leadership
 Team leadership is driven from a system viewpoint – not at an individual






technology viewpoint
Flexible development requires joint evolution of the system (concept &
requirements) and technology/detailed design
Use of periodic integration or convergence events to examine both
individual and system performance
Team leader must facilitate integration approach along with monitoring
customer/sponsor requirements, marketplace conditions and schedule
Integration events are key for the technology selection process and
moving the project forward. Management reviews (gates) will usually
follow successful integration events
Phase/Gate system can still be used but gate reviews are more
informational in nature (schedule is driven by integration events)
Leadership style is dynamic and focused on knowledge based approach
16
D. Lean Product Development – Integration/Convergence
The Lean Machine, Dantar P. Oosterwal (AMACOM 2010)
17
D. Lean Product Development – Integration/System Design Examples
 [NEC/SGI] Shows a strong focus on exploring interactions between





concept decisions and design details. The interactions are explored
through prototype cycles (integration events).
[NEC] The integration group was formed with a responsibility to lead
both concept development and implementation over several project
generations
[SGI] Simulations and early prototypes help uncover problems before
committing to expensive complete and representative prototypes
[Toyota] Chief engineers perform vital systems integration activities by
controlling the narrowing process, insisting on broad exploration and
resolving disagreements across functions.
[Toyota] Emphasis on nemawashi – finding the best solutions for the
entire system – locates a solution at the intersection of the feasible
regions for the individual technologies
[Microsoft] Attempts to get a low-functionality version of the product (i.e.
integrated prototype) into customer’s hands at the earliest opportunity
18
D. Lean Product Development – Dynamic Cross Functional Teams
 Project teams need to be cross functional at the start of a project
 Sponsors and project leader should examine team membership and
define appropriate members – representatives should range from
research & development, manufacturing, supply chain, engineering,
finance, quality and especially customers (internal/external)
 Cross functional teams at the start of a project will lead to better option
generation, diverse thinking, concurrent engineering and better team
atmosphere
 Resource loading should be somewhat level during the life of a project –
not going up exponentially at the end to address loop backs late in
process
 Resource commitments will be dynamic – all functions will have different
time commitments depending on the stage of the project
19
D. Lean Product Development – Dynamic Cross Functional Teams
Examples
 [NEC] Early research done in laboratory and then customers brought in to
help with specifications. Members of research and the technology
integration were then brought in with knowledge of manufacturing, system
design and past technical approaches. Substantial resources are dedicated
before the concept is frozen.
 [SGI] Critical decisions are made by a “core” Business Team representing
wide variety of expertise from research, engineering, manufacturing,
marketing, quality etc…
 [SGI] Relies on lead customers to test products and partners with
universities and research institutions for sampling the latest trends
 [Toyota] The review committee makes final technology decisions based on
engineering, marketing, manufacturing and other feedback
 [Microsoft] Teams have broad-based experience of shipping multiple
projects. Also an architecture was used where separate component teams
fed into the product development
 [Microsoft] Customers have a chance to influence the design at a time that
the development team had the flexibility to respond.
 [Eli Lilly] Chorus taps into a network of external experts and vendors for
both information and evaluations the team cannot perform
20
D. Lean Product Development – Knowledge Sharing/ Continuous
Learning Process
"The essence of knowledge is, having it, to apply it (use and share it); not
having it, to confess your ignorance." Confucius
 Ineffective sharing or loss of knowledge is the key driver of having to





rediscover knowledge (waste), loop backs (more waste), design shortfalls
etc…
Knowledge sharing both within the team and outside of the team is key
to reducing cycle time for new products
Documentation and sharing of knowledge enables reuse of knowledge
effectively in both current and future projects
Documentation can be as simple as using a quick A3 with trade off
curves, or documenting and collaborating with Google Drive and Dropbox
or more elaborate tools like Asana, Sharepoint and Yammer. Regular
exchange of learnings between teams is also a key output.
Team leaders must make knowledge sharing and transfer a priority
Essentially projects should be viewed as a continual learning and
improvement process
21
D. Lean Product Development – Knowledge Based
Development
Product Development in the Lean Enterprise, Michael N. Kennedy (Oakley Press 2003)
22
D. Lean Product Development – Knowledge Sharing/ Continuous
Learning Process
 [NEC] Emphasis on discovering and capturing knowledge about





interactions between technical possibilities and the concept before
committing to a concept
[NEC] By keeping integration groups involved with several product
generations, group members were able to effectively utilize the
knowledge base to direct future products
[SGI] As a project progresses, the source code (specification) is shared
by all members of the team facilitating communication and integrating
individual efforts.
[Toyota] Uses trade off curves and design matrices (Pugh analysis) to
communicate feasible regions of design space and criteria around
concept selection
[Microsoft] Use of “daily builds” of software to check in new code
providing rapid feedback and knowledge transfer to the team.
[Eli Lilly] As data flows from the experiments, the team modifies the
experimental plans constantly to drive the experimentation as efficiently
as possible
23
E. Lean Product Development – Product Design Examples
 Film Development Program Example
 Program was focused to address an issue in the trade (premature failure of product)
 Creatively adapted stage/gate process to drive towards a set based design with a series





of product introductions to improve issue
Used brainstorming sessions early in the development phase to identify many
technology approaches that covered film design, customer processes and end use
projectors. Used six sigma design principals to optimize technologies
Utilized benchmarking events to assemble technologies and send samples for aggressive
testing and customer evaluations
Effectively used a consistent cross functional team containing R&D, product
development, manufacturing, customer reps, systems over the life of the project
Held several workshops, weekly team meeting w/extensive online notes, multiple gate
reviews, several patents/reports to facilitate communication
Through a series of commercialization programs introduced 3 products silently over a
three year period that dramatically improved issue (improved
performance over 10x) and silenced all customer complaints
24
E. Knowledge Based Set Design in Action
Development Programs – Pugh Analysis
Program 3
Program 2
Program 1
25
E. Lean Product Development – Product Design Examples
 Development Programs
26
E. Lean Product Development – Product Design Examples
 Development Technical Roadmap/Portfolio Definition
 Used lean development approach to generate and execute technical roadmaps for cost




reduction programs since 2004
Assembled a large cross functional group comprising of R&D, product development,
manufacturing, supply chain, purchasing, customer reps and systems to annually
brainstorm and define sets of technical options and programs. The team planned work
to drive towards development and commercialization of these technical options. This
team continued to work on the projects through development & commercialization
Utilized benchmarking events regularly to assemble technologies and verify technical
roadmap directions and schedule. Drove to fast failure with early production scale
coatings and customer assessments. Maintained a flexible development/concept
approach to maintain a steady stream of cost reduction projects
Held regular workshops, weekly team meetings and many gate reviews, communicated
with notes, patents/TRs – roadmaps and direction regularly reviewed/updated with team
Through a series of programs and smaller projects introduced over 10 products changes
silently over a eight year period that saved the company 3 M$ on a yearly basis but over
the lifetime of the product line is around 100 M$ -> payback of 4X versus development
cost.
27
E. Knowledge Based Set Design in Action
Film Technical Roadmap Definition – Roadmap 2007
28
E. Knowledge Based Set Design in Action
Technical Portfolio Analysis
Cost
Savings
Option
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Technology
Risk:
1 - Low
2 - Medium
3 - High
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
174
45
50
207
100
150
853
138
891
0
3119
1680
150
891
2070
690
150
-250
600
323
400
1191
690
2070
1035
Timing
(Months)
2
4
2
2
4
6
0
3
6
6
9
6
6
6
9
9
6
6
9
6
6
9
12
12
12
Value w t Risk (Ext
Proposed
Risk (Int) Customer Resources Introduction Cum Risk risk,res,time
1
1
1
1
1
2
1
1
1
2
2
1
2
1
2
2
2
2
2
2
2
3
2
2
2
1
2
1
1
1
1
1
1
1
1
2
1
1
2
2
1
2
1
1
2
2
2
1
3
2
1
1
1
1
1
2
1
1
2
2
3
2
2
1
3
2
2
2
2
2
1
2
3
3
3
Program 7
Program 7
Program 8
Program 8
Program 8
Program 8
Program 8
Program 9
Program 9
Program 9
Program 9
Program 9
Program 10
Program 10
Program 10
Program 10
Development
Development
Development
Planned
Planned
Planned
Deferred
Deferred
Deferred
1
1.333333
1
1
1
1.666667
1
1
1.333333
1.666667
2.333333
1.333333
1.666667
1.333333
2.333333
1.666667
2
1.666667
1.666667
2
1.666667
2.333333
2
2.666667
2.333333
174
34
50
207
100
90
853
138
669
0
1003
1260
90
669
666
311
75
-150
270
162
240
383
259
582
333
Resources:
1 - Low Resource requirements
2 - Medium Resource requirements
3 - High requirements - greater than 50% resources for a significant amount of time
Risk (Int) - includes technical and manufacturing risks along with uncertainty around cost reduction estimates
Risk (Ext Customer) - includes likelihood that external customers have issues with the change or reject performance of modified product
29
E. Knowledge Based Set Design in Action
Film Technical Roadmap Definition – Roadmap 2011
30
E. Lean Product Development – Product Design Examples
 Film Technical Roadmap Definition – cost savings over time
31
F. Conclusions
 Using lean product development methods does lead to reduced cycle




times, minimized rework (loop backs), higher returns for development
dollars and a more engaged product development team atmosphere
Lean tools are being applied in many different product development
areas ranging from automotive to computer to drug/chemical products
Use of set based design and integration/system leadership lead to a
flexible product development cycle that is responsive to rapidly changing
customer expectations and marketplace conditions
LPD is scalable for the product/technology scope
The Kodak film development area has adopted many of the lean
development concepts and set based design. The use of integrating
events at both bench scale and at full production scale as early as
possible has been critical for technology selection. Much of the success is
an outcome of maintaining a solid cross functional team with strong
communications and a high degree of knowledge sharing.
32
F. Recommendations
 Lean product development concepts can be implemented at any time in


the product development cycle
Possible first steps:
1. Encourage set based solutions and utilizing integration events early
in programs
2. Implement system based leadership on project teams and drive
towards a flexible product development process
3. Drive towards cross functional teams and involvement of customers
early in development
4. Foster knowledge sharing through simple A3 style reports and
usage of team knowledge sharing and collaboration tools
Both teams and leadership need to support the lean initiatives in product
development to be successful.
33
Discussion / Question and Answer
34
For More Information
 Chris Haller, haller188@gmail.com
Website: www.cjhaller.com/Portfolio.html
LinkedIn: www.linkedin.com/in/cjhaller/
 Resources list:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
A More Rational Approach to New-Product Development, E. Bonabeau, N. Bodick & N.
Armstrong (Havard Business Review March 2008)
Developing Products in the Half the Time, Preston Smith and Donald Reinertsen (Van
Nostrand Reinhold 1991)
Going Lean, Stephen A. Ruffa (AMACOM 2008)
Managing the Design Factory, Donald Reinertsen (Free Press 1997)
Product Development in the Lean Enterprise, Michael N. Kennedy (Oakley Press 2003)
Product-Development Practices that Work: How Internet Companies Build Software, Alan
MacCormack (MIT Sloan Management Review, Winter 2001)
Shooting the Rapids: Managing Product Development in Turbulent Environments, Marco
Iansiti (California Management Review, Fall 1995)
The Lean Machine, Dantar P. Oosterwal (AMACOM 2010)
The Machine That Changed the World, James Womack, Daniel Jones and Daniel Roos (Free
Press 2007)
Toyota’s Principles of Set-Based Concurrent Engineering, Durward K. Sobek II, Allen C.
Ward and Jeffrey K. Liker (MIT Sloan Management Review, Jan 1999)
35