1138577537

Visible Knowledge for
Flawless Designs
Visible Knowledge for
Flawless Designs
The Secret behind Lean Product
Development
By
Allen C. Ward
With Contributions by
Dantar P. Oosterwal
Durward K. Sobek II
A PRODUC TIVIT Y PRESS BOOK

Routledge
Taylor & Francis Group
711 Third Avenue, New York, NY 10017
© 2018 by Allen C. Ward with contributions from Dantar P. Oosterwal and Durward K. Sobek II
Productivity Press is an imprint of Taylor & Francis Group, an Informa business
No claim to original U.S. Government works
Printed on acid-free paper
International Standard Book Number-13: 978-1-138-57753-4 (Hardback)
International Standard Book Number-13: 978-1-138-57728-2 (Paperback)
This book contains information obtained from authentic and highly regarded sources. Reasonable efforts have been made to
publish reliable data and information, but the author and publisher cannot assume responsibility for the validity of all materials
or the consequences of their use. The authors and publishers have attempted to trace the copyright holders of all material
reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained.
If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint.
Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or utilized
in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying,
microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers.
For permission to photocopy or use material electronically from this work, please access www.copyright. com (http://www.
copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-
8400. CCC is a not-for-profit organization that provides licenses and registration for a variety of users. For organizations that
have been granted a photocopy license by the CCC, a separate system of payment has been arranged.
Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for
identification and explanation without intent to infringe.
Visit the Taylor & Francis Web site at

http://www.taylorandfrancis.com
and the Productivity Press site at

http://www.ProductivityPress.com
Contents
Foreword: How This Book Came to Be........................................................ vii

Preface: What You’ll Learn.............................................................................. xi
Acknowledgments.......................................................................................... xiii
About the Authors........................................................................................... xv
1 How and Why to Use Visible Knowledge............................................ 1
What Is Visible Knowledge?............................................................................... 2
The Basic Concept.............................................................................................. 5
How Visible Knowledge Changes the Development Process........................... 8
The Wright Brothers, “Understand Then Design,” and the P-51..................... 10
The Efficiency of Visible Knowledge................................................................14
The Problem...................................................................................................14
Overcoming the Objections.............................................................................. 21
Reference........................................................................................................... 22
2 How to Create Visible Knowledge.................................................... 23
Choosing the Issues to Investigate................................................................... 24
How We’ll Approach the Problem.................................................................... 24
Step 1: State the Issue................................................................................... 26
Step 2: Draw a Picture.................................................................................. 28
Step 3: Create a Causal Diagram.................................................................. 30
Substep A................................................................................................... 32
Substep B................................................................................................... 33
Substep C................................................................................................... 34
Substep D.................................................................................................. 34
Substep E................................................................................................... 35
Step 4: Finding Data and Creating Curves................................................... 38
Substep A................................................................................................... 40
Substep B................................................................................................... 40
Substep C................................................................................................... 42
Substep D.................................................................................................. 48
Step 5: Countermeasures.............................................................................. 53
v
vi ◾ Contents
3 Visible Knowledge and Companies................................................... 59

Organizing Your Knowledge............................................................................ 59
Changing Management Roles and Skills.......................................................... 62
Making Sure Your People Create Visible Knowledge...................................... 63
Conducting Effective Design Reviews.............................................................. 64
Changing Your Development Process.............................................................. 65
Changing the Research Organization................................................................67
Changing Supplier Relationships.......................................................................67
Changing the Test Organization....................................................................... 68
Conclusion: Better, Faster, Cheaper.................................................................. 69
4 Applying Visible Knowledge............................................................. 71
Establish a Visible Knowledge Mindset........................................................... 72
Summary....................................................................................................... 75
Alternative Ways of Building Visible Knowledge............................................ 76
Leveraging Existing Data.............................................................................. 76
Tapping the Experience of Seasoned Employees........................................ 77
Using Designed Experiments........................................................................ 79
Use Visible Knowledge to Enhance Cross-Functional Collaboration............. 82
Presentation Is Important................................................................................. 87
Leading the Change.......................................................................................... 90
The Journey Is Just Begun................................................................................ 94
Index....................................................................................................... 97
Foreword: How This Book
Came to Be
The year 2003 was the hundredth anniversary for the Harley-Davidson Motor
Company. As the director of product development, Dantar Oosterwal faced the
challenge of delivering on a promise of double-digit growth Harley-Davidson
had made to the street, and he did not know how to do it. For many years, the
demand for Harley-Davidson motorcycles far exceeded their ability to supply
them. At the peak, customers waited nearly 24 months to buy certain models.
The company’s greatest focus at that time was eliminating bottlenecks in manu-
facturing and logistics to get motorcycles out of the factory to waiting customers.
The only motorcycles on the floor of a dealership seemed to be those waiting to
be picked up or used bikes from trade-in. In the 1990s, Harley-Davidson invested
heavily in operations, doubling its manufacturing footprint in an effort to address
the supply issue. This investment resulted in record revenue and profits every
quarter as Harley-Davidson broke production constraints and shipped increas-
ingly more motorcycles to fill demand. At first, the incredible demand seemed
insatiable, and the growth promised to the street seemed sustainable. However, a
deeper look behind the numbers revealed that the increased product shipments
had eroded pent-up demand. By the early 2000s, the wait times for motorcycles
had dropped dramatically with the wait lists virtually eliminated, reflecting a sig-
nificant shift in the ratio of product demand to supply.
The “demand/supply” ratio is a crucial metric used for product planning and
an integral part of a system dynamics model of the motorcycle industry cre-
ated to evaluate various business and industry scenarios for decision-making. As
the ratio dropped, the model provided a tool to evaluate ways to increase the
demand/supply ratio. The alternatives evaluated ranged from reducing supply,
to traditional pricing and marketing plays, to increased product innovation. The
model identified several actions that could provide short-term demand/supply
ratio improvements, such as pricing. The analysis also identified that the only
meaningful and effective way to achieve sustainable revenue and profit growth
was through increasing the introduction rate of new products. The dilemma was
figuring out how to increase new product development throughput to drive the
double-digit growth that had been committed.
vii
viii ◾ Foreword: How This Book Came to Be
Compounding the situation, Harley-Davidson had focused for several years

on creating and instituting a systematic product development process based on
Stage-Gate methods. The company implemented the approach well—so well, in
fact, that the Product Development Management Association (PDMA) awarded
the company the Outstanding Corporate Innovator award in 2003. Despite being
identified as among the best at utilizing conventional methods, it was clear that
making conventional development methods a little (or even a lot) better would
not lead to the drastic increase in development throughput they needed. Dantar
concluded that Harley-Davidson needed to learn a better way of developing
products.
The quest for more effective approaches led them to Jim Womack who was
then the CEO of the Lean Enterprise Institute and an internationally recognized
expert in lean operations within companies. With the effectiveness that lean
methods had demonstrated in operations improvement, the thought of using lean
manufacturing methods to improve the product development system was very
appealing. However, Jim was adamant that lean product development was very
different from lean manufacturing, and that product development needed to
be approached very differently. When asked how product development should
be addressed, he did not have an answer, but suggested Dr. Allen Ward who
was studying lean product development methods at the University of Michigan
at the time. This was the beginning of a relationship that proved instrumen-
tal in the changes at Harley-Davidson and led to a much better way of product
development.
The first contact with Allen was not encouraging. He had become reticent to
work with companies out of the frustration he had endured in trying to get orga-
nizations to change the way they worked. Over a series of conversations, Allen
warmed to the relationship and realized that Harley-Davidson may be different
as he eventually agreed to be a mentor in the effort to change product develop-
ment. The work resulted in a close relationship as Allen provided insight to the
lean development methods he studied at the University of Michigan, and Harley-
Davidson strived to apply this in real-world applications. Both sides learned and
grew through the experience. Few people understood lean product development
like Allen did. He was able to not just observe and communicate what Toyota
did, but he had an infectious enthusiasm and insight into why things worked.
This enabled Harley-Davidson to adapt principles to Western work practices
and institute lean product development at one of the most iconic American
companies.
Tragically, Dr. Ward passed away when the plane he was piloting crashed
during a thunderstorm. Following Allen’s untimely death, Dantar reached out
for guidance to Dr. Durward Sobek, who had studied under Allen while he
had been a PhD student at the University of Michigan. The combined efforts at
Harley-Davidson were very successful. By 2006, Harley-Davidson had realized
nearly a five-fold increase in new product throughput over 2003 and the previous
15-year trend with the same people.
Foreword: How This Book Came to Be ◾ ix
This book has evolved out of a manuscript that Allen was writing at the time
he passed away. It is not intended to be a treatise of lean product development
methods. Quite the opposite—it is focused on one small piece, “visible knowl-
edge.” However, it is one technique that we have found to be very effective at
Harley-Davidson and other places, and a tool that can make a difference whether
used by itself or as a starting point for a larger journey into lean product devel-
opment. In fact, Allen claimed that trade-off curves (visible knowledge) is the
most powerful lean tool he encountered.
In completing this work, we have tried to keep the manuscript true to Allen’s
original intent. The preface and first three chapters are essentially Allen’s original
intellectual contribution. We have made editorial changes to improve readability
and clarity of explanation to make the manuscript publication-ready. Throughout,
we have attempted to preserve Allen’s voice in the writing, even keeping the
narrative in first person as it was originally written. We had to recreate most of
the figures because we did not have the original electronic files, and we took
the opportunity to make some enhancements and corrections. Most notable of
those enhancements are an expanded introduction in Chapter 1 and the trade-off
curve sheet template presented in Chapter 2 where we have adapted the tem-
plate based on more recent work on A3 reports. Thus, Chapters 1 through 3 are
Allen’s work with minor modifications compiled to complete the text.
However, we felt that the manuscript was incomplete because Allen was still
working on it at the time of his death. We also felt that much more could have
been said because our understanding of visible knowledge had expanded in the
years since, especially in its application within actual company contexts. So, we
added a fourth chapter that was not in the original manuscript with the idea of
filling in a few gaps and providing practical examples of applying the concepts
or implementing them in practice. You may notice a change in voice in Chapter 4
as we shift from Allen’s original contribution to our own experiences and learn-
ing. Hopefully, you will find this added content equally interesting and perhaps
just as useful.
We are indebted to Allen for his depth of insight and intellectual capacity,
and are privileged to present this “secret” behind lean product development. Our
intent in publishing this book is to share a tool that can help you improve the
output of your product development system and achieve dramatic gains in your
competitive status. May you do so and more, and please visit www.developlean
.com to let us know how you have used visible knowledge to create flawless
designs.
—Dantar Oosterwal
Kalamazoo, MI
—Durward K. Sobek II
Bozeman, MT
Preface: What You’ll Learn
This book is for engineers, engineering managers, and development executives.

It describes the closest thing I know to an “engineering development secret.”
Visible knowledge is a tool nearly lost in the West, but it has been used to great
effect by Toyota in its 50-year march from noncompetitiveness to its current sta-
tus as the second largest automobile company in the world. It is key for the 50%
growth in market share Toyota plans for this decade, despite worldwide overca-
pacity in the auto business.
The book has three sections.* In Section 1, you’ll learn the basics of visible
knowledge: what it is, how it can transform your development process, and how
and why to use it. You’ll also learn how these skills achieved astounding results
in the American aircraft industry—and how they were lost again.
In Section 2, you’ll start learning the hard part: how to create visible knowl-
edge. This section will give you enough to start creating useful visible knowledge
for your company. But, I have to warn you, you will only be starting a long jour-
ney toward expertise—this is a skill bordering on art. In fact, you will essentially
be learning a step-by-step process for “doing engineering design right.”
In Section 3, you’ll step back and put visible knowledge in an organizational
context. How will you manage the knowledge? How will you apply it, conduct
research, establish supplier relationships, design for manufacture, conduct train-
ing, and so on? How will you change your design process? Your management
approach? Your test organization?
Finally, I’ll encourage you to ask the question, “How will visible knowledge
affect my competitive status?”
* Allen’s original manuscript had three sections. In completing this work for publication and book form,
the sections were built out into chapters and a fourth chapter was added as described earlier.
xi
Acknowledgments*
I would like to thank the following people for their hard work and dedication
in making the original manuscript possible: Jeff Chen, Geoff Rideou, and Calle
Wilholm provided excellent suggestions for improvement. The Associations
of Danish Industry supported the initial draft; without the encouragement of
Kristian Stockbro, it might never have come to life. Delphi supported a great deal
of related work; many engineers at the company experimented with trade-off
curves of their own, teaching me to teach them. Lee May worked long and hard
to format it. And, of course, as always, the example and tutelage of dozens of
people at the Toyota Motor Company provided the foundation of the work.
* These acknowledgments are from the original manuscript, and are thus Allen Ward’s. All first-person
references here and in Chapters 1 through 3 are to the author, Allen Ward.
xiii
About the Authors
Allen C. Ward is considered by many as the patriarch of lean product

development. According to James Womack, founder of the Lean Enterprise
Institute, “although many have studied Toyota as astute observers, few truly
understood what they were observing and extracted the principles that made
Toyota’s methods effective.” Since it is generally not possible (or even reasonable)
to duplicate Toyota’s product development system in other companies directly,
it is critical to understand why it works in order to leverage the principles in
other companies. Based on a decade of direct research at Toyota, Dr. Ward
provides tremendous insight into what is important for effective development
processes and how they work. Although he died in 2004, Dr. Ward is still seen
as a prominent figure in the lean product development movement and held in
high esteem by those who want to learn lean development methods. Dr. Ward
is author of the book, Lean Product and Process Development, considered by
many to be the authoritative text in lean product development; and co-author of
numerous academic papers on engineering design theory and methodology.
Dantar P. Oosterwal is a lean product development practitioner, advisor,

speaker, and author. Oosterwal first learned and drove implementation of lean
product development methods as director of product development at Harley-
Davidson. This effort led to a four-fold improvement in product development
throughput and over 50% acceleration in time-to-market with a customer satisfac-
tion level of 98% repurchase intent. Later, as global vice president of innovation
at Sara Lee, he led the implementation of lean product development methods,
which resulted in a 30% improvement in product development throughput
and a four-fold increase in revenue from new innovation. He co-founded the
Milwaukee Consulting Group focused on helping organizations implement con-
tinuous improvement principles. Dantar is the author of the Shingo Prize winning
book, The Lean Machine, which describes the lean product development transfor-
mation at Harley-Davidson. As an avid proponent of lean product development,
he continues to promote lean product development and share his experiences to
help companies learn and institute lean development practices. He writes articles
and is a popular speaker at events. He has recently co-founded Develop Lean
(DevelopLean.com) to help promote lean product development practices. Dantar
xv
xvi ◾ About the Authors
holds degrees from the University of Michigan and the Massachusetts Institute of
Technology (MIT).
Durward K. Sobek II is a professor and program coordinator of Industrial and

Management Systems Engineering at Montana State University. He holds PhD
and MS degrees in Industrial and Operations Engineering from the University of
Michigan, and an AB degree in Engineering Sciences from Dartmouth College.
Dr. Sobek has been researching lean product development and lean healthcare
for two decades, focusing on how organizations can increase their performance
capacity through the application of lean principles. He is co-founder of the not-
for-profit Lean Product and Process Development Exchange, Inc. whose mission
is to share and expand the body of knowledge around lean product and pro-
cess development. He is a frequent presenter, and has written published articles
in Harvard Business Review, Sloan Management Review, and IEEE Transactions
on Engineering Management among other publications. He is co-author of Lean
Product and Process Development, 2nd edition, with Allen C. Ward; and co-
author of the Shingo Prize winning book Understanding A3 Thinking: A Critical
Component of Toyota’s PDCA Management System.
Chapter 1
How and Why to Use

Visible Knowledge
Let’s face it—designing something new can be fun. Fun, but hard. It becomes
even harder when the project is large enough that a team is required, and harder
still when that team involves people from different backgrounds and disciplines.
Many books and articles have been written about better ways to engineer or
develop new products. They introduce tools, techniques, and methods to design
and develop faster, cheaper, and with better quality. Some of these tools and
methods are helpful; however, nearly all that I have seen are based on the same
basic assumption that design is iterative. Since we can’t possibly know how a
design will function until we try it, we have come to accept that the only realistic
approach is to generate one or more ideas; “try them” through analysis, simula-
tion, or prototyping; find how and where they fail; then make changes and try
again. Typically, these iterations continue until we feel we have an acceptable
design or we run out of time.
But what if I told you that this is not necessarily the case, that there is a bet-
ter way of engineering that substantially reduces, if not eliminates, reactive design
iterations? And if we eliminate these Design-Build-Fix iterations, we will see lead-
times tumble, realize drastic improvements in quality, and become consistently
predictable, all resulting in increased business opportunity and success. You might
say I’m crazy or say that it sounds like a silver bullet. While I agree that there are
no silver bullets to all that ails product development, I am not crazy. There is a tool
that few companies use but has demonstrated potential to dramatically transform
your development process for the better. That tool is visible knowledge.
What makes visible knowledge so transformative is that it changes the design
process from “try something” and see how it works to understanding the phys-
ics and economics of a design concept as it relates to your customer needs first,
before committing to a design. In other words, the process becomes knowledge
based or knowledge driven versus iterative. By using the techniques in this book
to make that knowledge visible, many benefits result, including deeper technical
1
2 ◾ Visible Knowledge for Flawless Designs: The Secret behind Lean Product Development
expertise acquired more quickly and shared across projects, efficiently identifying
feasible regions of the design space, effective communication of technical infor-
mation to nonexperts, and improved cross-functional collaboration. Together,
these result in quicker, more reliable decision making that, in turn, results in bet-
ter designs delivered faster, more economically, and with greater predictability—
in short, more effective product development.
Intrigued? I hope so. In this chapter, we’ll use examples to learn what visible
knowledge is, how to use it, when to use it, and how it changes the development
process. From a foundational perspective, we’ll examine the birth of aerospace
engineering in which visible knowledge played a key role in the rapid advance-
ment of that field. We’ll save the hard question of how to create visible knowl-
edge for Chapter 2. Chapter 3 then addresses the changes visible knowledge
produces within the product development organization. Finally, Chapter 4 will
discuss how to apply visible knowledge in your organization.
What Is Visible Knowledge?

Visible knowledge is a tool that lets you
◾◾ Understand the meaning of your engineering and economic data, for effi-
cient creation of optimized, reliable designs.
◾◾ Reuse the data you gain during a development process, to accelerate future
developments and reduce future testing.
◾◾ Conduct rapid and effective design reviews, even if you are not an expert in
the technology being reviewed.
◾◾ Communicate effectively between functions and companies, creating team-
work and concurrency.
◾◾ Make your development process more predictable and, therefore, manageable.
What is the evidence? Visual knowledge is the primary tool that enables Toyota
to design entire automobiles in 12 months from styling approval to production,
without building and testing prototypes. Complete cars with no prototype builds!
Visible knowledge allows Toyota to design systems they know will work and
won’t have to test postdesign.
And, Toyota claims to never have missed a launch date—they never have
surprises in the late stages of development large enough to prevent them from
launching on time. (Toyota also has very smooth launches, ramping up to full
production in one or two weeks.)
Here’s an example of the value of visible knowledge. Suppose you are the
manager responsible for the crankpins that join the connecting rods of an engine
to the crank, as show in Figure 1.1. Experience shows that these pins are criti-
cal and a common failure point; yet they should also be made as small as pos-
sible to minimize the moving mass in the engine. The load on the pin is partly
How and Why to Use Visible Knowledge ◾ 3
Connecting rod
Crank
Crankpin
Figure 1.1 Engine crank.
vibrational and cannot be accurately predicted from equations or simulations. So,

you have to rely on experience, judgment, and testing.
Your company has sold seven different engines, all using the same material
for the crankpin. In each case, the pin was a tube, and the inner diameter was
held at 0.5 inches. The relevant data for them is shown in Table 1.1. (All the data
in this book has been made up to illustrate the points, so please don’t use it to
design engines.) The design team for the eighth engine proposed the characteris-
tics shown as the last line of Table 1.1.
Is this a good design from a warranty standpoint? Take a little time and see
whether you can decide. How confident are you?
It’s pretty hard to be sure, isn’t it? In fact, I don’t even have a guess. So let’s
put the information in visible form, plotting the warranty cost per engine sold
against the generalized stress value in a trade-off curve (see Figure 1.2).
Table 1.1 Engine Data Related to Crankpin Failure

Pin Pin
Piston Peak Stroke Pin Working Compression Failure Units
Engine # Diameter RPM Length Diameter Length Ratio Warranty Sold
1 3.3 7,500 3.1 0.8 1.2 11 70,000 6,000
2 3.5 6,000 3.0 1.1 1.0 10 60,000 15,000
3 3.0 7,000 3.2 0.8 1.1 8 60,000 8,000
4 2.8 8,000 2.5 0.75 0.75 10 35,000 7,000
5 3.3 7,000 3.0 0.8 0.9 11 150,000 9,000
6 3.6 5,500 4.0 1.1 1.2 8 110,000 20,000
7 3.2 6,000 3.0 1.2 1.0 10 10,000 3,000
8 3.3 7,000 3.2 1.0 1.2 9 ? ?
$18
5
$16 Safe region Infeasible region
$14
Proposed
$12
Warranty cost per unit
engine 1
$10
$8
3
$6
6
4
$4 2
7
$2
$-
0 50 100 150 200 250 300 350
Generalized stress value
Figure 1.2 Relationship of warranty cost to generalized stress value.
You don’t need to understand the generalized stress value to use it. We’ll look
at how to derive such parameters in Chapter 2. In this case, it is the weighted
sum of two factors:
1. The inertial stress factor reflects the stresses caused by the inertia of the
piston.
inertial stress factor = (stroke)(piston dia.)3(rpm)2(pin working
length)/(pin dia.)3
2. The compression stress factor reflects the stresses caused directly by the
combustion in the cylinder.
compression stress factor = (piston dia.)2(comp. ratio)(pin working
length)/(pin dia.)3
Notice that these are not the actual stresses, which we don’t know, but they
make sense based on the physics, and they produce a smooth, plausible, and
useful curve.
Now can you tell whether this connecting pin design makes sense from a
warranty standpoint? Take a moment and study the picture. It’s pretty easy, isn’t
it? The data shows that above a generalized stress value of about 200, the war-
ranty costs begin to increase rapidly with increasing stress. We’ve labeled that the
infeasible region. At 200 or less, the generalized stress has relatively little effect
on warranty costs, so we’ve labeled that the safe region. Generalized stress for
the proposed engine is about 185, just inside the safe region, making that a logi-
cal place to set the pin diameter.
The Basic Concept

Let’s generalize the process we just followed:
1. Assemble data about a set or family of products (or manufacturing pro-

cesses, suppliers, etc.).
2. Find a combination of variables that makes sense from the data. The com-
bination of factors may not be a standard equation, but together represent
a logical representation of the variables involved and identify a correlation
between input (independent) and output (resultant or dependent) variables.
3. Show the data visually, so that we can see the limit between the safe and
infeasible regions, or the trade-off of the output change as a function of
input variables.
4. Pick a design solution in the safe region that optimizes the trade-off variables.
Sometimes the safe region is limited by a critical point on the curve, as in the
example we just saw. Other times, it is established by an external limit based on
the dependent variable (usually the vertical axis), which in turn sets a limit on
the independent variable (usually the horizontal axis), as depicted in Figure 1.3.
Sometimes the curve itself sets the limit, as illustrated in Figure 1.4.
Sometimes we will show limits on a diagram in three dimensions, such as for
the cantilever beam made from a pipe shown in Figure 1.5. In Figure 1.6, I’ve
plotted stress as a function of tubing thickness and radius for a given moment
load.
And, sometimes, we will only need limits on a single variable, as in the exam-
ple seen in Figure 1.7.
Absorber efficiency
100
90
80 Required efficiency
70
60
% Efficiency
50 Safe
region
40
30
20
10
0
100 250 400 550 700
Temperature (ºF)
(This graph shows that for the absorber in a catalytic converter, the required
efficieny can be maintained only if the temperature is kept in a narrow range.)
Figure 1.3 Absorber efficiency curve.

Exhaust system family limits
Safe region
Sound level
Infeasible region
Back pressure
(This is the first trade-off curve I saw, when I first started researching Toyota. A Sango engineer
had just explained to me that Toyota required them to prototype 10 to 20 exhaust systems
for each new design. The reason, he said, was that Toyota wanted to know the trade-offs
for example, between sound level and the exhaust gas back pressure. One the Toyota
engineers knew the trade-off: they could decide where they wanted to be on the curve,
but they didn’t need to waste time demanding an impossible level of performance or settle
for an inferior one.)
Figure 1.4 Exhaust system trade-off curve.
Load
Figure 1.5 Cantilever beam diagram.
1.6×10+04
0.08 Safe
region
1.4×10+04
0.07
PVC limit
2.0×10+04
1.8×10+04
0.06
Thickness
2.2×10+04
1.2×10+04
0.05
2.6×10+04
Steel limit
0.04 2.4×10+04
3.0×10+04
3.2×10+04 2.8×10+04
3.4×10+04
0.03
0.8 0.9 1.0
Radius
Figure 1.6 Stress limits for steel and PVC pipe (in MPa).
Break or radius all edges at

least 0.03 mm to prevent nicks
Figure 1.7 Limit on a single variable.
Trade-off curve information is not limited to technical use: some of the most
important trade-off curves describe customer preferences. For example, marketing
research is usually provided to development teams in the form of requirements.
This limits the team’s freedom of action, often producing launch delays for fragile,
overly complex products. It always produces poorly optimized designs, because
the requirements are a guess about the appropriate compromise between cus-
tomer desire and engineering feasibility. (Customers want infinite performance,
zero weight, and zero cost; “requirements” are guesses at what we can provide at a
profit, and marketing departments’ guesses are often off the mark.)
A good customer value trade-off curve is far more useful than a requirement.
For example, rather than assigning a maximum weight to the product, we create
a curve showing the relationship between weight and the amount the customer
would pay above the standard price for the product as a function of the year of
launch, as shown in Figure 1.8.
Of course, this information is a guess—but so are requirements. This way, the
guess is visible, where we can discuss it. By discussing and documenting our
best assumptions, we are able to create visible knowledge as a basis for learning
as we improve our understanding with each product launched.
+25
80 kg
Actual
Average
Delta $ from nominal price
product
weight
Projected +10
–10
–25
1990 2000 2010 2015
Delta kilograms
from “expected standard”
Figure 1.8 Customer value curves with fuzzy limits.

No matter how we show it, our goal is to see the limit, the boundary between
the safe and infeasible regions and the trade-offs associated with the decisions
we make. This lets us approach the optimal design while staying in the safe
region and be overt in the decisions we make. We can choose how close we
want to be to the boundary of safety, trading off risk and other factors with the
need for more testing against performance.
What, then, is the difference between visible knowledge and conventional
design standards? With conventional design standards, we attempt to tell people
what to do, usually in words. In many cases the standards or requirements conflict,
often because they are arbitrarily established. With visible knowledge, we try to
◾◾ Represent the information visually.

◾◾ See “why,” by identifying basic causal relationships.
◾◾ Show the data and assumptions, updating the knowledge each time we get
new data.
◾◾ Show the maximum limits within which design engineers are free to choose
and adapt.
◾◾ Identify countermeasures for cases where the safe region is not acceptable.
◾◾ Focus on the relationships between variables, rather than one variable at
a time. (Notice that our single-variable example above is not very good,
because nicks depend on the environment and the hardness of the material,
as well as the radius. It would be better to show a series of curves: required
radius as a function of material hardness for different use environments.)
◾◾ Use our understanding of physics and customer needs to combine many
variables into a single picture. (For example, the exhaust system design limit
is not very good: we should show something more like the relationship
between two ratios: audible noise over exhaust energy and back pressure
over exhaust system weight.)
As we will see next, this focus on limits can dramatically improve our
development process.
How Visible Knowledge Changes the Development Process

The following are two significant problems with conventional development processes:
1. They cannot promise to produce optimal designs.

2. They are unpredictable and, in turn, unmanageable.
To understand this, let’s examine the conventional development process, which

looks like the process depicted in Figure 1.9.
The company has a research organization that (we hope) generates many
ideas, in a “fuzzy,” unpredictable, creative process. Management then decides
“Failure” “Disaster”
Pick Generic
Specifications
Consider one design
many “Prove” Detail
Validate Launch
concepts feasibility design
Research Advanced Analyze, simulate,

(“the fuzzy front end’’) development prototype, and test
Figure 1.9 The conventional development process.
in a meeting or through a structured discussion which idea to pursue, and

launches a project.
This is the biggest impetus for far-from-optimal designs. This selection of the
basic concept to work on is the most important decision in the development
process. Yet, there is very little chance, given how little information is available at
this point, that this decision will hit on the best concept.
Advanced development then tries to prove that the idea will work. This can
take a short time, or it can take forever: many apparently good ideas are not fea-
sible. When feasibility is evaluated, it is generally on a rudimentary aspect of the
design and does not encompass the complexities the final design will encounter.
If and when the idea leaves advanced development, it goes through a detailed
design process where it is tested, analyzed, and/or simulated to validate that it
meets requirements.
Often, the design fails validation, and must be returned for redesign. The num-
ber of such iterations is unpredictable. The unpredictability means that the process
is basically unmanageable—we have to just try and hope. And the more complex
the design, the more unpredictable the process, because changes in one subsystem
may force changes in another, forcing changes in a third, and so on indefinitely.
As we have noted, requirements are themselves guesses. But the validation
process treats them as if they were absolute limits. Fundamentally, “validation”
is impossible. In the modern world, a design is a failure if one part in a million
fails, but there is no possibility of testing a million parts. Moreover, there is no
possibility of testing all these parts under all the circumstances they may face
in the field. If parts do pass validation, they may be just this side of the edge of
disaster, but we have no way of knowing how close to disaster our designs are
when they pass the test.
So, fairly frequently, with variations or conditions slightly different from stan-
dard tests, we discover the edge of disaster. Sometimes this occurs during manu-
facturing launch or (less often) the field, and the system must be redesigned,
further hindering any attempt to manage the development process.
Of course, this description is highly simplified—it leaves out tooling, planned
iterative loops, the distinction between system design and component design,
and so on—but it captures the essence of the issue. We can call this conventional
development practice a design-and-test methodology, with the understanding that
tests may be physical, analytical, or computational. Design-and-test produces rela-

tively poor designs over a time period that cannot be predicted or managed.
The irony is that a better development process was discovered at the begin-
ning of the twentieth century, repeatedly proven through dramatic successes, and
mostly lost after World War II.
The following section explains what happened.
The Wright Brothers, “Understand Then Design,” and the P-51

Around 1900, the Wright brothers found a problem with design-and-test methodol-
ogy, mainly that testing heavier-than-air flying machines often killed the pilot. They
wanted to live, so they invented a different process: test then design (Figure 1.10).
The Wrights were the first to use a wind tunnel to investigate the properties of
airfoils, systematically determining the effect of angle of attack on lift, somewhat
Figure 1.10 The Wright brothers’ 1902 prototype flyer. (Courtesy of NASA, 2014. Wright
Unpowered Aircraft. https://wright.nasa.gov/airplane/kite00.html.)
Table 1.2 Sample of Airfoil Lift Data

Airfoil 8 9 10 11 12 13
Lift begins at: −2.75 −2.75 −3.0 −2.75 −2.5 −4.0
Angle of Attack Rectangular Pressure (Coefficient of Lift)
0.0 0.185 0.185 0.183 0.162 0.145 0.191
2.5 0.401 0.361 0.417 0.373 0.311 0.345
7.5 0.531 0.510 0.595 0.563 0.515 0.505
10.0 0.839 0.839 0.784 0.802 0.839 0.656
like Table 1.2. They used this knowledge to design wings and an efficient propel-
ler (they recognized that a propeller was simply a spinning wing), and to identify
the maximum safe angle of attack—what we would now call the stalling angle.
They developed, tested, and integrated control systems using tethered kites and
gliders, thereby learning the relationship between angles of bank and turning
radius. They found that, contrary to nearly universal assumption, lack of power
was not the critical problem—control was.
The Wrights attempted powered flight only after they understood the boundaries
between safety and death. The Wrights didn’t just invent the airplane, they invented
aeronautical engineering. In contrast, Louis Bleriot, their great French competitor
and the first to cross the English Channel, somehow survived crash after crash in
a design-and-test process. Samuel Langley, director of the Smithsonian Institution,
attempted an automatic flying machine so that crashes would be acceptable!
In fact, the Wrights followed a process as rare then as it is now—an under-
stand-the-limits-then-design process, as shown in Figure 1.11.
They first conducted a research process, creating a knowledge base that
encompassed many possible concepts intended to explore the limits of possibili-
ties and identify trade-offs, eliminating those concepts proven inferior. Then,
they combined the concepts, eliminating those that would not fit together, and
conducted more tests on the combinations to develop more knowledge, always
looking for the limits. Finally, they launched a safe, optimized design.
People usually suggest at this point that this process looks expensive: how can
it be cheaper to look at many ideas rather than at one? But in fact the cost of evalu-
ating an idea increases exponentially as the project continues (see Figure 1.12).
The Wrights’ “set-based” process focused on evaluating ideas thoroughly but
early, when it is cheap. They demonstrated a great deal of ingenuity in finding
inexpensive ways to gather the data they needed.
It worked: The Wrights invented the airplane in less than five years from
their initial experiments, aided by their sister with her sewing machine and one
engine mechanic. Bleriot was a rich man and a fearless one; Langley was sup-
ported by government money and avoided actual piloted flight. Both could afford
to look at only one idea at a time. The Wrights could not.
While the Wrights systematically developed limit information, they often
left it in the form of tables rather than visual curves. The next generation of
User/market needs Safe

optimized
design
Detail, mix and match, find
Find
more limits, and kill Launch
limits
concepts
Knowledge
base
Research
“Knowledge”
Figure 1.11 The knowledge-based development process.

Conventional process
Cost of evaluating an idea

operates here
“Set-based” process
operates here
Project timeline
Figure 1.12 Cost of evaluating an idea versus project time.
aeronautical engineers, however, brought visual knowledge to a peak of refine-

ment. By the 1930s, the average aeronautical engineering paper was built around
one or more curves. The National Advisory Committee for Aeronautics (NACA)
published airfoil catalogs with sophisticated curves describing the relationships
between Reynolds’ numbers and lift and drag coefficients as a function of angle
of attack—an enormous compression of information (Figure 1.13 shows an exam-
ple of NACA airfoil curves). “Test to find limits, then design within the limits”
was the order of the day.
This use of visual knowledge enabled the 1943 design of the P-51 Mustang in
six months, from blank paper to production. The Mustang (Figure 1.14) may have
been the best piston engine fighter ever built, at half the cost of its competitors,
and was so reliable that they continue to dominate piston engine aircraft racing.
This may have been the fastest successful development of a complex machine in
history.
During the 1980s, Jose Rodriguez interviewed several survivors of the Mustang
design team. They told him the key to success was visible knowledge of the limit
curves. (They worked primarily with “nomographs,” a more precise but trickier
refinement.) Said one team member, “We already knew all the trade-off curves;
all we had to do was decide where we wanted to be in the trade-off space.
But after WWII, we got computers. With computers, we designed it first, then
simulated it, then changed the simulation. Now, it takes us 20 years to design a
fighter.”
In other words, by reducing the cost of testing (in the form of simulation),
computers revived the practice of design then test. (The irony is that computers
could easily have been used instead to develop visible knowledge more quickly.)
Meanwhile, Toyota probably learned to use trade-off curves from the superb
Japanese aircraft engineers it hired after World War II—its first hiring of a signifi-
cant number of degreed engineers. Toyota’s isolated geographical location had
made it impossible to hire the knowledge required to build automobiles success-
fully, forcing the company to focus on efficiently learning the knowledge it needed
20
Sta. Up’r. L’w’r.
10
of chord
Percent
0 0 0
1.25 1.420 –1.420 0
2.5 1.961 –1.961 –10
5.0 2.666 –2.666
7.5 3.150 –3.150 0 20 40 60 80 100
10 3.512 –3.512 Percent of chord
15 4.009 –4.009
20 4.303 –4.303
25 4.456 –4.456
30 4.501 –4.501
40 4.352 –4.352
50 3.971 –3.971
60 3.423 –3.423
70 2.748 –2.748
80 1.967 –1.967
90 1.086 –1.086
95 0.605 –0.605
100 (.095) (–.095)
100 0 0
c.p. in percent of chord (from forward end of chord)
28 0 L.E. Rad.: 0.89 CL

c.p.
24 20
20 40
L/D
16 60
Ratio of lift to drag. L/D
12 80
8 100
4
CD
0
Airfoil: N.A.C.A. 0009 R.N.: 3.210.000
Size: 5"×30" Vel. (ft./sec.): 68.5
–4
Pres.(st'nd.atm.): 20.8 Date: 1 – 6 – 32
Where tested: L.M.A.L. Test: V.D.T. 746
–8 Corrected for tunnel-wall effect.
–8 –4 0 4 8 12 16 20 24 28 32
Angle of attack, α (degrees)
Figure 1.13 NACA airfoil curve. (From Jacobs, E. N., K. E. Ward and R.M. Pinkerton. 1935.
National Advisory Committee for Aeronautics Report No. 460. https://ntrs.nasa.gov
/archive/nasa/casi.ntrs.nasa.gov/19930091108.pdf.)
Figure 1.14 P-51 Mustang fighter. (Courtesy of https://s-media-cache-ak0.pinimg.com

/originals/60/12/22/6012225ec2f8ee19f39a64af8ec03c1a.jpg.)
from experience. Toyota was a learning organization out of necessity. It had few
computers. And Toyota was convinced that the interactions between engineers
were more important than what any individual engineer did—that people needed
to be able to explain why they wanted to use an approach, so that their arguments
could be compared with those of others. Trade-off curves were perfect for Toyota’s
purposes, and they became a fundamental part of Toyota thinking.
The American shift backward in design process was reinforced by a change
in teaching and management practices. U.S. universities after World War II
focused their attention on research and teaching engineering students equa-
tions rather than design, and as a result the students had little opportunity to
learn good design methodology. Almost all university faculties are now selected
as researchers, primarily, and have very little engineering design experience.
Creating curves takes longer than plugging numbers into an equation and
increases the grading burden. Testing by number-plugging is more efficient
from the professor’s viewpoint, although it is highly inefficient from the view-
point of the design engineer.
Similarly, most engineering managers, unlike their pre-World War II predeces-
sors or their Toyota counterparts, are encouraged to keep their distance from the
messy details of engineering and focus on management. Thus, both professors
and managers are blinded to the fact that design then test—whether by equation,
a finite element model, or physical prototype—is much less efficient than find
limits, then design.
Are you skeptical? The next section illustrates by example how much more
efficient visible knowledge—trade-off curves—is than equations and numbers.
The Efficiency of Visible Knowledge

Here’s an example of a simple but realistic engineering problem. (It happens to
be a mechanical engineering problem, but all the data and equations are pro-
vided, so don’t worry if your mechanical engineering skills are rusty—you can
just run through the calculations.)
First, write down the current time. Then, work out the answer to the problem
below. Check the time again, and write down how long it took you to solve the
problem—or give up. If you give up, estimate how long it would have taken you
to solve the problem and find an optimal solution.
First, try solving the problem using calculations.
The Problem
You are designing a simple crane to lift a maximum load of 1000 kilograms, for a
force at the tip of the crane boom of 9800 Newtons. The boom of the crane will
extend 1.6 meters horizontally from its support braces; the critical bending stress
takes place at the saddle support (Figure 1.15).
1.6 meters 0.5 meters
Point of
maximum
bending
Point of
stress F2
9800 Newtons maximum
compressive
stress from
saddle support
End view of saddle support enlarged
Figure 1.15 A simple crane.
Table 1.3 Schedule of Standard Pipe Sizes

Wall Thickness (mm)
Outside
Inch Nominal Diameter Schedule Schedule Schedule Schedule
Size (mm) 5S 10S 40S 80S
1¼ 42.2 1.65 2.77 3.56 4.85
1½ 48.3 1.65 2.77 3.68 5.08
2 60.3 1.65 2.77 3.91 5.54
2½ 73.0 2.11 3.05 5.16 7.01
3 88.9 2.11 3.05 5.49 7.62
3½ 101.6 2.11 3.05 5.74 8.08
4 114.3 2.11 3.05 6.02 8.56
5 141.3 2.77 3.40 6.55 9.50
You want to make the boom from a steel pipe, selected from a catalog of
available standard pipes, as shown in Table 1.3.
Pipes of a particular schedule are designed in more or less the same way: 5S
pipes have thin walls, 80S pipes have thick ones.
You want the lightest and therefore cheapest pipe (mild steel is sold by weight).
The density of the pipe steel is 7.872 g/cc, and the pipe mass per unit length, m, is
ρπ 2
m=
2
(
d − (d − t) (1.1)
2
)
where ρ is material density, d is the outer diameter of the pipe, and t is the thick-
ness of the pipe’s wall.
One possible source of failure is the bending stress, caused by the bending
moment. The equation for the maximum bending moment, M, in the pipe is
M = F ⋅ l (1.2)
where F is the force and l is length between the point of application and the
saddle support. Thus, the moment M at the support is (9,800 N)(1.6 m) = 15,680
Newton-meters.
The equation for the bending stress, σ, is
Md
σ= (1.3)
2I
where d is the pipe diameter and I is the cross-sectional moment of inertia. You
need to make sure that the resulting bending stress does not exceed 85% of the
yield strength of grade A pipe steel (which is 205 MPa, or 30,000 psi). The cross-
sectional moment of inertia is the characteristic of the shape of the pipe that
enables it to resist bending. The equation for the moment of inertia, I, is
π 4
I = d − (d − t)4  (1.4)
4 
where t is the wall thickness of the pipe and d is the diameter as before.
So, you can guess at a good pipe size, plug its values into these equations,
and iterate, looking for the lightest. (Does that seem crude, slow, and uncertain?
Is it basically the way your company does development?)
By the way, you also need to take into account the local compressive stresses
induced by the saddle support brace. According to Roark’s Formulas for Stress
and Strain,1 for a 90-degree saddle,
F2  d 
σ 2 = 0.03 ln (1.5)
t 2  2t 
where F2 is the force at the support. The two stresses have their maximums at
different points around the circumference of the pipe, and we won’t bother to
add them—we will just check them separately. The load force of 9800 Newtons
exerts a lot of leverage on the pipe, so the force at the support must be larger to
balance it: in fact, balancing the torque around the rear support, with the pipe
supports 0.5 meters apart, requires a force of (1.6/0.5)F. Adding these together,
you get
 1.6 
F2 = F +   F = 4.2 F = 41,160 Newtons (1.6)
 0.5
Now plug in the numbers for the pipe you have selected into Equation 1.5 above.
Does it pass the test? Is the resulting stress less than 85% of the yield strength of
pipe steel? If not, you will need to go back and try again.
Did you give up before finishing the problem? Are you sure you didn’t make
any mistakes? Are you sure that you found the lightest pipe? How confident are
you that engineers in your company never give up, and never make mistakes?
If you created a spreadsheet to make it easy to look at a number of solutions,
you are well on the way to a visible knowledge solution.
Now write down the time and try to solve the problem again, but this time
using the visible knowledge shown in Figures 1.16 through 1.18.
To select candidate solutions based on safe bending moment, draw a hori-
zontal line through the y-axis at the bending moment of 15,680 Newton-meters
40,000
80S
40S
10S
35,000
5S
30,000
25,000
Allowable moment (Nm)
20,000
15,000
10,000
5,000
0
0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5
Pipe diameter (inches)
Figure 1.16 Limit curves of allowable bending moments versus pipe diameter.*
* To create these curves, start with the bending stress Equation 1.3 and solve for M. Use 85% of yield
strength of the material for allowable bending stress, and substitute for sigma. Then calculate allowable
M for each pipe size using the diameter and wall thickness for each.
40,000
80S
40S
10S
35,000
5S
30,000
25,000
Allowable moment (Nm)
Safe region
20,000
Actual moment
15,000
Infeasible region
10,000
5,000
0
0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5
Figure 1.17 Safe region of feasible pipe sizes based on bending moment.
140
Safe region
120
Allowable compressive force (kN)
100
80S
80
40S
60
Actual compressive force

40
20 10S
5S
0
0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5
Figure 1.18 Limit curves of compressive force versus pipe diameter.

in Figure 1.16. (The moment M at the support is [9,800 N][1.6 meters] =15,680
Newton-meters as before.) All the points above the line now represent safe pipe
sizes of four different schedules; read the smallest safe pipe diameters in each
schedule from the x-axis, and write down the diameter and schedule number.
(My answers are given later in the chapter.) In case you don’t have a triangle
handy, I drew the bending moment line in Figure 1.17. Make sure you understand
that each dot represents a pipe with the bending moment it can safely handle; so
if the pipe’s allowable bending moment is greater than the actual moment, the
pipe is safe.
Now, you need to eliminate candidates based on allowable force for 90-degree
saddle: draw a horizontal line in Figure 1.18 through the y-axis at the saddle
force of 41,160 Newtons (identified from Equation 1.6 above). All the dots above
the line represent safe pipe sizes, since their allowable forces are greater than the
actual force: cross out the unsafe pipes from your list.
Lastly, to find the lightest surviving pipe, locate the diameters of the surviv-
ing pipes in Figure 1.19 and see which is lightest (the lowest dot on the vertical
scale).
180
160 80S
140
120
Mass per meter length of pipe (kg)
40S
100
80
60 10S
5S
40
20
0
1 1.5 2 2.5 3 3.5 4 4.5 5 5.5
Figure 1.19 Trade-off curves of pipe mass versus pipe diameter.

Now ask yourself these questions:
◾◾ This time, how long did it take you to find the lightest acceptable pipe? How
many times faster was it than calculating?
◾◾ How confident are you that it is correct, assuming the charts were correctly
drawn?
◾◾ Was your previously calculated answer correct?
◾◾ How hard would it be to check the correctness of the charts?
◾◾ Do the charts make intuitive sense?
◾◾ Which gives you a better understanding of the fundamental behavior of the
pipe used as a beam: the calculations or the charts?
◾◾ Which would give you a better fundamental understanding: the charts, or a
computer program that selected the optimum pipe and gave you the answer?
◾◾ If you saw these charts in a design review, with the values chosen for the
design plotted on the chart, how long would it take you to check the design?
◾◾ What if your marketing department suddenly informed you that the cus-
tomer had changed their maximum load requirement? How flexible would
you be to adapt and update your design?
◾◾ If the data given had been different—say, you were given a pipe size and
needed to determine maximum allowable loads—could you have used the
same charts?
The fact is that the part of your brain that processes mathematical information
is small; there are many computer programs that can do mathematical manipu-
lation better than any human. But the part of your brain that processes visual
information is large—no computer can see as well as a human. So, putting the
information in visual form lets you use the big part of your brain instead of the
small part.
If you wish to check your work, here are my results. Based on bending
moment, we could use any of these pipes:
◾◾ 5S 3 inch
◾◾ 10S 2.5 inch
◾◾ 40S 2.5 inch
◾◾ 80S 2 inch
Based on the compressive stress of the support, only the Schedule 40S and
80S pipes will work. Of these, the 80S pipe is lighter. The answer is 80S 2-inch
pipe.
Even if I’m going to do an optimization like this only once, and even if I have
a computer, it is much better to create the curves than to try to work with num-
bers. It’s faster, I make fewer mistakes, I understand more, and it’s easier to fol-
low along to see that it is correct.
I use two computer programs. Microsoft Excel is great for handling data in
tables and creating plots. LiveMath is a what-you-see-is-what-you-get algebraic
manipulation program that converts equations directly into graphs and lets you
combine equations without having to worry about dropping an exponent some-
where. I’d suggest that you get LiveMath or an equivalent such as MathCAD
because you will find that such programs come in handy during Chapter 2 as
well as in your work.
So now you know why Toyota and other lean or learning-based companies
put so much emphasis on visible knowledge:
1. It allows engineers to understand how their systems behave under variation.

2. It allows engineers to quickly get good answers, be confident they are right,
and see how close to the limit they are.
3. It allows managers who are not expert in the field to quickly check engi-
neers’ work.
4. It facilitates sharing of learning across projects and across the organization.
5. It allows engineers working on different parts of the system to quickly com-
municate with each other, thus optimizing the system.
Let’s look at that last point a little further. Different parts of the development
team have different kinds of expertise, so they generate different kinds of curves.
Each curve defines a safe region. We want to find the intersection of the safe
regions, and design within it. So, for example, using the exhaust system, we can
add lines that show a maximum noise limit (set by marketing) and a maximum
back-pressure limit (set by the engine designers). Besides enabling better engineer-
ing practices, visual knowledge facilitates cross-functional conversations, which
leads to better design optimization decisions across functions of the organization.
Overcoming the Objections

I hope you are enthusiastic at this point, but if you aren’t (or someone you need
to influence isn’t), let me try to deal with a couple of common objections.
Objection 1: “I already have a computer program that tells me whether my
designs meet the criteria. I don’t need this.”
Answer: Sure, but does your computer program tell you which factors are
important, and how to move them to improve the design? Does it tell you how
close to the edge you are? Does it do both in terms simple enough that you can
explain them to everyone you work with? Do you completely understand the
program, so that you know it is giving you good answers? And does everyone
you work with understand it too, so they believe the results? If you answered yes
to all of these questions, maybe you don’t need visible knowledge.
Objection 2: “This looks like a lot of work.”

Answer: You are right. It is much easier to guess at the solution. But guessing
just moves the work downstream, to fixing the problems that inevitably occur
when we don’t really understand. This is a case where quality is free once you
understand the real costs of poor quality.
Objection 3: “This will reduce our creativity and innovation by focusing on what
we already know.”
Answer: No, it will increase your innovation, by focusing it on moving the limits
rather than on repeatedly rediscovering the limits or moving around on the limit
surface. It will also increase your creativity by focusing your attention on cause
and effect, and what is most important to your customers.
Objection 4: “My problems are far too complex for this simplistic way of thinking.
We need powerful computer tools, such as finite element analysis, to deal with our
problems.”
Answer: Maybe. I’ll believe you when I see the trade-off curves you have com-
pleted, and you tell me that the rest of the problem is too complex. Until then,
I’ll continue to regard this answer as a result of poor fundamental understand-
ing, lack of skill in creating visibility, or a desire to avoid sharing basic knowl-
edge. I’ve heard this claim a lot, but I have never found a case where no useful
curve was possible once we applied enough creativity. Few phenomena are more
complex than the behavior of airfoils or of internal combustion engines, but the
engineers of the 1930s created a tremendous amount of useful knowledge about
both in the form of trade-off curves.
Objective 5: “I already have a lot of good curves done: I don’t need this.”
Answer: Maybe you are right. Here are ways to check whether you have the
right curves in the right format. Can a newly hired engineer use your curves to
design in the safe region and with a design close to optimal? Have you elimi-
nated failures to meet requirements in the field or in testing? Are managers
reviewing designs by looking to see where they fall on the trade-off curves?
If any answer is no, I’d suggest continuing.
Reference
1. Young, W. C. and R. G. Budynas. 2001. Roark’s Formulas for Stress and Strain, 7th
Edition. New York, NY: McGraw-Hill.
Chapter 2
How to Create Visible

Knowledge
As shown in Chapter 1, using visible knowledge can dramatically improve your

development process. But it is now time for the hard part: creating the knowl-
edge. Then, in Chapter 3, we’ll move to the larger issues of how to manage it
and how to change your organization.
A special note for managers: This chapter is built around a simple mechan-
ical engineering example, and it may be difficult if you don’t have mechanical
engineering skills. You can get by without really working through the exercises—
if you are going to let someone else teach your people how to create visible
knowledge. But, if you supervise engineers or product developers, you should
learn the methods and teach them yourself. Whether you use this example or use
one from your discipline as a basis is up to you. You don’t need to be an expert
at the particular technology involved—I am certainly not an expert in all the dif-
ferent fields of the engineers I teach. What you are learning and what you need
to instill in your organization is a thought process.
What you are likely to find when you try to teach, and, perhaps, when you
work through this chapter, is that many engineers can’t do engineering. When
managers stopped doing engineering after World War II, engineers also stopped
doing engineering. If you are old enough, you can remember when that hap-
pened. (After all, as the U.S. Army taught me, the “unit does well what the boss
checks.”) That’s the basic reason product development takes so long and pro-
duces such bad results. So, the most direct effect of creating visible knowledge is
that you will need to break bad habits, and your engineers will have to relearn
to engineer—and to get them to do it, you will probably have to as well. This is
hard work and if you are rusty, it may come slowly at first. But I assure you that
through practice it becomes easier and once engineers are back to engineering,
the good ones will appreciate the change and flourish.*
* If you need more help than this chapter provides, check with us at www.developlean.com for other
sources.
23
(If you are one of those engineers or managers who does know how to
engineer, my apologies—but you are probably too busy agreeing with me to
be mad.)
Choosing the Issues to Investigate

The first question you must ask yourself is, “What knowledge shall I make vis-
ible?” I suggest that you make a failure mode list: you may already have one,
in the form of Failure Modes and Effects Analysis (FMEA) sheets. However,
our approach to failure modes will be different than the normal for FMEAs.
FMEAs focus on the probability and effect of failures. We focus on understand-
ing the conditions under which the failures occur, so that we can design them out.
Besides FMEAs, other areas for inspiration for a failure modes list include war-
ranty and field quality issues, information from a House of Quality, test failures,
and anywhere that a lack of knowledge has or could cause delays in your devel-
opment process.
Once you have a list of issues, pick one to start on. For your first one, choose
one that you have a lot of knowledge about, that is not too complex, and is still
an important problem. Use it as an example as you work through the rest of the
chapter.
As you work through this exercise, you will probably find that your problem
statement changes as you progress. You may find that you need to create a curve
based on the trade-off between two different failure modes, for example. That is
okay—the failure modes list just gives you a starting place.
I’m going to lead you through a mental process that will enable you to cre-
ate visible knowledge even in difficult cases. To be most effective, you’ll need an
issue of your own to work on in parallel to the exercise. The exercise will work
best if you choose an initial issue that
◾◾ Is important enough to justify the effort

◾◾ Can be partially analyzed using equations
◾◾ Has associated historical data—from past experiments or field experience—
that you can draw on
How We’ll Approach the Problem

We’re going to follow a systematic step-by-step process, with iterations. As you
gain experience and intuition, you will start skipping around among the steps,
combining them, and adding steps of your own—that’s OK. For now, though, I
recommend following these steps as they are laid out. At each step, do the exer-
cise, and then execute the step on your own issue. The steps are illustrated in
Figure 2.1, which also provides a convenient way to lay out the knowledge on a
single page.
By: John Smith Contact: Ypsilanti, Michigan
Theme: Nail bending Mechanical Engineer coolmech@wsynthesis.com
Date: March 15, 2004
Issue statement: Characteristic curves:

• Nails bend when struck by hammer causing unsightly finish, lack of
structural integrity in joint, and rework.
System illustration:
Data source:
Jobsite physical testing
Worksite observation and records
Causal analysis:
Grip position
Strike Countermeasures:
+ angle Handle length
Training Nail gun
Nail selection
bending + Material Stiffer nails
– Roughened face
Nail Heat treat Pre-drilled holes
strength
Other fasteners
+ Diameter
–
Length
Figure 2.1 One-page trade-off curve sheet.

How to Create Visible Knowledge ◾ 25
You will want to use a single page so that the knowledge is—you guessed
it—visible. The page can be fairly large: Toyota usually uses A-3 paper; I use
11 × 17 inch paper. I highly recommend doing this on paper first to understand
the context before moving to a computer. When you move to a computer, feel
free to fill the entire screen.
Your goal on the single page is to visually tell a complete story. You don’t
want people to have to read through a lot of material to understand what is
going on: you want them to glance at the pictures and short phrases and under-
stand. One page should provide both sufficient context as well as detail.*
The format is not critical: You may wind up attaching multiple curves or inter-
val limits to a single drawing for example, or doing one causal analysis produc-
ing many curves. You may need several pictures to illustrate your point. Do not
fall into the trap of believing that filling out a lot of examples according to a set
format will enable you to make your knowledge visible: it is more likely to just
waste trees! A few well-thought-out examples are more useful than many cursory
examples created by filling out a template. Although the format is not critical, it
is important that all of the elements described below are present, and that they
convey a cohesive story.
The basic thought process—using all the tools to tell a complete story—is
important, even though you may jump around, iterate, rearrange, and be inno-
vative in displaying the knowledge. Experience shows that unless you use all
the tools shown, you are likely to miss things. And your trade-off curve sheet
needs to tell a complete story: everything needs to fit together. The way things fit
together enables you to see whether your logic is sound.
Work in pencil—you will want to change things as you go.
So, take out a piece of 11 × 17 inch or A3 paper so that you can work on your
problem in parallel with the one in this workbook. (If you don’t have any 11 × 17
or A3 paper, use two pieces of 8½ × 11 or A4 paper. Also, you will probably
need extra sheets to try things out on.)
Step 1: State the Issue

To fit your visible knowledge on one page, you have to be clear and concise by
identifying what is really important. (That is one reason for the “one-page rule”:
you don’t want people to have to spend a long time reading a textbook in order
to use the knowledge.) Conciseness and preciseness are important.
Therefore, you need a brief but understandable and accurate statement of the
issue you are addressing. Ask yourself, “What is the problem we are trying to
solve?”, or “What is the issue we want to understand better?” Here’s an example
to test your approach.
* If you are finding it difficult to capture the entire problem on one page, it may be that you need prac-
tice; but you may also want to consider whether the problem is too large and should be broken into
sub-problems. Sometimes an overarching problem statement that cascades additional sub problems is far
more effective.
Suppose your company designs and builds large pressure tanks. They have
long cylindrical bodies, with welded-on endcaps. You would like to reduce the
cost of the tanks by making the walls thinner, but experiments and field failures
have shown that the weld-joint between the caps and the bodies will tear open.
So, the statement on the failure modes list may be “endcap weld tears under
pressure.”
Here are some example issue statements. Mark them with an X if you think
they are bad issue statements, or a check mark if you think they are good.
◾◾ Cheaper pressure tanks.

◾◾ Weld problems.
◾◾ Tank pressure is limited by rupture at the endcap welds.
◾◾ Endcap welds fail because we don’t use laser welding.
Which issues statement did you think was best? Here are some thoughts:
Cheaper pressure tanks: Too general—there could be a lot of ways to make

cheaper tanks. Also, trying to optimize something makes a bad issue state-
ment. We are going to create trade-off or limit curves: we need to focus on
a conflict. Cheaper pressure tanks will be an outcome.
Weld problems: Okay, but what weld problems? Where? Why does it matter?
This statement is too general, more like a category label. It may be appro-
priate to organize problems identifying specific aspects related to welding
under a category heading, but, as an issue statement, it is probably too gen-
eral to be useful for creating visible knowledge.
Tank pressure is limited by rupture at the endcap welds: This one is
pretty good. It accurately and succinctly captures the basic issue, and it
identifies one of the basic conflicts we must address: the conflict between
containing pressure and maintaining product integrity.
Endcap welds fail because we don’t use laser welding: Watch out, this
issue statement assumes a solution. It might be appropriate to recommend
laser welding in a recommendation report, once you have data showing that
laser welding is better and is the cheapest countermeasure. Be careful with
implied solutions before the proper rigor of a study is complete. This is one
of the biggest pitfalls in transitioning from point-based to set-based devel-
opment since we have been conditioned to pick a path quickly. This issue
statement is too narrowly focused to be useful at this stage of investigation
and proposes a solution masquerading as an issue statement.
Have you noticed something? Issue statements in complete sentences are usually
better than simple titles. Thinking in complete sentences tends to make things
clearer.
Now write an issue statement for your own issue. Show it to someone else,
and ask them to explain it back to you. Did they understand the problem you are
trying to solve or the goal you are trying to achieve? Work hard at this: bad issue
statements are a leading cause of bad work. Take the time to establish clear and
concise understanding of the problem before starting to work on it.
A good way of creating an effective issue statement is to break the issue down
and define four key aspects: object, defect, extent, and impact.
In this example, we are most concerned with tank pressure, so the object of
the issue statement makes sense to be “tank pressure.” Now we can ask our-
selves, what’s wrong with tank pressure? What defect does tank pressure cause
or expose? We’ve previously identified our concern with weld tears, so perhaps
the defect is weld tears. When we consider the extent, we are not so much con-
cerned with the entire tank; we are focused on the endcaps. So, the extent of
our investigation is focused on the endcaps. Finally, what is the impact? Or said
in a different way, “Why do we care?” In this case, the impact is tank ruptures.
We care because we do not want the tanks to rupture, so our objective will be to
identify the optimal trade-offs to prevent rupture.
Thus, the four elements may look something like this:
◾◾ Object: tank pressure

◾◾ Defect: weld tear
◾◾ Extent: endcaps
◾◾ Impact: tank rupture
Rearranging the information into a sentence would result in an issue statement

something like, “Tank pressure is limited by rupture at the endcap welds.” This
is a clear and concise issue statement description we can agree to go work on to
understand. It clearly brings out a need to understand the relationship between
endcap welds and tank rupture pressure.
The issue statement does not have to be perfect to begin. As you get into the
analysis, you may discover new information and modify your issue statement.
However, the better the issue statement is when you start, the better your focus
and alignment with others will be. Put the right diligence into getting the issue
statement correct, but don’t let it paralyze you from doing the work. The more
practice you get, the easier it becomes.
Step 2: Draw a Picture

Draw a picture to clarify the issue for the reader and provide context for the
problem. You want the picture to help you figure out the causal relationships for
the issue: why the system behaves the way it does. Good pictures help you do
that. Bad pictures, no matter how pretty, don’t.
For the “Tank pressure is limited by rupture at the endcap welds” issue, which
of the pictures in Figure 2.2 does the most to clarify the issue? Why?
Discussion: All three pictures have some utility, particularly when viewed in
the order (b), (c), (a). But (b) is only useful for people who have never seen a
(a) (b)
Weld microstructure
(c) Point of rupture
Cylindrical shell
Endcap
Weld
Figure 2.2 Images of pressure tank. (Images courtesy of steelconstruction.info and

formfonts.com.)
tank, not for the intended audience. Image (a) may or may not be useful, once
we know whether the cause lies in the microstructure. Image (c) is the only one
that does a good job illustrating the problem by identifying the typical point of
rupture at the endcap weld.
Let’s put the issue statement and the picture on an 11 × 17 inch page, as
shown in Figure 2.3. We will also need a heading that names the issue, gives the
date of revision, and provides contact data of the person creating the trade-off
curve sheet for the readers.
(By the way, trade-off curve sheet is my name for these documents. Toyota
refers to them more generally as A3 reports and is often less formal about what
specific information goes on them than I’m being here. When you have 30
years of experience with them, you can be less formal, too. Toyota takes the
process one step further than we do here to compile the key learnings from
their A3 reports into an engineering design standard they translate as a “check-
sheet,” although I don’t like the translation to the word checksheet because
it sounds like checklist, and checklists usually serve a completely different
function.)
Now, draw a picture for your issue. Make sure your picture illustrates the
failure mode, clarifies the real issue, and orientates the reader. Do you find that
as soon as you have the picture, you want to go back and change your issue
statement?
Theme: Tank pressure and cap weld problem
Issue statement:
• Endcap weld tears under pressure!
• Tank pressure is limited by rupture at the endcap welds
Point of rupture
Cylindrical shell
Endcap
Weld
Causal analysis:
Figure 2.3 Pressure tank trade-off curve sheet, Steps 1 and 2. (Continued )
Step 3: Create a Causal Diagram

This is the most critical step. In my experience, most engineers generally
know what factors affect their issues, but they don’t know the relationship
between those factors. They don’t distinguish between the factors that they
can control—the resultant variables they want to control—and the intermediate
variables through which the control variables influence the resultant variables.
And they don’t understand the causal chain that organizes the intermediate

Mechanical Engineer coolmech@wsynthesis.com
Characteristic curves:
Data source:
Countermeasures:
Figure 2.3 (Continued ) Pressure tank trade-off curve sheet, Steps 1 and 2.
variables. They may create fishbone or Ishikawa diagrams that show all the
causal variables, but don’t show which variables are tightly coupled, nor which
are direct causes and effects.
Always bear in mind here that you want not only a visual representation of
the factors that cause the problem or the goal to be achieved, but also the rela-
tionships between them. Understanding the relationships allows breaking the
problem into pieces for which you can create curves. You want a final effect vari-
able, control variables you can directly influence, and the intermediate variables
that appear on the causal pathway between control variables and effect variables.
Once you understand these connections, selecting the relationships to graph will
be straightforward.
To build a causal diagram, we’ll follow the step-by-step subprocedures listed
below:
A. Write down on the left side of a piece of paper the effect variable we want
to influence.
B. Write down, just to the right, the variables that directly affect the result
variable.
C. Draw lines between variables to show the relationship of what affects what.
D. Mark the lines with a “+” if increasing the causal variable (the right-side
variable) has a good effect, and a “–” if increasing the causal variable has a
negative effect. If the variable is not quantitative, leave off the mark. If the
effect of increasing the variable is sometimes good and sometimes bad, use
a “+/–” symbol.
E. Repeat steps B, C, and D until we reach variables we can control.
Let’s practice for the issue “Tank pressure is limited by rupture at the endcap
welds,” and simultaneously work on your issue.
Substep A
Write down on the left side of a piece of paper the effect variable we
want to influence. Which of these is the result variable we want to influence?
Circle one:
Pressure
Material
Tank rupture
Weld type
If you circled “tank rupture” you are thinking along the same lines that I am.
Although not always the case, you may note that “tank rupture” was the “Impact”
we identified in creating our problem statement earlier. Write “tank rupture” on
the left side of a piece of paper. Then, on your other piece of paper, write the
result variable for your own issue.
Note: Sometimes when you are just starting out it can be useful to write the dif-
ferent blocks of the trade-off curve sheet down on a separate piece of paper and
then transfer them over to your A-3 or 11 × 17 sheet of paper as you build your
story. Doing this work as a team can also be very effective, particularly if you are
teaching this to others. In this case, do the work on a whiteboard or flipchart,
and then transfer it over.
Substep B
Write down, just to the right, the variables that directly affect the result
variable. Which of the following directly affects rupture? Circle all that apply:
Material strength in the weld

Tank diameter
Stress in the weld
Pressure
Weld type
(The stress in the weld is, roughly, the force per unit area being exerted on the
material in the weld.)
Did you circle “material strength in the weld” and “stress in the weld”? Do you
find that some judgment is required to decide what constitutes a “direct effect”?
There are potentially many useful causal diagrams for any given issue—and even
more that are misleading.
Why don’t we consider “pressure” a direct effect and add it at this point?
Because pressure causes rupture only by causing stress in the weld. If the
material thickness is great enough, or the tank small enough, or the tank is
underwater and pressurized from the outside, the weld can take a great deal of
pressure before it ruptures. We need to understand the direct causes so that we
can combine data from many different situations: all tanks will rupture at com-
parable stress-to-strength ratios, but their pressure-to-material-strength ratios may
be very different depending on the application or environmental context.
Write “strength” and “stress” to the right of “tank rupture” on our example dia-
gram. You should now have a picture that looks something like Figure 2.4.
Now, on your other sheet of paper, write the immediate causal variables for
your own issue. Don’t try to list every variable that might have an effect. Stick to
the important ones that directly affect the result variable. Our goal is to isolate
analyzable chunks, not to achieve a theoretical completeness. It takes some prac-
tice to identify those important and relevant variables versus all-encompassing
variables for completeness.
Strength
Tank
rupture
Stress
Figure 2.4 Start of causal diagram for pressure tank rupture.

Substep C
Draw arrows between variables to show directionally what affects what.
Go ahead and do this on your diagram for the propane tank issue.
You should now have a picture something like Figure 2.5.
Now draw the causal arrows for your issue on your diagram. You may find
that causal variables can affect each other as well as the result variable. We can
even have closed circles of causality. This is very different than a fishbone or
Ishikawa diagram.
Substep D
Mark the lines with a plus or minus to show whether the relationship to
the resultant variable is positively or negatively influenced by the causal
variable. Mark with a “+” the arrow for which increasing the causing variable
improves the affected variable. Mark with a “–” the arrow for which increasing
the causing variable makes things worse.
Did you produce a result like the one in Figure 2.6?
Now mark the positive and negative influences on your own diagram. Bear in
mind you may not know exactly and may need to investigate.
Strength
Tank
rupture
Stress
Figure 2.5 Strength and stress as causes for tank rupture.
Strength
+
Tank
rupture
Stress
Figure 2.6 Direction of relationship between causes and effect.

Substep E
Let’s repeat substeps B, C, and D for the stress variable. Circle the variables that
directly affect the stress:
Pressure
Tank diameter
Material
Residual stress from welding
Weld type
Tank wall thickness
Stress concentrations
Weld oxidation
Did you circle pressure, tank diameter, residual stress from welding, tank wall
thickness, and stress concentrations? Write them on your diagram, with arrows
and pluses or minuses like before. You should wind up with a picture that looks
something like Figure 2.7.
Applying sub-steps B, C, and D again, this time to the strength variable, we
get a picture that looks like Figure 2.8.
Why are there no plus or minus signs near material and heat treatment? Write
down your answer in the space below. (answer below)
Strength
+
Tank
rupture
Pressure
–
–
–
Stress Tank diameter
+
Wall thickness
–
– Residual stress
Figure 2.7 Expanded casual diagram for pressure tank rupture.

Material
Strength
+ Heat treatment
Tank
rupture Pressure
–
– –
+
Wall thickness
–
– Residual stress
Figure 2.8 Further expanded casual diagram for pressure tank rupture.
Answer: These are not quantitative variables. We select a type of material, but can’t
increase the material, for example. Plus or minus signs would have no meaning.
Now expand the diagram for your own problem with the important variables
that directly affect one or more of your intermediate variables. Add the relation-
ship arrows with “+” and “–” symbols as appropriate.
Now, returning to our pressure tank example: on the causal diagram, circle
the variables that are directly controllable. You should wind up with a picture like
Figure 2.9.
Material type is something we can control because we can specify what mate-
rial to use. However, the heat treatment state of the welded material cannot be
Material
Strength
+ Heat treatment
Tank
rupture
–
–
Stress – Tank diameter
+
Wall thickness
–
–
Residual stress
Figure 2.9 Directly controllable factors affecting pressure tank rupture.

directly controlled—it is a result of the type of welding performed and the weld
parameters. Similarly, residual stress and stress concentrations are a result of the
welding process, not directly controllable in the same way that tank diameter and
wall thickness are controlled.
Now return to your issue and circle any variables on your diagram that are
directly controllable.
Carrying our pressure tank diagram a step further (once again repeating
substeps B, C, and D for noncircled causes), we can create a picture like the one
displayed in Figure 2.10.
Now we have a real problem. The weld process parameters and the cleaning
process are quite complex: they are really stand-ins for many included variables.
We will certainly not be able to determine the effects of all those variables ana-
lytically, and it is very unlikely that we will have enough historical data to be
able to sort out their effects from experience. So, what do we do?
Answer: Let’s assume for the moment that the weld process parameters and the
cleaning process parameters have been more or less optimized, and focus our atten-
tion on the type of weld and the cleaning processes. Figuring out how to optimize
the weld and cleaning process parameters will be another project. We have enough
of an analyzable chunk to develop visible knowledge around, so we will stop devel-
oping our causal diagram here for now. If you have been working on a separate
sheet, let’s put this diagram on our trade-off curve sheet now (see Figure 2.11).
Now, finish the causal diagram for your issue, repeating substeps B, C, and
D until you have an analyzable chunk. Once sufficiently complete, analyze your
causal diagram. Have you included enough variables? Too many? Is it well orga-
nized and clear? Redraw as needed. Do you find that you need to go back and
redo your issue statement or your illustration? If so, that’s fine. It just shows that
your understanding of the issue is growing deeper and more complete.
Material
Strength
+ Heat treatment
Weld
Tank process
rupture type
Pressure
–
–
– Weld
process
+ parameters
Wall thickness
–
Cleaning
– Residual stress process
Figure 2.10 Causal diagram with build process factors.

Issue statement:
Point of rupture
Cylindrical shell
Endcap
Weld
Causal analysis: Material

Strength
+ Heat treatment
Weld
Tank
process
rupture Pressure
– type
–
Stress – Tank diameter Weld
+ process
parameters
Wall thickness
–
– Residual stress Cleaning
process
Figure 2.11 Pressure tank trade-off curve sheet, Step 3. (Continued )
Step 4: Finding Data and Creating Curves

Now the real fun starts. We have an analyzable chunk, but it is still too complex
to show all the variables easily in a single diagram. We will need to look for
appropriate combinations of variables that will give meaningful, compact, and
effective curves.
We will often sketch a simple curve from intuition, trying to get a sense of
whether we understand the causal relationships. Then we will look for data and
return to curve manipulation.

Data source:
Countermeasures:
Figure 2.11 (Continued ) Pressure tank trade-off curve sheet, Step 3.
We can get data in several ways:
1. Analytical equations: Derived or from textbooks

2. Historical experience: The results we already have (or may need to get)
3. Simulation
4. Physical testing
The methods above are listed in rough order of increasing cost, and decreas-
ing reliability and insight production. We should usually exhaust the potential of
each of these before going on to the next. Far too many engineers jump imme-
diately to finite element simulation or physical testing before learning what they
can from analysis and historical data.
Let’s start with the first source of data: analytical equations. Again, we’ll pro-
ceed in several substeps:
A. Identify clusters of variables that we can handle analytically.

B. Put hypotheses about the cluster into visible form.
C. Find equations of each cluster.
D. Combine the equations into a compact and meaningful generalized
parameter.
We can then use that generalized parameter to make sense out of historical data,
simulation, or physical test data.
Substep A
Identify clusters of variables whose relationship we can handle analytically.
Look at the propane tank causal diagram (reprinted in Figure 2.12) and circle a
cluster of variables for which you think you will be able to find equations.
Did you circle the same ones I did in Figure 2.13?
Now, circle a cluster of variables on your own diagram that you think you can
handle with equations.
Substep B
Put hypotheses about the cluster into visible form. For example, my hypoth-
esis is that increasing pressure will lead to increasing stress, and that the relation-
ship will be linear. I’ve sketched my hypothesized relationship in Figure 2.14.
Now, try your hand at sketching the relationship between stress and wall thickness.
Material
Strength
+ Heat treatment
Weld
Tank
process
rupture Pressure
– type
– – Weld
process
+ parameters
Wall thickness
–
Cleaning
Figure 2.12 Causal diagram for pressure tank rupture.

Material
Strength
+ Heat treatment
Weld
Tank process
rupture Pressure type
–
– – Weld
process
+ parameters
Wall thickness
–
Cleaning
Figure 2.13 Cluster of variables as candidates for trade-off curve development.

Stress
Pressure
Figure 2.14 Hypothesized relationship between stress and pressure.

Stress
Wall thickness
Figure 2.15 Hypothesized relationship between stress and wall thickness.
Did you produce a sketch something like the graph shown in Figure 2.15?
Stress and wall thickness have a hyperbolic relationship. We can guess this
by noting intuitively that stress will increase as wall thickness decreases, going
to infinity as the wall thickness goes to zero. Also, stress will decrease as wall
Stress
1
Wall thickness
Figure 2.16 Hypothesized relationship between stress and the inverse of wall thickness.
thickness increases, but it will never reach zero. Hyperbolic relationships mean
there is a linear relationship between one variable and the inverse of another as
depicted in Figure 2.16.
Sketching these hypotheses will develop and hone our intuitions, thus,
◾◾ Improving our ability to analyze the data once we start gathering it.
◾◾ Helping us figure out what data to collect.
◾◾ Possibly enabling us to make some design improvements without any data
at all.
◾◾ Giving us a check on our results. If our intuitions conflict with the equa-
tion or data once we get them, we know we had better double-check. If we
find that our intuitions do indeed conflict with equations or data, we have
gained tremendous understanding.
Now sketch a relationship between stress and cylinder diameter.

Did you sketch a linear relationship, or do you think that the stress increases
with the square of the diameter—a quadratic relationship? (See Figure 2.17.)
To go further, we will need to develop equations. Before we do, though,
sketch some hypotheses about your issue.
Substep C
Find equations for each cluster. We might be able to look these e quations
up, but wherever possible I prefer to derive them. Remember, our goal is
understanding—and we get a lot more understanding if we derive the equations
ourselves. Obviously, this little book is not going to teach you everything you
might ever need to know to derive the equations you might need—but following
along may remind you of the basic process.
To find the equations for the stress in the tank, we need to know the follow-
ing about the hydrostatics of gases: if we make an imaginary slice through a
pressure vessel, the force exerted by gas is equal to the pressure times the area
Linear Quadratic
Stress
Stress
Cylinder diameter Cylinder diameter
Figure 2.17 Potential relationship between stress and cylinder diameter.
of the slice. (This assumes that the pressure is large enough and the tank small
enough that we don’t need to worry about the change of pressure from top to
bottom because of gravity. Remember that concept of simplifying approxima-
tions?) Our imaginary slices and conceptual understanding of forces and pressure
give us the pictures and equations shown in Figure 2.18.
At any point along the weld, we need to take into account both the longitu-
dinal stress from the gas trying to pop the endcaps off, and the circumferential
stress from the gas trying to push the top and bottom, or sides of the tank apart.
(There is also a radial stress from the direct pressure of the gas and equal to the
actual pressure of the gas, but it is too small to worry about.)
Slice 1
Slice 1 Endcap cross-
sectional area
Slice 2 F = PA
D
2
A1 = π D
4
F = PA
Slice 2
Body cross-sectional area
D
L D2 +
A2 = π LD
4
Figure 2.18 Tank pressure equations.

Issue statement:
System illustration: Point of rupture
Cylindrical shell
F = PA
Endcap
Weld
F = PA
Causal analysis:
Material
Strength
+ Heat treatment
Weld
Tank process
rupture type
Pressure
–
–
Stress – Weld
Tank diameter
process
+ parameters
Wall thickness
_
_ Cleaning
Residual stress
process
Figure 2.19 Pressure tank trade-off curve sheet, Step 3b. (Continued )
Remember free body diagrams? Pictures like those in Figure 2.18, with a solid
object sliced apart to allow us to identify the stresses on the body, are a power-
ful method for making mechanical and civil engineering knowledge visible. We
should use them in our illustrations step whenever we are dealing with forces.
We’ll add this illustration to our trade-off curve sheet as shown in Figure 2.19.

Data source:
Countermeasures:
Figure 2.19 (Continued ) Pressure tank trade-off curve sheet, Step 3b.
Now, what can we learn from the free body diagrams? Let’s start with the
longitudinal stress. The force from the gas on the endcap, FL, is just the internal
pressure of the gas in the tank, P, times the area of the endcap, or
D2
FL = P π (2.1)
4
where D is the diameter of the tank. Newton’s law of equal and opposite reac-
tions says that this force must be balanced by the longitudinal stress in the mate-
rial that holds the endcap on the tank multiplied by the area of that material. As
shown in Figure 2.20, the area is the product of the tank diameter (D), the tank
wall thickness (t), and pi.
So, solving for the longitudinal stress, σ L, we get
FL
σL = (2.2)
πDt
And substituting for force from Equation 2.1
DP
σL = (2.3)
4t
we arrive at an expression for stress in terms of our manageable cluster of vari-
ables. (Good news—there are software programs that will do the algebra, elimi-
nating one source of errors.)
So far, so good, but now we come to the circumferential force, and we have
a problem. We knew that the longitudinal stress would be the same everywhere
along “slice 1” (see Figure 2.18) because the geometry of slice 1 is completely
symmetrical. But slice 2 has a long cylindrical central section and two endcap
sections, and there is no obvious reason to believe that the stresses will be the
same for both (see Figure 2.21).
Let’s consider a very small section of the cylinder, of length dl. If we consider
a section far from the endcaps, we can assume that the section takes its own
load (i.e., that the endcaps won’t affect the section). Then we have the picture
FL = σLπDt
D
Figure 2.20 Cross section of thin-walled cylinder.

Uniform stress distribution:

Stress is the same everywhere due
to symmetry
Variable stress distribution:

Stress varies along length of tank
due to asymmetry
Figure 2.21 Two different tank cross sections.

dl
Figure 2.22 Finite element analysis of cylinder wall.
shown in Figure 2.22, with an elemental force, f, caused by the gas pressure act-
ing over the rectangle defined by the tank diameter, D, and dl.
f = PD (dl ) (2.4)
An equal counter-balancing force is produced by the circumferential stress acting

over the two small rectangles defined by dl and tank wall thickness, t.
f = 2σ C t (dl ) (2.5)
Setting Equation 2.4 equal to Equation 2.5 and rearranging terms, we arrive at an
expression for circumferential stress, σ C:
DP
σC = (2.6)
2t
From this equation we recognize that the circumferential stress near the middle
of the cylinder is about twice the longitudinal stress we calculated earlier (com-
pare to Equation 2.3).
Now, if we imagine the center cylinder reduced to nothing so that
the endcaps form a ball, there would be no difference between the
circumferential stress and the longitudinal stress we found earlier. At the

ends of the tank the circumferential and longitudinal stresses must be
equal. But very close to the cylindrical portion, where the weld is, a section
through the ball end is very close to being a section through a cylinder. So,
we will be both conservative and close to accurate if we assume that at the
weld the circumferential stress is the same as the circumferential stress at
the middle of the tank.
Substep D
Combine the equations into a compact and meaningful generalized
parameter. As a first step, we can try just adding the stresses up. If we ignore
residual stresses, stress concentrations, etc., and apply a constant distortion
energy failure theory out of a textbook,* the rupture will occur when
2S 2 = σ C2 + σ 2L + (σ L − σ C ) (2.7)
2

where S is the effective strength of the material.

Combining Equations 2.3 and 2.6 into 2.7 and simplifying, we have
3 DP
S= (2.8)
4t
at the failure limit.

We can reorganize these into a relationship between dimensionless numbers
to get something a little more interesting:
t 3  P
= (2.9)
D 4 S
where, as before
t is the wall thickness

D is the tank internal diameter
P is the pressure inside the tank
S is the effective strength of the material
We can graph this relationship as shown in Figure 2.23.
* See: Engineers Edge. 2017. Von Mises criterion (maximum distortion energy criterion). http://www
.engineersedge.com/material_science/von_mises.htm (accessed 22 August 2017).
0.03
0.02
t/D
0.01
0
0 0.01 0.02 0.03 0.04 0.05 0.06
P/S
Figure 2.23 Graph of the wall thickness (t) to tank diameter (D) ratio against the pressure
(P) to material strength (S) ratio.
This tells us a great deal about designing tanks. Circle the true statements
from the five below:
1. As we increase the diameter, for constant material and gas pressure, the
required wall thickness increases in direct proportion.
2. As we keep the thickness/diameter ratio constant and look only at pressure
and strength, we can increase pressure in direct proportion to the strength
of the material.
3. The ratio (t/D) : (P/S) is constant. Thus, for any of the four variables that we
might want to use in another relationship, we can substitute a simple combi-
nation of the other three.
4. We now have a basis for comparing historical data on the rupture pressure
of different-size tanks made of different materials and welding techniques.
5. Elvis is alive and living in Nome, Alaska. (Just making sure you were paying
attention.)
Only one of the above statements is false (and I meet people who argue about
that one, even though we all know that Elvis is living in Tahiti). The most inter-
esting statement is number 4: going as far as we can with equations gives us the
ability to do much better things with historical, simulation, and test data.
By the way, which did you find easier to understand: the curve or the equa-
tions that led to it?
Also, do you see anything interesting about the units (length, force, etc.)
used in the two ratios, t/D and P/S? The units cancel each other out resulting in
dimensionless ratios. This is common for good combinations of variables.
Now, find and plot interesting combinations of variables for your own issue. In
particular, look for dimensionless variables.
Do you find it hard? Is your algebra and basic engineering, marketing, or
chemical knowledge a little rusty? Have you had a lot more practice using
rules of thumb that have evolved at your company, or perhaps plugging num-
bers into equations defined by others, rather than thinking about fundamental
relationships?
If so, you are not alone. A modern engineering education generally does a
very good job of teaching engineers to think. However, the way engineering is
managed in many Western companies often does not draw on the true capabili-
ties that engineers studied or create the linkage between development and cus-
tomers’ desires. This stuff is hard—particularly if you have been out of this for a
while. It can hurt anyone’s head. It is much easier to fall back on heuristic rules
of thumb, but stick to it.
Did you get any insights you didn’t have before?
If you didn’t, maybe you aren’t trying hard enough. Please go back and think
some more.
Returning to the pressure tank example, what we have plotted is not the exact
rupture point of the material, because we have not taken into account the other
causal factors, such as stress concentrations resulting from contamination in the
weld, the weld shape, and residual stress from the cooling deformation of the
hot weld material (see Figure 2.24). What we have done so far is develop a basic
understanding of the characteristics of the system.
Now, let’s suppose we have some historical data, based on previous
experiments with our own tanks and some tests on small tanks purchased
from competitors (see Table 2.1).
Table 2.1 Hypothetical Historical Tank Rupture Data

Material
Rupture Tensile Rupture
Diameter Thickness Pressure Weld Strength Stress
No. (m) (mm) (Kpa) Techniquea Material (Mpa) (Mpa)
1 2.0 4.0 600 SMA Mild steel 180 130

2 1.5 3.2 680 SMA Mild steel 200 138
3 1.8 3.0 540 SMA HSLAb 280 136
4 2.2 3.0 380 MIG Mild steel 200 121
7 2.0 3.7 564 MIG Mild steel 210 132
5 3.0 5.0 720 MIG HSLA 280 187
6 1.5 1.4 600 MIG HSLA 320 278
a SMA = shielded metal arc (stick); MIG = metal inert gas
b HSLA = high-strength, low-alloy
Material
Strength Heat treatment

+
Weld
Tank process
rupture type
Pressure
–
–
Stress – Weld
Tank diameter process
+ parameters
Wall thickness
_
_
Cleaning
Residual stress process
Figure 2.24 Other causal factors affecting tank rupture.
We can use our previous analysis to plot some meaningful parameters:

The nominal rupture stress, based on the actual pressure, wall thickness, and
diameter
-against-
The tensile strength of the material in its preweld state of heat treatment, as
measured on a tensile stress machine.
This is shown in Figure 2.25 for two types of welding, metal inert gas (MIG) and
shielded metal arc (SMA).
Notice that we aren’t plotting the rupture stress, because we don’t know it:
the rupture stress is affected by weld shape, stress concentration, and so on. The
nominal stress is what we control during the design. And we aren’t plotting the
material strength, because we don’t know that either: it will have been changed
by the welding process. Instead, we are plotting what we can control in the
design: the nominal or test material strength.
What conclusions can we draw? Circle the correct statements from among the
four below.
1. All conclusions should be tentative, because we do not have a lot of data

and something could be distorting the results.
2. MIG welding is better than SMA welding.
3. Both welding methods result in a significantly lower rupture strength than
the basic strength of the material.
4. MIG welding has no advantage over SMA welding at low material strengths,
but a rapidly increasing advantage at high material strengths.
300
250
Nominal rupture strength (Mpa)
MIG
200
150
SMA
100
100 150 200 250 300 350
Material tensile strength (Mpa)
Figure 2.25 Rupture point versus material strength for two types of welds.
Discussion: Statement 2 is not technically correct: MIG welding is better for

high-strength alloys, but has no advantage for simple mild steel. The other state-
ments are true.
To summarize, we have used our analytical equations to derive a useful
parameter, the nominal rupture stress. The nominal rupture stress enables us to
compare rupture in tanks of different sizes and designs. We have plotted that
stress against the theoretical strength of the preweld material (tensile strength).
The plot shown in Figure 2.25, then, is a measure of the degree to which the
welding process degrades the basic strength of the material. We used the plot
to draw conclusions about the effectiveness of different welding processes in
our application. Along the way, we have also created a concise causal graph
that gives us a wealth of information about the relationship between our param-
eter and design variables, and some useful illustrations. In short, we have cre-
ated visible knowledge. Let’s transfer this onto our trade-off sheet, as shown in
Figure 2.26.
Now, do this for your own issue. Improve your curves to take advantage of
historically available data. In the very least, check your analytical results against
historical evidence.
Can you combine the analytical result with historical data to produce insights
and useful limit information?
I hope that by this time you have some pretty interesting visible knowledge of
your own. You’ve clearly stated a problem, drawn illustrations that communicate
the core issue, developed some basic equations, and used the equations to develop
meaningful curves based on real data. If not, please go back and think some more.
Finally, if your work is spread out over many documents, and you have not
done so already, put your work on a single 11 × 17 or A3 sheet of paper. Simplify
as required. The specific format isn’t critical, provided other people can visually
follow the thought process. However, having a clear and uniform format has some
advantages. Particularly early on, a standard format helps people work through
the thought process in a clear and consistent manner that reinforces the learning
and thinking process. As visible knowledge becomes more ingrained, having a
common format makes it easier to read and understand these documents as infor-
mation and the story flow is consistent across the various documents. Certainly
having all of your work on one page makes it easy for other people (and you)
to “follow the story” and see if it makes sense, but having consistency makes it
easier to pick up a document and understand it quickly. Having said that, don’t be
afraid to modify the template to suit the particular needs of the problem you are
trying to solve. It’s more important to tell a story that makes logical sense and has
all of the critical pieces than it is to fill in a template. If you would like a template
to use as a starting point, you can download one at www.DevelopLean.com.
Does this all make sense? Are you satisfied that you’ve created a useful nugget
of knowledge? Do you need to go back and correct some things? Do you need
to fill in some missing information with testing? Does this exercise incentivize
you to want to learn more? Does this feel daunting when you consider all the
knowledge you have neglected? Consider the competitive advantage this method
creates.
Some of your knowledge may be best expressed as one-dimensional curves—
simple limits applied to parameters on a drawing. You can put a lot of these on a
page, for example, put a drawing in the center, label the dimensions with letters,
and create a table that shows minima and maxima. But be careful: simple limits
can lead to trouble, because they leave out the interactions.
Step 5: Countermeasures
We have only one step to go. Limit curves are highly useful, but what if you can’t
live with the limits? That’s where countermeasures come in: things you can do
when you need to go past the limits.
Countermeasures should tell us things that are not visible from the limit
curve—ways to bypass the curve or make it irrelevant.
Issue statement:
Cylindrical shell
F = PA
Endcap
Weld
F = PA
Causal analysis:
Material
Strength
Heat treatment
+
Weld
Tank process
repture type
Pressure
–
–
– Weld
process
+ parameters
_ Wall thickness
_
Cleaning
Residual stress
process
Which of these are good examples of countermeasures for the weld rupture
problem? (Circle them.)
1. Shot peen the weld to change the stress state.

2. Use MIG welding for high-strength, low-alloy steels.
3. Braze or bond in place a reinforcing ring.

Stress
Stress
Wall thickness 1/Wall thickness
300
Linear
250
MIG
200
Stress
150
SMA
100
Cylinder diameter 100 150 200 250 300 350
Data source:
Historical tank rupture data; stress from engineering analysis
Counter measures:
Discussion: 1 and 3 are good examples. 2 simply restates in words what is

depicted in the trade-off curve shown in Figure 2.25; I’d leave it out. Notice how
different this is from the usual design standards.
Let’s put these countermeasures on our trade-off curve sheet as shown in
Figure 2.27. Are we done?
Issue statement:
Cylindrical shell
F = PA
Endcap
Weld
F = PA
Causal analysis:
Material
Strength
Heat treatment
+
Weld
Tank
process
rupture
Pressure type
–
–
Stress – Weld
Tank diameter
process
+ parameters
_ Wall thickness
_
Cleaning
Residual stress process
Now, create countermeasures for your own issue. What can you really do
to move the limits, not just move them around in the identified feasible space?
How do you prevent the worst condition of moving out into the infeasible
space without countermeasures? This thinking is a powerful tool for spurring
creativity and innovation by focusing on how to shift curves and move into

Stress
Stress
Wall thickness 1/wall thickness
300
250
MIG
Stress
200
150
SMA
100
Cylinder diameter 100 150 200 250 300 350
Data sources:
Historical tank rupture data; stress curves from engineering analysis
Countermeasures:
(1) Shot peen the weld to change the stress rate.
(2) Braze or glue in place a reinforcing ring.
the space that is now infeasible in a direction that is advantageous to your

customers.
Ask yourself again, does it all make sense? Are you satisfied that you’ve cre-
ated a useful nugget of knowledge? Do you need to go back and correct some
things?
Chapter 3
Visible Knowledge
and Companies
This chapter addresses the questions: How should visible knowledge be orga-
nized? How should it change your managers? Your development process? Your
research organization? Your test organization? Your supplier relationships? Each
of these questions could be answered at book length, but I hope that the brief,
introductory answers that follow will be of some use.
Organizing Your Knowledge

The issue of knowledge management is a common challenge in organiza-
tions. As an organization shifts toward a conscientious focus to create and
reuse knowledge, the need to organize that knowledge so that it can effectively
be used when needed is heightened. Adding to the challenge is that while
knowledge may be distinct from the people who create it, it is impossible to
completely separate the two. Many companies rely almost exclusively on the
knowledge that is in the heads of their people, and miss out on the opportunity
to build and share knowledge at an exponential rate. There are several prin-
ciples to consider related to creating and organizing your knowledge that we’ll
discuss here.
1. Organize departments, as far as possible, around knowledge of the opera-

tional value stream—the suppliers, manufacturing system, product, and
customers.
2. Expect everyone to create visible knowledge—the departmental manage-
ment focuses primarily on creating reusable knowledge.
3. Hold everyone responsible for delivering and sharing the knowledge they
have, and getting the knowledge they need.
59
Let’s look at these in more detail.
1. Organize departments, as far as possible, around knowledge

of the operational value stream—the suppliers, manufacturing
system, product, and customers. You want your development orga-
nization to be structured around the subsystems of your product and
manufacturing system. Focus the organization on a knowledge flow that
enhances the ability to connect your design efforts with your customers
and manufacturing systems. Then, each section will be responsible for
creating and continuously improving the trade-off curves associated with
their subsystems.
For example, Toyota has three vehicle development centers, each dedi-
cated to a group of product families. Each development center has its own
body engineering, interior, chassis engineering, powertrain engineering, and
test departments. The powertrain department specializes in the powertrain
for a specific vehicle: an advanced development center does basic pow-
ertrain development. The manufacturing engineering division (separate from
the vehicle development centers) is similarly broken down by manufacturing
process, then by components.
Toyota makes little use of organization by tool or discipline: for example,
there is no separate drafting organization. Some tools may be so complex
that you must specialize and have to organize around them: for example,
you may need finite element analysis departments because it is simply not
possible for people to remain expert at using the finite element programs
unless they do it every day. Be careful, though: if you have a centralized
finite element organization, you can be sure that your finite element soft-
ware will grow steadily more complex. If such an organization is necessary,
you should probably associate each finite element analyst with one of the
sections associated with a product subsystem.
Note, however, that the test organization is relatively independent. Part of
the role of a test department is to keep the design engineers honest.
Organizing departments around the operational value stream enhances
your ability to systematically build knowledge in areas that add value to
the customer. Customers don’t care that your finite element methods are
sophisticated, but they will notice when your product is more robust, reli-
able, and higher performing than your competitors. So creating a stamping
group that builds visible knowledge about what materials and geometries
are within the limits of the manufacturing technology adds value to the
customer through better-quality products, and adds value to the company
through opportunity for higher margins due to lower costs and better
value to customers.
2. Expect everyone to create visible knowledge—the department
management focuses primarily on creating reusable knowledge.
Each department at Toyota creates a body of visible knowledge, with
Visible Knowledge and Companies ◾ 61
responsibility assigned down to sections of a manageable size.* For example,

one section might be responsible for all the door mechanical systems for a
class of vehicle, and would maintain all the associated visible knowledge,
while another section would be responsible for the door inner panels for
that class of vehicle. If these two sections were combined at Toyota, the size
of the group (not to mention the span of technologies involved) would be
too large for a section leader to effectively coach in knowledge creation and
manage the knowledge generated.
Knowledge is maintained at the section level so that it can be approved by
the section leader, shared across the members of the section, and used to train
new members of the section. However, each individual is responsible for
◾◾ Mastering the knowledge maintained by the section and relevant knowl-

edge maintained by other sections
◾◾ Adding to and improving the knowledge as new data arrives
Since the people doing the work are maintaining the knowledge, their
skills continually increase, and the knowledge never goes out of date. So
don’t create a knowledge management organization separate from the peo-
ple who actually do the work. Knowledge management organizations never
manage to remain current: they may do a good job for a short time, but
their efforts will soon be obsolete.
(In general, avoid creating organizations of gun-bearers, drum beaters,
and trackers—people whose job it is to help the design engineers or to
make sure they are following procedures. They will always start getting in
the way and create extra work to keep themselves relevant.)
Of course, it is hard to get engineers to take the time to create visible
knowledge: they want to get the project done. That is why Toyota’s depart-
mental managers focus primarily on visible knowledge. Project progress is
primarily the responsibility of a project leadership team that has no direct
authority over the engineers. Departmental managers are thus in a position
to say, “I understand you want to use this great new idea, but where is the
visible knowledge that proves that it will work?”
3. Hold everyone responsible for delivering and sharing the knowledge
they have, and getting the knowledge they need. Hold every developer
responsible for sharing their knowledge with every contact who needs it.
For example, at Toyota each manufacturing engineer provides limit data to
product engineers and stylists as required to ensure they can design manu-
facturable parts. This assigns a much more vigorous meaning to “concurrent
engineering” than the mere review of product designs by manufacturing
engineers.
* In Toyota’s context, a manageable size is about five direct reports per engineering manager in order to
properly develop technical personnel and build knowledge within their section.
Hold developers equally responsible for going after the knowledge they
need. Ignorance is no excuse; a product engineer who designs a part that is
difficult to manufacture has clearly failed to dig out the required knowledge.
Don’t let the form of how to transmit knowledge stand in the way. Some
organizations fail to move forward with creating knowledge because they
get tied around the axle with questions of databases or document manage-
ment software or integration with engineering software tools. Start with
paper and three-ring binders if necessary (Toyota did this for decades). The
important thing is to get started and not let the technical demands of your
knowledge management solution get in the way of the principle of individ-
ual responsibility.
Changing Management Roles and Skills

I often ask American engineering managers in large manufacturing companies
how much of their time is spent directly improving products and processes. Or
sometimes I just ask them how much of their time is spent doing technical work,
or how much time they spend creating or transmitting useful knowledge. Any
way I ask the question, the answer is the same: an average of about 5%.
Conversely, when I ask these questions of Toyota managers, even the
Americans working for Toyota in the United States, the answers are about 80%.
There is a similar difference in the engineering skill of the managers. Toyota’s
managers are extraordinarily technically competent: they consider themselves
super engineers. Most American managers report that their engineering skills are
disappearing.
This was not always so. Before World War II, American business leaders
such as Edison, Ford, Westinghouse, the Dodge brothers, John Deere, Cyrus
McCormick (inventor of the mechanical reaper), and Alfred P. Sloan (the long-
time president of General Motors) were renowned for their technical expertise.
(My own grandfather, inventor of a tag-making machine and an executive at
the American Tag Company, was a minor example.) Surely it is no accident that
America then led the world in manufacturing.
At that time, Americans were contemptuous of the preoccupation some
societies had with clothing, social connections, school associations, and public-
speaking skills: their preoccupation with presentation as opposed to perfor-
mance. Now, it seems in many cases that the single most important influence
on an American engineer’s promotability is likely to be his or her presentations.
A handful of software companies founded by technical people continue the old
traditions, giving new hires serious technical tests and focusing management on
the product—sadly, many established companies have given up the fight.
Of course, many managers believe that they are too busy doing “management”
to pay any attention to technical work, when the opposite is true. Because
they have little ability to directly improve the operational value streams that flow
from suppliers through manufacturing plants to customers, they spend their time
creating management work for each other. Most of this work detracts from cor-
porate success.
Management philosophy in most companies is dominated by a single fact:
most managers have no direct way to influence the factors that control the suc-
cess of the company. Manufacturing companies make money by building and
selling products. But few managers really understand customer needs, product
physics, or manufacturing processes.
Since they cannot directly contribute to value-producing activities, manag-
ers resort to an endless stream of programs of the month, management by
best-seller, and PowerPoint presentations. They may hate it—but they have no
other handles with which to try to influence the organization. In the meantime,
knowledge-based companies like Toyota—whose managers do understand the
customer, products, and manufacturing equipment—continue to gain market
share.
It is past time for a counterrevolution. As is so often the case in management
history, the military has led the way. Defeat in Vietnam led to a new generation
of hands-on, set-the-example leaders. Visible knowledge is an important part of
that counterrevolution for industry, liberating managers to pay attention to cus-
tomers, products, and manufacturing systems.
Leaders need to use visible knowledge to do two things: make sure their
people are creating visible knowledge and conduct effective design reviews.
Doing these two things well will accomplish many management activities as an
automatic side benefit. Let’s look at this in more detail.
Making Sure Your People Create Visible Knowledge

Engineers will create visible knowledge if they perceive that their bosses think it
is important (that is, they check it). You can’t get them to create it by establishing
a template, or requiring a certain number of sheets to be created each month, or
forming a committee, or running a big program. You have to master the thought
process, teach them the thought process, and then look at their work to make
sure they are using the thought process. That is why having small departments is
important.
This does not necessarily require you to be a technical expert, although
expertise helps. A good trade-off curves sheet is clear enough to be understood
by a nonexpert. So, keep asking questions and demanding improvements to
the sheets until you understand them. This will rapidly improve your technical
expertise. It will also rapidly improve the technical expertise of your subordi-
nates: the quickest way to make someone learn something is to force them to
teach it to you.
Conducting Effective Design Reviews

Many companies have separated project reviews, conducted by management
and intended to ensure that the project is on schedule, from design reviews
conducted by technical experts (often the peers of those being reviewed) and
intended to ensure technical quality. This is absurd: if the technical quality is
present in the form appropriate for that point in the project, the project is on
schedule; if not, it isn’t.
So management needs to conduct technical design reviews, with the help of
other technical experts as needed. At Toyota, the general managers three lev-
els up (section leader reports to a manager who reports to a general manager)
review every drawing three times. In one case, a general manager reviewing a
part from another department made 211 suggestions.
Why would a general manager have so many suggestions for a technical
drawing? His focus is not to ensure that all the dimensions have been included,
though that may be a side benefit. If there is data missing, the customer for the
drawing should catch that and send it back. Lean organizations normally have
each worker inspect the work of the previous operation in a chain. The general
managers are knowledgeable and competent to understand the overall system
and customer implications, and are looking to see whether the appropriate
knowledge has been created and applied.
Thus, to review a design, focus on a few key things (see Table 3.1). First, say,
“Show me the parts” (or drawings, CAD models, or schematics depending on
where you are in the development process). Then, say, “Explain to me how all
these parts fit and work together, and why you chose this approach.” Finally,
say, “Describe the trade-offs as they affect the customer and show me where this
design is relative to the limits.” Ask this same question regarding the manufactur-
ability of the design.
By the time you are done you will know whether the engineers being
reviewed have thought through their design, and whether it makes sense on the
basis of your broader knowledge.
Table 3.1 Manager’s Cheat Sheet for Design Reviews
Key Points for Design Reviews

1. Can you show me the drawing/solid model/part?
2. Explain to me how these parts fit and work together, and why you chose this
approach.
3. How does this design perform relative to its design limits?
4. Where is this design relative to the limits of our manufacturing technology?
5. What trade-off decisions did you make, and how do they affect the customer/our
manufacturing partners?
Changing Your Development Process

We’ve already introduced the idea that visible knowledge can revolutionize your
development process. Let’s explore that idea a little more.
To oversimplify, conventional development processes start with a guess at a
solution, evaluate its performance, and redesign it to solve any problems that
arise (as illustrated in Figure 3.1).
This process is unpredictable. A bad initial guess may be impossible to fix. Even
if it is, there is no telling how long it may take to fix it. It is also very expensive,
because most of the learning takes place late in the project, or even after the start
of production. Most companies try to reduce the cost by getting it right the first
time, using testing only to validate the design. But, by the nature of guesses, most,
even educated guesses, will be wrong: the emphasis on validation rather than test-
ing to discover failures tends to reduce the amount of information available for the
next design, forcing companies to reduce innovation or make mistakes.
The knowledge-based design process looks different (see Figure 3.2).
Oversimplifying again, it begins by gathering design limit information through
analysis, historical data, simulation, and test. It puts that information into a visible,
understandable form. And it designs near-optimal products within those limits,
assuring success. Innovation is focused on shifting curves and breaking constraints.
This process is highly predictable. We can learn how long it should take us to
create a nearly optimal design based on the current state of knowledge and his-
torical results. We can also learn how long it will take us to add a new curve to
our storehouse of visible knowledge or shift a curve. We can then build a devel-
opment system to produce the innovation throughput needed for the business
Conventional design process

Fix problems
Guess at a Evaluate the

design based design by analysis,
on intuition test, or simulation
Figure 3.1 Conventional design process simplified.
Knowledge-based design process
Create
Create visible
near-optimal
knowledge
designs
Figure 3.2 Knowledge-based design process, in essence.

on the timescale required. It enables us to shoot for the very best designs and
achieve expected results every time. This effective, sustainable, and efficient
development system concentrates our learning where it is most cost effective—in
simple analyses, simulations, and subsystem tests, not in making changes near
the end of the program.
Transforming your development process will take time. It will also take a plan.
You will need to set objectives for changes in your research and test pro-
cesses, and in your relationship with your suppliers, as described in the sections
that follow.
◾◾ If you have a cumbersome and complex project management system that is

fundamentally task-based, you will need to replace it with a simpler “lean”
system that is focused on learning cycles.*
◾◾ You will need to decide, project by project, which areas of your product
require new knowledge, and which can be designed on the basis of existing
knowledge.
◾◾ You will need to learn to innovate by looking at sets of possible solutions
rather than single solutions.
◾◾ You will need to evaluate the progress of your development projects based
on knowledge-driven criteria rather than task-based checklists.
When you innovate, you will not simply try to find a solution that works; instead,
you will need to understand the capabilities and limitations of entire families of
solutions: through trade-off curves.
This will lead you to a new concept of reuse. Your general philosophy will
become, “I’m glad that you have a new idea, but prove to me that it is fundamen-
tally better than the old idea, enough better to justify the risk and cost.” Said differ-
ently, “Does this new idea actually modify the curve, expanding the safe region, or
does it simply shift us elsewhere along the curve? More important to know, does it
move us across the curve into a known infeasible or unknown region?”
This process will enable you to reuse knowledge as well as parts. You will
reuse parts and approaches because the reuse is economically correct for this
specific project, not because of a one-size-fits-all fiat. It will automatically find
the right balance between innovation and reuse, because either innovation or
reuse will be justified based on the trade-off curves when evaluated against the
needs of the project.
* Project management is a subject worthy of a book in its own right, and several have been written. Some
resources that address this topic within a lean context include:
Knaster, R. and D. Leffingwell. 2017. SAFe 4.0 Distilled: Applying the Scaled Agile Framework for Lean
Software and Systems Engineering. Boston, MA: Addison-Wesley Professional.
Oosterwal, D. 2010. The Lean Machine: How Harley-Davidson Drove Top-line Growth and Profitability
with Revolutionary Lean Product Development. New York, NY: AMACOM.

Ward, A. C. and D.K. Sobek II. 2014. Lean Product and Process Development, 2nd Edition. Cambridge,
MA: Lean Enterprise Institute.

You will probably never get all the way to a fully knowledge-driven process
where everything is known upfront before committing to a detailed design solu-
tion. There will always be interactions unique to the new design, which must be
evaluated after the design is complete due to interactions. But you can dramati-
cally reduce the amount of prototyping and simulation that you need, shorten
your design cycles, and be more predictable. Do so gradually, so that you have
time to create the new knowledge you need; don’t attempt abrupt and radical
changes to your process.
Now let’s turn to some specific changes in other important aspects of the
development system.
Changing the Research Organization

Our goal here is to get rid of the fuzzy front end. We want to make the research
process efficient and manageable. The following explains how.
First, temporarily stop doing research. Your organization almost certainly has
an enormous amount of data that you are not effectively using. Put your research
organization to work converting this historical data into current visible knowl-
edge. Hold off on creating new data until you’ve got a handle on the existing
data. If you can’t convince the organization to temporarily stop doing research, at
least carve out a portion of your resources to convert historical data into current
visible knowledge.
Second, stop using your research or advanced development organization to
try to prove feasibility. Proof of feasibility takes an unpredictable amount of time:
most ideas never do work. Instead, use your research and advanced development
organizations to determine the limits and learn the trade-offs associated with an
idea. This includes understanding of your customer’s needs and wants, as well as
clear knowledge of the use environment. Demand that this be done to a regular
schedule and track it. Then, continuously shorten that cycle.
Third, use visible knowledge in the research process itself. For example,
Toyota researchers recently discovered a new alloy with outstanding perfor-
mance. One of their tools was a curve relating alloy properties to the average
number of electrons in the outer shells of the metal’s atoms.
These changes will dramatically improve the efficiency of your research orga-
nization. It will prevent you from wasting time on bad ideas, and it will make
research a manageable process like any other.
Changing Supplier Relationships

Visible knowledge facilitated profound changes in Toyota’s relationship with its
suppliers. Utilizing visible knowledge with suppliers completely changes the
relationship as a buyer, empowers the development organization, and drastically
reduces time to market while improving both cost and predictability.
First, rather than giving suppliers specifications and hoping these suppli-
ers can meet them, Toyota expects suppliers to provide limit curve information
characterizing their products near the ranges surrounding their design targets. So
communicate target specifications to suppliers, then ask for data on the trade-offs
associated with a range surrounding those targets. (By the way, if you are a sup-
plier, you can impress your customers and win new business by supplying trade-
off information on the specifications they give you and helping them optimize
their design with it.)
Second, Toyota expects suppliers to perform research leading to new prod-
uct concepts before Toyota’s projects begin. If the existing supplier for a car
line is performing satisfactorily, competitors can only displace the existing sup-
plier by demonstrating that their new concepts have shifted the limit curve. This
approach simultaneously encourages innovation while balancing loyalty to faith-
ful, high-quality suppliers.
Third, Toyota maintains an extensive database relating subsystem performance
to price. This enables Toyota to dictate the price of purchased subsystems, rather
than sending them out for bid.
Together, these skills enable Toyota to select suppliers near the beginning of a
development project. The supplier can therefore participate fully in creating new
knowledge.
Changing the Test Organization

In most companies, the test organization executes tests from a standard set or as
directed by the product development organization. Test engineers tend to be the
least experienced. Their goal is validation of designs in a build-test-break-rede-
sign world.
In knowledge-based companies, the test organization includes some of the
most experienced engineers. Their job is to understand the challenges the design
will face in the real world and economically determine the basic limits on con-
cepts and families of designs—to find the limits where they fail. Fundamentally,
knowledge-based companies switch from trying to validate designs to generating
useful knowledge.
This goal is essential because validation is in fact a logical impossibility.
Modern quality standards imply that a few failures in a million products are too
many—it is completely impossible to test enough samples that “passing the test”
will prove that failures will not occur under all design conditions. Modern quality
standards can be achieved only through profound knowledge leading to predict-
able performance.
This means that the test organization needs to
◾◾ Understand the customers and use conditions

◾◾ Maintain its own list of failure modes
◾◾ Test to failure against those modes and conditions

◾◾ Develop curves relating accelerated test results against field failure
experience
◾◾ Provide its reports using the full visible knowledge thought process, with
issue statements, illustrations, causal analysis, data, limit curves, and
countermeasures
For a given set of tests, these activities often take longer than the standard valida-
tion test. The test organization must compensate in three ways. First, it must find
clever, quick, cheap ways of finding limit and trade-off curves. Second, it must
create knowledge bases that take the place of most existing tests so validation
testing isn’t needed (because the answer is already known). Third, it must negoti-
ate with project leadership to ensure that innovation is allowed only where there
are adequate resources to understand it.
For test department leaders, visible knowledge represents a profound oppor-
tunity. They can change their role from relatively helpless servants of a process
into value creators of great importance. A visible knowledge approach makes test
organizations central to the development process.
Conclusion: Better, Faster, Cheaper

Visible knowledge can save money by reusing existing knowledge and prevent-
ing the errors that are the most expensive part of development. It can acceler-
ate the development process by speeding optimization, eliminating blind alleys,
reducing iterations, and enabling more effective communication between depart-
ments. And it can more effectively help development teams understand the trade-
offs to optimize cost and performance. As a bonus, it is also far more predictable.
Take a few minutes to think about how fast and how good your organization
could be if it built its development processes around these concepts. Could you
cut development time by 30%? 50%? More? Other companies have. Could you
increase innovation by a factor of 2? Or 10? Other companies have. Could you
reduce postlaunch problems by a factor of 2? Or 10? Or 100? Other companies
have.
How ironic is it that at the beginning of the twenty-first century, one of our
most powerful development tools can be traced back 100 years to a pair of
bicycle mechanics? Yet it is so. If Toyota’s 50-year rise from insignificance to
global dominance of its industry is any indication, companies that do not under-
stand and build visible knowledge cannot compete with those that do. And here
we have another great irony: a few lines on paper can drive a great revolution in
management, organization, and process.
Chapter 4
Applying Visible Knowledge
Whether you are interested in visible knowledge as a tool to enhance a conven-

tional development process or as a component of a lean or set-based develop-
ment system, you should have enough information about visible knowledge now
to begin applying the principles and using them. Chapter 1 introduced what
visible knowledge is and why it should matter to you. Chapter 2 presented how
to create visible knowledge through an example. If you worked an issue of your
own as you completed the exercise, you have at least one trade-off curve sheet at
this point. Chapter 3 then raised several issues related to using visible knowledge
in companies, such as knowledge management and changes to leadership behav-
iors, changes to the development process, changes to research and test organiza-
tions, and dealing with suppliers. Hopefully, you’ve taken the time to consider
how they apply to your situation.
In this chapter, we discuss the application of visible knowledge. Although
we cannot address everything involved with instituting visible knowledge, we
will cover some of the fundamental aspects to help you get started, begin-
ning with the basic idea of establishing a visible knowledge mindset. We then
address alternative sources of knowledge (or rather, data from which you can
create knowledge) with examples from different industries so you can see how
to turn existing information into visible knowledge. We also discuss how visible
knowledge can be used to improve collaboration across functional boundaries.
And finally, we conclude with the all-important role of leadership. Whether as
a team member, a midlevel leader, or an executive, your leadership is the dif-
ference between successful transformation and status quo. Stepping out of the
comfortable confines of what you know and how things have always been done
is difficult, yet it is essential to effectively change the paradigms of development.
Woven throughout the chapter are illustrations of how managers and frontline
developers can use visible knowledge to help their teams achieve new levels of
excellence.
71
Establish a Visible Knowledge Mindset

As you begin to put visible knowledge in place, a foundational challenge will be
to establish a visible knowledge mindset across the team, group, or organization.
As we’ve seen, many people involved in product development (especially engi-
neers) are conditioned by the pressures of the business to pick a solution quickly
in order to solve a specific problem and move on. They are not accustomed to
thinking in terms of creating reusable knowledge as a part of their responsibility.
It may seem inefficient to stop and clarify the problem, to consider the entirety of
an issue, or to explore the boundaries of possibilities, much less to create trade-
off curve sheets under the pressures of a deadline when a quick solution may
suffice. The rush to solve problems must be unlearned in establishing a mindset
of creating reusable and visible knowledge. As you consider your approach to
building knowledge, you may find it necessary to focus initial efforts on estab-
lishing the mindset. As the mindset starts to take hold, you will identify opportu-
nities to create knowledge in everyday work.
Not all visible knowledge needs to be analytically intense. Perhaps the exam-
ple in Chapter 2 scared some of you who are not trained as mechanical engi-
neers or are a bit rusty in your skills. Don’t worry; the idea of visible knowledge
is fairly straightforward and can involve knowledge you already have, or be
derived from information that can be obtained fairly readily—provided you have
the mindset.
Let’s illustrate with an example.
Let’s say you work at a multinational consumer products company. Your com-
pany makes everything from food products to baby diapers and everything in-
between. With the diversity of products you produce and the markets you serve,
there is no way that you can be an expert in everything that your company
makes or markets in which you sell. You have just been assigned to the personal
care products division and moved to a foreign country with the assignment to
improve product development because the division’s sales revenue is declining.
You have no experience with personal care products other than as a consumer,
and you are unfamiliar with the market in the new country.
How do you proceed?
Fortunately, you have experience as a product development leader and you
are experienced in visible knowledge principles; most importantly, you can ask
questions. In your effort to drive change to reverse the division’s declining sales
revenue, one of the engineers, Peter, comes to you and expresses his concern
that visible knowledge takes too long and is unnecessary given the type of
problems that he deals with on a daily basis. Upon inquiry, you learn that Peter
has been working on a quality issue related to a high incident rate of consumers
reporting rust on cans of shaving gel that is negatively affecting sales.
Your instinct is to probe to better understand the issue, so you ask Peter to
show you a part. From reviewing the part and further discussion with Peter, you
learn that rust forms on the top of the shaving gel cans in the area under the
Applying Visible Knowledge ◾ 73
plastic cap. Peter has been tasked with reducing incidents of rust on cans and
reducing customer complaints as measured in parts per million (PPM).
Thinking there must be similarity with metal aerosol antiperspirant cans, you
ask if the same condition occurs on antiperspirant cans, which are produced
in the same division. Peter, perplexed by the question, replies that antiperspi-
rants are a completely different product developed by a different department.
You quickly realize that the two departments do not communicate because the
organization considers them completely different products. You then suggest
that although the products in the cans are different, the containers share a lot of
similarities and perhaps understanding how the department developing antiper-
spirants deals with corrosion could be useful.*
Peter then confesses that he has been under tremendous pressure to address
this problem since it is contributing to loss of sales and that he has already iden-
tified a solution. Because he is in the process of implementing the solution and
the organization is already moving ahead with the changes, he would not be able
to check with the antiperspirant team. Intrigued, you ask him to explain how he
plans to address the quality issue and why he chose the approach.
Peter responds that it is simple: the cans currently receive one coat of paint
in the factories. He plans to send the cans back through the paint process for a
second coat of paint to double the thickness of paint applied to the cans. This
was a quick and easy solution the plant could implement with no investment and
would improve rust protection. So, you ask how much he expects the change
will improve the quality. Peter again looks perplexed in a way indicating that he
had not really considered the degree of improvement. Thinking on his feet he
said, “Well, doubling the paint thickness should cut the complaints in half.” Not
satisfied with that response, you ask him how the change in paint thicknesses
performed relative to design limits, and if the laboratory corrosion testing con-
firmed his hypothesis. Peter responds that laboratory testing is useless because
there is no correlation between lab testing and the field complaints. He confides
with you that engineers in the division are forced to make decisions based on
experience and intuition because there are a lot of issues that come up regularly
and they are under tremendous pressure to solve them quickly.
Now at this point you may be thinking to yourself that this would never hap-
pen in your company. Yet, in the organizations we encounter, the players and the
products may be different, but the story line is the same. So let’s look at the wealth
of knowledge available in this simple example even without any complex analytics
or calculations, provided you approach it with a visible knowledge mindset.
* Unlike industries such as automotive, which organize by product subsystem such as body, chassis,
etc., this company only considered their product as the final product they sold to the consumer. This
approach caused them to miss the opportunity of recognizing the container as a common subsystem
around which to build knowledge. Each developer had to have knowledge for all aspects of the final
product. By instituting the mindset of visible knowledge, the common systems across the various prod-
ucts begin to emerge. In recognizing common systems, the vice president of R&D for the division on
which this example is based emphatically demanded, “We must reorganize to align with the knowledge
streams!” This realignment alone resulted in tremendous efficiency gains for the organization.
What are the opportunities that you see in this example? Think about it for a moment.
In Chapter 1, we created a curve based on different engine families and their
failure rates to identify a crankpin diameter for a new engine. We did not use
any complicated analytics or algebra to derive formulas. In that case we identi-
fied the warranty cost per engine and plotted it against a “generalized stress
factor” concocted based on what we felt from experience would represent the
key design factors. In this case Peter has a similar opportunity. Although it did
not appear that he had a great deal of data, he has access to quite a bit of knowl-
edge, and he can build more knowledge in a simple way.
First, Peter has one of the most valuable pieces of information for a designer:
the consumer complaint rate relative to the design. Since Peter knows the cur-
rent complaint rate and has unlimited access to the product from the factory,
he can test the current products on the laboratory corrosion test to correlate lab
results with the current field complaint rate. Next, since he has already decided
to double the paint thickness, he will automatically develop new complaint rate
information after the change goes into effect. He can take some of the new prod-
uct, which he is assuming will reduce the complaint rate, and also test it in the
laboratory. From these simple actions, Peter will have two points from which he
can begin creating visible knowledge similar to the engine crankpin example. A
simple depiction is shown in Figure 4.1.
From the figure, you will immediately identify that because there are only
two points, we don’t know the shape of the curve. For simplicity, we’ve drawn
One pass of paint

Customer complaints (ppm)
Two passes of paint
Paint thickness (µm)
Figure 4.1 Shaving gel PPM curve.

it as a straight line as a first approximation. It may not be perfect, but these

two points give us a starting point for building reusable visible knowledge. The
relationship may be more accurate as a curve as indicated by the dashed line.
At this point we don’t know, and it is not all that critical. By collecting informa-
tion and making what we know visible, we create a basis for dialogue. We also
have the opportunity to evaluate other products against the same criteria. A
good starting point would be to evaluate antiperspirant cans we already pro-
duce in similar tests and compare them to their field complaint rate. We can
also begin to build knowledge related to other coatings or different thicknesses
of coatings.
Since we now have two data points that include both field data and laboratory
test data, we can begin to correlate our lab data with field data that has been
missing.* If we find that the separation in laboratory testing does not reflect what
we see in the field, we must consider if our laboratory tests are an appropriate
surrogate for the field. Lack of correlation would be a strong signal that we do
not fully understand our products, our customers, or the field conditions. Going
forward, we will eventually have data that would allow us to build visible knowl-
edge relating rust complaint PPM and laboratory testing to sales.
You may be thinking that this is a lot of work for a simple issue for which
Peter had already identified a solution. So let me ask you this, “What do you
think will happen in a few years?”
Peter is a bright young engineer, and like most bright young engineers, he
is under consideration for a promotion into another part of the company. Once
he moves on to another role, his current role will most likely be filled by a new
engineer, who is new to the company or new to shaving products. You can
imagine that, over time, the pressure to reduce product cost or increase through-
put of the paint area in the plant will cause the new engineer to look at eliminat-
ing a pass of paint. Without a mindset of actively creating visible knowledge in
the department that each engineer is expected to build on, the new engineer will
most likely be pressured to eliminate a paint pass, and we will be exactly where
we started this story, with the opportunity to learn this lesson all over again.
Could it be possible that the quick solutions approach is contributing to the
constant flow of issues that engineers like Peter must address on a daily basis?
Think about the firefighting that goes on in your organization.
Summary
In this example, we see all three aspects related to organizing knowledge
described in Chapter 3.
* As it turns out, there was in fact, a lot more information available through the test department, as will be
explained later.
1. Organize departments, as much as possible, around knowledge of the

operational value stream.
2. Expect everyone to create visible knowledge.
3. Hold everyone responsible for delivering and sharing the knowledge they
have, and getting the knowledge they need.
Establishing a visible knowledge mindset focuses everyone’s attention on the

need and desire to create, share, and use knowledge. It helps us see the gaps
in our understanding and highlights opportunities to close those gaps. A vis-
ible knowledge mindset aligns the development organization with the desire to
cultivate deep understanding and expertise, fostering the development of people
along the way. In the simplest form, that is all that product developers do: create
and use knowledge. Make it easier for your organization by aligning people for
the flow of knowledge creation, and expect everyone to create and share visible
knowledge.
Alternative Ways of Building Visible Knowledge

As you consider the monumental task you face to build visible knowledge for
your organization, even with a visible knowledge mindset, success will require
a plan. Chapter 2 outlined an analytic approach you will want to institute to
effectively build true, deep visible knowledge in your organization. There are no
shortcuts to creating visible knowledge, but there are approaches you can employ
to speed up the process. Three aspects to contemplate as you evaluate your
approach are how to leverage existing data, how to tap into the expertise you
already have, and how you can best conduct designed experiments.
Leveraging Existing Data

When Allen Ward worked with the Harley-Davidson Motor Company in help-
ing them institute Lean Product Development, he used to say, “You’ve got to
shut down development testing. You already have all the information you need.”
Harley-Davidson did not shut down development testing, and such a drastic
move is probably unwarranted in most cases, but Allen’s point is a good one.
Organizations have far more knowledge available to them than they realize or
use—it just happens to be in the wrong form.
In the example above, it turned out that Peter had far more information avail-
able to him than he knew. The test department had conducted hosts of corrosion
tests on various coatings for metal cans. However, each was an individual test
with its own test report requested by different engineers for different purposes.
Each test was conducted to answer a specific question, and no one had ever
synthesized the information from the various reports together. Peter would have
needed to read each document to get the small bit of applicable information
out of it, then combine the data into a continuum to understand the trade-off
of coatings and corrosion. It would have been both inconvenient and time con-
suming for Peter to extract the knowledge he needed. This is not uncommon.
Developers would often rather run a new test than go through the effort of find-
ing existing information due to the difficulty (and uncertainty) of extracting data
point by point. By employing temporary engineering interns to extract data from
existing test reports and compile the data in the form of trade-off sheets, the
consumer goods company in this example created visible knowledge useful for
evaluating coating properties against corrosion results quickly and inexpensively,
building on the two points in Figure 4.1.
Allen’s insistence to stop testing was due to his recognition that so much
information goes unused. Most test results are documented in individual reports
that are filed based on specific incidents related to a particular test. Extracting all
of these data could produce a wealth of knowledge if it were synthesized and
made visible on a continuum based on key characteristics.
Think how you might leverage existing data your organization has already
collected. What would it do for your development process if you had this infor-
mation in the form of visible knowledge at your fingertips?
Tapping the Experience of Seasoned Employees

You also have a tremendous opportunity to leverage what is in the heads of your
employees. For example, let’s go back to the personal care division of the con-
sumer products company and imagine that you have been making some progress
with establishing a visible knowledge mindset. Your effort has now shifted more
toward building up the knowledge base for the group’s development efforts. One
day you are talking to one of the engineers who has been working in laundry
detergents for many years about the impact of high-efficiency washing machines
that operate at lower wash temperatures and the effect of water temperature on
the wash performance of the laundry detergent. In the past, a conversation like
this would have quickly concluded with the recognition that lower water temper-
ature is bad for wash performance. But in order to reinforce the visible knowl-
edge mindset you are working to establish, you ask the engineer what a causal
diagram might look like for the impact of lower washing temperatures on stain
removal for laundered fabric. (Recall that this is essentially the issue statement—
Step 1 from Chapter 2.) She sketches out the diagram shown in Figure 4.2 based
on her many years of experience.
In the causal diagram, she identifies four stain types that could be affected dif-
ferently by lower wash temperatures for stain removal: fatty, enzymatic, particulate,
and bleachable soils. Intrigued that she has immediately broken the problem down
into four distinct stain types, you ask about the effect of reduced temperature on
each type. After a bit of thought, she sketches out the curves shown in Figure 4.3,
depicting her assumptions of how lower temperature impacts wash performance.
Blood Grass
Skin
Potato
il
Olive o le Human Protein Corn
etab
Veg Starch
Rice
Motor oil Enzymatic
Fatty
Mineral
es
Stain typ
Particulate
Bleachable soil
Red wine
Ink Pollen
Dirt Sand
Figure 4.2 Stain removal causal diagram.
Bleachable Enzymatic
Performance TAED P
Percarbonate Enzym 1
Enzym 2
Enzym 3
20 40 60 80 100 20 40 60 80 100
Temp Temp
P Fatty P Particulate soil
Surfactant
Builders
20 40 60 80 100 20 40 60 80 100
Temp Temp
Figure 4.3 Detergent trade-off curves.
From years of experience developing laundry detergents, she has developed

a feel for what the key causal relationships are and the differences in how the
various stains behave based on their properties. She has also developed a sense
for the basic shape of a trade-off curve. In short order you have shifted from the
traditional answer that lower water temperature is bad for wash performance to
a thoughtful depiction of the expected relationship between water temperature
and wash performance. Just drawing out what was in her head is huge. It makes
what she knows visible so others can have a conversation about it. By having it
visible, others can see it, can debate it, and can contribute. Most importantly, you
can test these assumptions to validate or refute it—which is where the greatest
learning occurs.
We have found that experienced people generally have a good feel for one-
to-one causal relationships. However, as they draw them out in a diagram, the
causality across multiple variable relationships becomes more difficult because
most of us are not accustomed to overtly think in those terms. Our brains tend to
simplify down to the minimum number of useful variables (usually two). Good
experienced people can generally draw out a relational trade-off curve in two
dimensions that are directionally correct, but the specifics tend not to be entirely
accurate.
Nevertheless, going through this exercise with experienced people is a fan-
tastic way to begin instituting a visible knowledge mindset as they articulate
on paper what they think happens. These documents are great starting points
for building trade-off curve sheets. Giving these sketches to junior engineers to
verify sets up tailor-made mentoring opportunities between experienced people
and junior developers. Both learn in the process and the organization builds tre-
mendous knowledge.
As you plan to institute visible knowledge, think about how your organization
can leverage the data that you have already collected through your test depart-
ments. Think about how you might draw out the knowledge that has amassed in
the heads of your more experienced developers. In the case of knowledge that
needs to be developed, consider conducting designed experiments.
Using Designed Experiments

Let’s return again to the consumer products company, where you are now try-
ing to convince Jan, the division’s vice president of research and development, to
implement visible knowledge division-wide. Jan recognizes the need to improve
and is anxious to drive improvement to the product development process. You
have a good relationship with Jan, and he has been a great partner in driving
change. He has been willing to adopt other ideas you have brought to him for
improvement, but when you propose visible knowledge, Jan becomes skeptical.
“Visible knowledge may work for cars and motorcycles,” he says, “but we are a
chemicals company. It won’t work here.” Nevertheless, he is willing to run a trial*
* For readers new to change management, conducting a controlled trial is an effective way to institute
change. A controlled trial allows for fast learning under isolated conditions so you can adapt quickly to
learning with a higher likelihood of success.
and assigns Wim to work with you. Wim has been with the company developing
antiperspirants for more than 20 years. Like the other products the division pro-
duces, other than being a user of antiperspirants, you know absolutely nothing
about them. So, you start this effort like every other, by first defining the issue,
or objective (Step 1: State the Issue, from Chapter 2). In this case, you agree on
the objective to define the relationship between the design parameters, and the
wetness and odor control of antiperspirants.
With the objective defined, you move on to creating a causal diagram
(Step 3: Create a Causal Diagram, from Chapter 2). You ask Wim to sketch out
causal relationships between the design parameters and product performance
based on his experience. Wim sheepishly responds, “I don’t know the causal
relationships. It’s kind of a black art. We modify various ingredients and test
them until we find a formulation we like.” With multiple simultaneous input
variables affecting the output, the cause-and-effect relationships are far from
straightforward. Recognizing that you need to take a step back, you ask Wim
what ingredients he typically modifies in his formulations. He then lists the
ingredients and the typical ranges of ingredient makeup in a formulation.
Although this is not a causal diagram, it provides a starting point to develop
trade-off data. Together you work through the combination of ingredients in a
design of experiments matrix to develop a minimum number of formulations
and tests to allow you to distinguish the influence of the change from each
ingredient.
With the design test matrix complete, you submit the test requests and for-
mulations to the laboratory for testing, and they agree to conduct the testing
when test slots become available. After some time, you receive test data back and
begin to analyze it. It is not too long until patterns begin to emerge. With further
manipulation of the spreadsheet you are able to tease out the patterns and even-
tually display the data in a diagram similar to Figure 4.4. (The information has
been changed to protect the company’s intellectual property, so please don’t use
this to develop antiperspirants.)
Although you know nothing about the formulation of antiperspirants, and
the curves carry little meaning for you, when Wim sees the curves for the first
time, his face lights up as he exclaims, “So that’s how antiperspirants work!” After
20 years of working on antiperspirants formulating and testing ingredients, this is
the first time Wim recognizes the causal relationships between how the changes
in formulation affected the product performance.
In the case on which this example is based, Wim also discovered an ingredi-
ent in the formula that had no impact on the performance at all. It cost less than
a penny per can, but multiplied by the millions of cans sold every year, it was
a significant savings. (Apparently, years earlier, the ingredient was added based
on a salesperson’s pitch. Over the years it had just become a standard part of the
formulation recipe. There had been questions from time to time, but everyone
was afraid to remove it for fear of not knowing what the removal would do, so it
continued as a staple in the recipe for years.)
Wetness and odor vs. discharge rate

60.00
10 × Odor, 4% active 10 × Odor, 2% active
50.00
40.00 Wetness, 6% active

10 × Odor, 6% active
30.00
Wetness, 4% active
20.00 Wetness, 2% active
10.00
0.00
0.30 0.40 0.50 0.60 0.70 0.80 0.90 1.00
Discharge rate (g/s)
Figure 4.4 Antiperspirant trade-off curve.
The trial turned out to be very successful. Not only did it result in a product
change to save considerable money without affecting the consumer, it trans-
formed antiperspirant development. The curves Wim created provided the infor-
mation needed for most of the development efforts. They virtually eliminated
the need for the routine testing that had been required in the past, freeing up
test capacity and reducing development time by months because formulations
testing was replaced by simply looking up the performance on the curves.
Antiperspirant development shifted from repetitious testing of various formula-
tions to conscientious efforts to shift curves, or identify new curves through new
ingredients.
Jan saw the tremendous advantages for his organization and soon all product
development under his control were creating trade-off curves and building visible
knowledge. Even sales and marketing got on board: rather than providing point-
based design specifications, they provided their best estimate for sales and profit
in terms of design attributes. Jan’s research and development department became
a fun and dynamic place to work. An organization that had developed a reputa-
tion for the lowest morale and highest employee turnover became the organiza-
tion where people requested to work.
The ultimate endorsement for the change to visible knowledge came when
a customer requested a proposal for a new bath gel. The customer was losing
sales to a competitor, so they were quoting a number of suppliers in the hope
that someone could quickly develop a product to compete. Since the team that
developed bath gels had created trade-off curves, it was simply a matter of com-
paring the customer’s needs to the formulations on the curves. Jan was able to
confidently commit to supply a new product that met the customer’s needs with
no testing. Although the new product they requested normally took more than
a year to formulate, the longest lead time became building the tools for a new
bottle. Relieved, the customer happily signed a contract to buy the new product
at a premium.
How would having this type of visible knowledge for your products change
your development organization and development system?
Use Visible Knowledge to Enhance Cross-Functional

Collaboration
We have discussed visible knowledge as a development tool primarily for use
in the technical understanding for design decisions. It could be construed
that trade-off curve sheets and limit curves are the domain of the engineering
or technical organization only. This would dismiss one of the most power-
ful aspects associated with trade-off curves: cross-functional collaboration.
Certainly, it is straightforward to recognize that making knowledge visible
enhances collaboration and the decision-making process within the develop-
ment or technical community. Trade-off curve sheets are a vital component
for effective integration events,* particularly early in the development pro-
cess. Whether you use trade-off documents as a part of a lean development
methodology or simply a tool in a traditional process to enhance dialogue,
they are helpful in shifting cross-functional decision from emotional to factual
decisions.
Let’s look at an example from a different industry: underground mining. With
apologies to the readers in the mining industry, we will oversimplify an aspect
of mine development to share how visible knowledge enhances cross-functional
collaboration. In this example, imagine that you are the leader developing a
major underground mine. As any good leader, you might set annual targets for
the mine to support your business plans and cascade objectives to your various
functional leaders. Inevitably, conflicting goals emerge.
Reflect for a moment on how your organization tries to align goals. How do
you deal with conflicting goals? Let the department managers work it out when
they arise?
In the case of a mine, let’s look at two specific functional areas: operations
and maintenance. As the mine is developed, operations is responsible for remov-
ing all of the earth, but in order to keep mining, they also need to fill in voids
behind them to keep the ground stable. The primary means of backfilling is
* Integration events are crucial points where information from the different subteams on a project is
brought together and key decisions are made (see Oosterwal, D. 2010. The Lean Machine: How Harley-
Davidson Drove Top-line Growth and Profitability with Revolutionary Lean Product Development. New
York, NY: AMACOM).
through pumping a slurry of crushed rock and sand back down the mine after
the ore has been extracted. Thus, the objective for operations is to maximize
muck* removal and backfilling of voids. In order to enable the removal of ore
from the mine, the maintenance function needs to ensure that the equipment
is always available for operations to use. In this case, one of the keys to being
able to backfill voids is the piping which pumps the sand slurry to the voids so
they can be filled. One of the primary objectives for the maintenance function
is uptime, or the elimination of times that the backfill system is not available to
pump slurry to the voids.
However, the sand slurry is abrasive to the pipes and equipment, so the faster
the slurry moves through the pipes, the faster the pipes wear out and cause
downtime.
Naturally, the operations function wants to pump backfill slurry into the voids
as fast as possible to meet production targets. Backfilling is a necessary evil since
it produces no value in terms of ore removal, but is required to stabilize the
mine. The rule of thumb for the miners has always been to pump as fast as pos-
sible. As you can imagine, when the equipment to pump the backfill slurry is not
available, there are some very heated conversations. Not only does it halt min-
ing progress, but the inability to fill voids disrupts schedules for the mine with
a ripple effect on the overall progress as crews are sent home or reassigned to
make up for lost production.
Question: Is pumping the slurry mixture to the voids as fast as possible the
right thing to do for the business?
Let’s first look at the question from the perspective of the operations func-
tion. Let’s say that the objective for the mine is to remove 550,000 tons of muck
from the mine for the year. Given the mine development plan, you can iden-
tify the voids and the amount of backfill slurry you will need depending on
whether you use 60% or 70% of solid fill. Based on the amount of slurry and
the rate at which you pump the slurry, you can identify the number of opera-
tions hours your crews need to work on backfilling voids. If you create a trade-
off curve for the hours as a function of pumping rate, you will have curves as
shown in Figure 4.5.
For the operations leader, this diagram supports the notion that pumping
faster is better. The curves show that the faster you pump slurry, the less time
crews need to devote to backfill, although there is a diminishing rate of return.
From this diagram, perhaps it makes sense to pump around 1,400 to 1,600
gallons per minute.† Due to the regular breakdowns of the pumping system,
at times there may be a need to pump faster to catch up after the system has
been down.
When you consider the question of what rate to pump slurry from the per-
spective of the maintenance department, however, the answer may be different.
* Muck is the combination of ore and waste rock that has been broken up by blasting.
† In the real case that drove this example, the mine was pumping at around 1500 gpm.
6000
5000
Annual fill time (hours, assuming 550K tons)
4000
3000
70% Solid
60% Solid
2000
1000
0
0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800
Flow rate (gallons/min)
Figure 4.5 Backfill time trade-off curve.
The objective for the maintenance department is to ensure uptime of the pump-
ing system. Maintenance wants to make sure that the system is operational to
avoid getting chewed out, but more importantly, they need to achieve their
uptime objectives to get their bonuses. So, let’s look at what the impact of slurry
flow rate has on downtime. Looking through historical records of maintenance
and the rate at which slurry was being pumped, you can create a trade-off curve
as shown in Figure 4.6.
Downtime as a function of flow rate is an exponentially increasing relation-
ship. This makes sense as the slurry is abrasive, so the higher the pressure and
the faster the flow, the more abrasive the slurry is on the equipment. From the
perspective of the maintenance department, the ideal flow rate for pumping
slurry would be about 400 gallons per minute. Even before having data, the
notion of pumping at 400 gallons per minute would never fly.
So, what is the rate at which the mine should pump backfill slurry?
If operations and maintenance share their knowledge on how the system
operates from their perspective, you can combine the curves in a way that pro-
duces the diagram in Figure 4.7. In this case, the ideal flow rate to optimize the
output of the mine would be around 800 to 900 gallons per minute depend-
ing on the amount of solid material used in the backfill. Pumping slower would
increase the amount of time the crews spend backfilling. Pumping faster would
6000 6000
5000 5000
4000 4000
Annual downtime (hours)

3000 3000
2000 2000
1000 1000
0 0
0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800
Flow Rate (gallons/min)
Figure 4.6 Downtime trade-off curve.
6000
60% Solid
5000
cumulative time
Time required (hours per year, assuming 550K tons)
4000
70% Solid
cumulative
3000 time
70% Solid
fill time
2000
60% Solid
fill time
1000
Annual downtime
0
0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800
Flow Rate (gallons/min)
Figure 4.7 Backfill rate trade-off curve.

increase the amount of time that the crews wait for the equipment to be avail-
able. This example illustrates how making knowledge visible in the form of
trade-off curves, and then sharing the curves cross-functionally changes the way
we collaborate, interact, and make decisions.
In the case behind this example, creating the trade-off curves allowed the
two functional leaders to end years of emotional arguments. The data allowed
the mine leadership to shift individual goals to objectives that truly maximize the
benefit to the company over individual departments.
There are some interesting points worth mentioning that come out of the
visible knowledge displayed in Figure 4.7. It is human nature to react to short-
term feedback. The operations functions are measured daily and often even
to the minute. Feedback to making or not making goals is immediate. When
operations falls behind plan, the immediate reaction is often to drive for filling
faster because that quickly increases output to bring it back in line with objec-
tives. In the case of the maintenance function, by contrast, downtime of the
system fluctuates, making it less predictable, so the cause-and-effect feedback
can be delayed or muted. The delayed reaction for increased maintenance due
to increased backfill flow rate is often not directly correlated due to the time
lag. Looking at the curves, the flow rate of 1500 gallons per minute the mine
was running requires more total hours in terms of fill and downtime than run-
ning at 400 gallons per minute, which would never be tolerated. Our gut feel
or the rules of thumb that have been developed over time often lead to the
wrong decisions.
With the trade-off curves in Figure 4.7, you can identify the optimal flow rate
to operate the mine under the current conditions. If the profit margin is such
that additional hours in terms of filling and downtime warrants the increase in
production, it may be worth operating at a higher flow rate. Bear in mind that
increased output under the current conditions comes at a reduction in profit
margin because you can only move along the curves. To improve the efficiency
of the mine, the conditions would have to change. From the operations perspec-
tive, either the crews become more efficient at filling at the existing flow rates
(in other words, the total fill time decreases and the curves shift down) or new
curves are added to the left requiring less fill material. From the maintenance
perspective, they would need to shift the downtime curve to the right by either
becoming more effective at fixing the system when it breaks or using differ-
ent technology that is more resistant to abrasion, which would extend the time
between failures at a given flow rate.
This notion highlights the leadership responsibility when using visible knowl-
edge. First, optimize under the current conditions of the system. Then look to
change the system by shifting curves or create new operating conditions with
associated curves. From a product development perspective, there are three pri-
mary knowledge areas: functional knowledge, operational knowledge, and market
knowledge. Functional knowledge is visible knowledge that depicts the trade-offs
and limits for how the product operates under given criteria. Functional knowl-
edge is developed from analysis as shown in Chapter 2, as well as from failure or
test results. Operational knowledge is visible knowledge that depicts the trade-offs
and limits for the tools, equipment, and operating systems used to produce your
products. Operations knowledge is developed from analysis, time studies, and
equipment specifications. Market knowledge is visible knowledge that identifies the
market conditions under which the products operate in your customers’ hands, as
well as the trade-off and limits related to customers purchase intent for your prod-
ucts. Market knowledge is generally developed through field studies, historical and
market analysis, and customer interaction.
You may be thinking to yourself that the mine example is overly simplistic
because the products you develop are different than mine development. How
are specifications conveyed in your product development? Are specifications
defined as an absolute? Do the specifications ever conflict? If you are develop-
ing cars or motorcycles, for example, a specification such as 35 miles per gallon
for the vehicle conflicts with an acceleration target of 0 to 60 miles per hour in
6 seconds. As a development team, how do you prioritize?
In the consumer goods company example discussed earlier in this chap-
ter, sales and marketing teams shifted from absolute specifications to trade-off
curves. What would it mean to your development teams if your specifications
identified curves of gas mileage and acceleration times versus vehicle sales.
Perhaps there is a particular performance goal you need to meet to be competi-
tive. Wouldn’t it be nice to see that in the form of a trade-off or limit curve? What
about the addition of a new feature marketing expects to be popular but is heavy
and impacts both fuel economy and acceleration? Wouldn’t sharing information
in the form of trade-off curves create a better forum for dialogue and collabora-
tion across functions to optimize your products?
You may say that we don’t know the trade-off of miles per gallon versus
sales. And you would be correct, but you don’t know your sales at an absolute
miles-per-gallon specification level either. At least by drawing out what is in your
head on a piece of paper, you can have the conversation and encourage healthy
dialogue. Moreover, once you’ve documented your hypotheses, you can look
back after the fact and learn. If you are shifting toward, or currently operate in a
set-based or lean development system, you will need this kind of information to
conduct effective integration events anyway.
Presentation Is Important
How and what you present as visible knowledge is important because it can
affect the story and the message you intend to convey. Consider the tragic exam-
ple of the space shuttle Challenger and how the presentation of accurate informa-
tion can still lead to incorrect decisions. On January 28, 1986, the space shuttle
Challenger exploded 73 seconds after liftoff from the Kennedy Space Center kill-
ing all seven crewmembers on board.
The cause of the Challenger accident was consequentially determined to be
failure of the rubber O-rings that sealed the joint between two sections of one
of the Challenger’s ancillary booster rockets. On the morning of January 28,
the weather was uncharacteristically cold for Florida with temperatures fore-
cast between 26° and 29ºF. Due to the frigid temperatures, the technicians from
Morton Thiokol, who produced the ancillary booster rockets, advised against the
launch. The joint that failed between the sections of the ancillary booster rockets
was sealed with a series of six O-rings. No previous launch had ever occurred at
such a low temperature. Although none of the joints had previously failed, some
flights had exhibited problems related to the joints where some, but not all, of
the O-rings failed. Due to concern over the effect of the low temperature on the
joints, the technicians from Morton Thiokol sent a 13-page fax to NASA advis-
ing them not to launch on the morning of January 28. The NASA officers found
the data and tables in Morton Thiokol’s recommendation insufficient to conclude
a relation between low temperatures and the effectiveness of the O-ring joints.
After intense debate NASA decided to proceed with the launch, even though
it was the first time that Morton Thiokol advised a no-launch in 12 years of
missions.
Your first reaction to this example may be that NASA does not operate
under the same constraints and pressures you experience for the launch of
your development projects, and they should have delayed the launch on the
basis of the request. However, NASA was under considerable pressure to launch
the Challenger. Liftoff for space shuttle Challenger was initially scheduled for
January 22, six days earlier, but a series of events had already delayed the
launch to that fateful morning—mission delays in the onboard space probes,
bad weather at the abort landing site followed by bad weather at the launch site,
and malfunctions in the ground servicing equipment all contributed to delaying
the launch to January 28.
From an economic perspective, competition from the European Space Agency
required NASA to fly the shuttle dependably on an ambitious schedule to prove
the cost-effectiveness and viability for commercialization of the shuttle program.
NASA had scheduled a record number of missions in 1986 to make a case for its
budget requests.
From purely a scheduling perspective, NASA needed to launch the Challenger
so the launch pad could be refurbished in time for the next mission, which
would be carrying a probe to examine Halley’s Comet. An on-time launch
would allow the United States to collect data a few days before a similar Russian
probe would be launched. A delay could cause NASA to miss collecting data on
Halley’s Comet altogether.
From a political perspective, President Ronald Reagan planned to give his
State of the Union address on February 4, 1986, with his main topic to be
education. He expected to mention the shuttle and the first teacher in space,
STS 51-C
3
Field joint
61A
2
Number of
incidents
41B 41C 41D
1
61C STS-2
0
45 50 55 60 65 70 75 80
Calculated joint temperature (°F)
Figure 4.8 O-ring failure data. (From: NASA. 1986. Report to the President by the
Presidential Commission on the Space Shuttle Challenger Accident, p. 145, https://spaceflight
.nasa.gov/outreach/SignificantIncidents/assets/rogers_commission_report.pdf.)
Christa McAuliffe. As a result, NASA was under tremendous pressure to launch

Challenger. The decision to launch or delay was not easy and followed a pre-
defined protocol.
Let’s look at the information available at the time of the decision and how
it was presented. Figure 4.8 depicts the table included in the lengthy fax from
Morton Thiokol, intended to relate ambient temperature to joint failures to sup-
port their recommendation to NASA not to launch.
The report of the Presidential Commission on the Space Shuttle Challenger
Accident* identified that the NASA officers involved in making the decision to
launch or delay found the data and tables insufficient to conclude a relation
between low temperatures and the O-ring joints.
When you look at Figure 4.8, what conclusions do you draw from the
diagram?
NASA staff analyzed the data for the relationship between ambient tempera-
ture and number of O-ring failures (out of 6). In the diagram you can see that
only failure data is included. Data from missions where no O-rings failed were
excluded. They believed that conditions where there were no failures were unin-
formative. However, retroactively as a part of the accident investigation, these
data were reanalyzed and included launches with no O-ring failures. A logistic
regression model was fit to the complete data set in order to produce a predicted
extrapolation for the probability of failure at the lower ambient temperature
experienced on January 28, 1986. Figure 4.9 depicts the information that was
available at the time of the launch converted into the form of visible knowledge.
Take a moment to look at both Figures 4.8 and 4.9. Which diagram makes
a more compelling case for Morton Thiokol’s no-launch advisory? Figure 4.8
presents data leaving the conclusion to the discretion of the reader. Figure 4.9
* NASA. 1986. Report to the President by the Presidential Commission on the Space Shuttle Challenger
Accident. https://spaceflight.nasa.gov/outreach/SignificantIncidents/assets/rogers_commission_report.pdf.
100
90
80
70
Probability of failure (%)
60
50
40
30
20 Temperature
forecast
10 26°–29° F
0
25 30 35 40 45 50 55 60 65 70 75 80 85
Temperature (°F)
Figure 4.9 O-ring joint data.
progresses from data to visible knowledge where there can be no confusion as

to the relationship between ambient temperature and probability of failure. In
Figure 4.9 you can question the underlying data or debate the analysis, but you
cannot misconstrue the conclusion. Would you have made the decision to launch
based on Figure 4.9? How much of an impact could the proper creation of visible
knowledge have made to the decision to launch? Clearly, how you present visible
knowledge, and what data you present, makes a difference.
Leading the Change

The importance of leadership in instituting visible knowledge cannot be over-
stated. Someone has to go first. Leading the way can take many forms, from
individual commitment to adopt the techniques described in these chapters and
leading by example, to the head of an organization having the conviction to set
different expectations and lead their people in a new direction. In our experi-
ence, companies benefit the most from visible knowledge when they have a
leader with the conviction to lead through engaged involvement.
The degree to which visible knowledge becomes ingrained in day-to-day
work, whether individually or organization-wide, is predicated on the level of
conviction for those involved. One level of conviction is simply to try some of the
tools and techniques, such as those introduced in Chapters 1 and 2. As a man-
ager, it may be convenient to simply tell your people to “go try it” or “just do it.”
Certainly, if enough emphasis is placed behind the directive, the use of the tools
and techniques of visible knowledge will benefit the organization, especially

when it comes to the more straightforward diagrams, such as plotting failures on
two axes. However, the creation of deeper visible knowledge (e.g., to the degree
of understanding described in the tank example of Chapter 2) is hard work.
Developing systems to retain and reapply that knowledge is also hard work.
Getting to this deeper, more systemic level likely requires more than just encour-
agement or a directive. It will require adopting visible knowledge as a practice.
Visible knowledge as a practice means using and applying the concepts and
tools routinely during the development of new products; in other words, mov-
ing beyond a theory for someone to investigate the potential usefulness of the
tool or technique to a belief in the methods to such an extent that it becomes the
preferred approach to certain kinds of problems. If you are a senior leader in the
organization, you can play a crucial role in the shift from theory or experimenta-
tion to daily practice. That role takes on several distinct aspects.
The first and perhaps most critical thing a leader can do is to set an expecta-
tion that decisions be knowledge-driven. Insist on seeing trade-off curve sheets
behind key technical or marketing decisions. Drill down into the relationships
and trade-offs, seeking explanation, until you are satisfied that those who are
creating them understand them. Start praising people for the knowledge they
generate just as much, if not more so, as providing solutions.
The leader of a company that was very successful in adopting visible knowl-
edge as a practice, which drove tremendous improvement across the entire
business, took the position with his development group that, in his mind, the
knowledge doesn’t exist unless it is on a trade-off curve sheet. If someone in
his group approached him with a design proposal, he’d ask to see their trade-off
curve sheet; and if they did not have one, he’d send them away to create one
and come back with visible knowledge. In development team meetings, only
team members who brought trade-off curve sheets to share with the group got
the floor to present their ideas. Through these policies, the group quickly accli-
matized to new ways of working based on visible knowledge.
A second area that a leader plays an incredibly important role is in guiding
which trade-off curves to focus on for development. In a development challenge
of any reasonable size, the development team faces a seemingly infinite number
of potential trade-off curve possibilities; and it would be impossible to develop
all of them. An effective leader helps the organization focus on the most impor-
tant ones, and those are usually ones that help the team better understand what
their customers truly care about, and how design decisions affect those attributes.
Questions that help focus the team on priorities might be, “What do our custom-
ers care most about?” or “Why do our customers buy our products?” or “What are
the essential things our customers need/want from our product?” or “Under what
conditions must our product operate?” If the team has done a House of Quality
analysis or conducted a failure modes and effects analysis (FMEA), they can use
these great tools to help prioritize questions. With the answers to these questions,
the leader can then facilitate a discussion on what the group or broader organization
understands or does not understand about the physics or economics behind meet-
ing those key customer interests. Some have started referring to those areas where
we do not clearly know how certain parameters or ingredients affect the key cus-
tomer interest as knowledge gaps. Knowledge gaps concerning what customers care
most about, then, are the highest priority trade-off curves to develop.
Take golf clubs as an example. What do golfers really care about in a driver?
Do they care most about appearance or a nice color or that the company logo is
discrete? Do they care that the handle is comfortable and fits nicely in the hand,
or that it is made of leather versus synthetic material? Well, they might. But what
they really care about is that they can hit the ball far and straight. Those are
bragging rights on the golf course! Most golfers will pay more for an ugly golf
club if it enables them to hit 10 yards farther than anyone in their foursome. The
golf club company, Ping, realized this and decided to develop trade-off curves
around hitting distance and different club head design parameters. With this
knowledge, they increased the rate of new product introduction two-fold within
a few short years without adding resources.
The third action that a leader can take to help move visible knowledge into
daily practice is to create structure that supports the development of visible
knowledge. Engineers, in particular, tend to want to cover every possible aspect
and avenue in developing visible knowledge, and may want to develop a level of
precision in their analysis or testing that is unnecessary for the decision at hand,
and thus produce unnecessary additional cost and time delays. One technique is
to timebox the development of a given trade-off curve or set of curves. Once a
knowledge gap is identified and prioritized for trade-off curve development, then
give the responsible person or group a fixed amount of time (e.g., two weeks) to
generate data and close the gap. At the end of two weeks, the group agrees to
review the findings to determine whether the information is good enough or if
additional development is necessary.
To take the timeboxing idea a step further, the team can set up a cadence of
learning cycles where, on a regular interval (every two weeks, every month, etc.)
the team meets to review the knowledge gaps identified at the last meeting and
what has been done to close those gaps. They evaluate the visible knowledge
and determine whether the knowledge gap is satisfactorily closed. Once all of
the knowledge gaps from the previous meeting are reviewed, the question is
then asked, “What knowledge gaps do we still have, and which are most impor-
tant?” The team brainstorms the quickest, fastest, and easiest way to generate the
desired knowledge, then has until the next meeting to do it. This cadence contin-
ues until all known knowledge gaps are addressed to a satisfactory level.
Leaders often find that a visible knowledge approach to development requires
tweaks to the existing development system or process. Design review meetings,
particularly during the front end of development, may need to change format as just
explained in the previous paragraph. Milestones or checkpoints may need to be
modified to focus more on knowledge than on task completion. Groups may even
find that the expectations of certain checkpoints may need to change. For example,
a company that would normally expect to see detailed part drawings at preliminary
design approval may need to specify trade-off curve sheets instead of drawings, sav-
ing drawings for a later checkpoint. (If you are operating in a set-based or lean devel-
opment system, these will all naturally be a part of your proactive learning cycles
and integration events, and if not, then they will need to be created in your system.)
This brings us to a final critical role that a leader often needs to play to realize
visible knowledge as a practice—to protect the development group from other
parts of the organization. For example, consider a company that was conduct-
ing a controlled trial with visible knowledge in engineering. The trial involved
identifying and closing as many knowledge gaps as possible before committing
to prototypes or detailed drawings. It was not very long into the trial before the
engineering team started getting pressure from the marketing group. Marketing
was accustomed, under the old system, to having product renderings, part draw-
ings and rough prototypes by a certain stage. Meeting those dates was critical to
them because they wanted to have a prototype to show at a giant trade show a
few months down the line. Historically the engineering group was always late at
hitting these deadlines and often only pulled through at the very last minute. So
naturally the marketing group was pushing for even earlier delivery because of
the history of missing deadlines. Now they were hearing from engineering that
they wouldn’t have any drawings, much less early prototypes, at a point when
they would normally expect to have them (or at least a promise that they were
coming “soon”) under the old system. Needless to say, they were nervous and
spoke urgently about it with the CEO. So, the CEO found he needed to shield the
engineering group from this pressure to allow them to develop the visible knowl-
edge needed to make knowledge-driven decisions. Fortunately for the company,
he successfully protected the engineering group from such pressures allowing
them to conduct their trial. Not only did the engineering group deliver a proto-
type ahead of schedule, they did so faster than any other development project
of similar size in the company’s history because they developed the knowledge
first, then created the detailed design of the product. To add icing to the cake,
that product was a huge hit at the tradeshow, and became the company’s biggest
sales winner and most profitable product in the following year.
As the organization begins to rely on visible knowledge for decisions, there
will be a natural gravitation toward creation and use of visible knowledge,
and it will become the norm, an expected standard of behavior. Gradually, it
will become a value of the development system. The mindset and the attitude
become one where the creation of reusable knowledge is expected in the form
of visible knowledge.
When Allen Ward engaged with the Harley-Davidson Motor Company to help
them transition to lean product development, the principles he shared were a sig-
nificant departure from the traditional methods they employed at the time. Much
of what Allen proposed was not just foreign, but counterintuitive to what they
understood about product development. To build conviction, all the functional
leaders involved in product development dedicated a day with him to understand
the principles of development that he espoused. Following the day Allen spent
with the functional leaders, the president of the company, Jim McCaslin, dedi-
cated a day with him. Jim recognized the need to improve product development,
devoting the time to make sure he personally understood so he could have con-
viction for the effort. From that point forward, he was personally vested in the
effort. Jim pledged his commitment and support, but never told anyone what to
do or how to do it. As the president of the company, he clearly demonstrated his
conviction by asking questions; never in the form of a report, but rather personal
engagement in the work. His offer for help and support was always genuine,
never meddlesome, as was the case for all the senior leaders with conviction to
change. As the organization went through the necessary structural and cultural
changes, the functional leaders devoted one day every month to review and
ensure they were engaged with the effort. Over a three-year period the efforts
in lean product development yielded nearly a five-fold improvement in product
development.
In the case of the consumer products company behind some of the examples
in this chapter, to establish visible knowledge as a practice, the vice president
of research and development demonstrated his personal conviction by directly
engaging in the improvement efforts. Although he did not understand the details
of all the trade-off curve sheets in his department, he still took a personal inter-
est. After the initial efforts demonstrated the effectiveness of the tools and tech-
niques, he insisted on a one-week, dedicated training program for all of the key
personnel in his department. There were nearly 40 midlevel leaders whom he
took on a dedicated off-site excursion focused on learning the principles. He was
intimately engaged in the planning of the training effort and participated in every
aspect of the program. Following the training, he held people accountable to cre-
ate and share visible knowledge. Although he did not fully comprehend all of the
details, he consistently asked to see trade-off curves. Design reviews became far
more structured as they focused on the visible knowledge with critical questions
relating to the fundamental design decision process. Over an 18-month period,
this division reversed an annual 4% revenue decline to a 2% revenue growth.
One thread that runs through these examples and many others we could
cite: when someone demonstrates leadership and conviction, the results follow.
Whether it is an individual who adopts these techniques or the CEO of the com-
pany who shows conviction, improvement follows to the extent of their span of
control and sphere of influence.
The Journey Is Just Begun

Product development at most companies has gotten away from the deep level of
understanding visible knowledge elicits. Investing in the work necessary to build
deep understanding is often seen as too time consuming. The intense pressure
to deliver a rapid sequence of new products required by the business encourages
development teams to pick a solution quickly so the development process can

start, often with incorrect or partial knowledge. Developers are caught in the
never-ending cycle of fixing issues discovered late in development in order to
just get to launch. With so many resources consumed fixing immediate problems,
it is difficult to justify taking the time to do the hard work of creating visible
knowledge upfront—the very knowledge that could prevent the late discover-
ies and constant rework, and enable faster time to market more efficiently. It is a
vicious cycle, and difficult to break.
Breaking the cycle requires a vision for how things could be done differently
(and better), with the conviction to embark on a journey to build knowledge
to address the firefighting in development systems. As you build visible knowl-
edge, you will begin to see better ways to structure development systems and
processes, new and creative product solutions, and opportunities for personal
growth. You will find that knowledge created to address one issue can be reap-
plied on another problem elsewhere or in a future project. Each bit of visible
knowledge you create prevents late discoveries and frees resources to create
more visible knowledge—a virtuous cycle of improvement.
This book started as an effort to revive a work that Allen Ward had begun.
Based on the successes of companies using early manuscripts to initiate their
own journeys, we knew that the information and techniques he was developing
were an important contribution and valuable to share with the broader product
development community. Experience has demonstrated that visible knowledge
can be truly transformative in breaking the vicious cycle of firefighting and posi-
tively impacting innovation productivity.
Although our initial intent had been to simply polish and publish Allen’s origi-
nal work, as we got into the project, we realized that more work was required
if we wanted to do it justice. We felt compelled to build on Allen’s foundation
in creating a book that would effectively present his ideas and retain his origi-
nal intent of resurrecting a part of engineering and product development that
is so crucial. We hope that his work and our efforts open your eyes to a new
and exciting way to go about developing new products, and, at the same time,
provides concrete, practical methods and approaches to realizing that vision. We
trust that these ideas inspire you to try something new, to explore an art that,
to some extent, has been lost, regardless of your role in product development
or in your company. As we all progress in our journey to master our crafts and
improve what we do, we hope that the lessons in this book help you along your
journey.
That journey will be challenging. Treat this book as a starting point for learn-
ing effective ways to establish the mindset, build visible knowledge, and adjust
processes and functional roles within development teams in response. Along the
way, don’t be afraid to reach out to those who are farther along in the journey for
advice, guidance, and support. The most important thing is to begin, and once
you begin, to not give up. We wish you much success on your journey to trans-
form product development through visible knowledge.
Index
A Circumferential stress, 47, 48

Compression stress factor, 4
Absorber efficiency curve, 5 Compressive force vs. pipe diameter, 18, 19
Airfoil lift data, 10 Conventional design process, 65
American engineering managers, 62 development, 8–10
American Tag Company, 62 visible knowledge and, 8
Antiperspirant, 73 Countermeasures, 53–57
formulation, 80 Creation of visible knowledge, 63
trade-off curve, 81 causal diagram, see Causal diagram
Application of visible knowledge countermeasures, 53–57
building, see Building visible knowledge cylinder wall, finite element analysis of,
cross-functional collaboration, 82–87 47
leading change, 90–94 direct effect of, 23
mindset, establishing, 72–76 failure modes and effects analysis sheets,
presentation, 87–90 24
product development, 94 learning and thinking process, 53
one-page trade-off curve sheet, 25
B for pressure tank rupture, 40, 50, 51
pressure tank trade-off curve sheet, 44, 45,
Backfilling, 82
54–57
Bending moment, see Safe bending moment
rupture point vs. material strength, 52
Bending stress, 16
step-by-step process, 24
Building visible knowledge
stress and wall thickness, 41, 42
designed experiments, 79–82
tank pressure, 27–31, 43
leveraging existing data, 76–77
thin-walled cylinder, 46
seasoned employees experience, 77–79
wall thickness, 49
Cross-functional collaboration, 82–87
C Customer value curves, 7
Cantilever beam diagram, 6
Causal diagram D
with build process factors, 30, 37
causes and effect relationship, 34 Design-and-test methodology, 10
expanded, 35, 36 Design-Build-Fix iterations, 1
intermediate variables, 30 Designed experiments, building visible
for pressure tank rupture, 33, 35, 36 knowledge, 79–82
pressure tank trade-off curve sheet, 38 Detergent
step-by-step subprocedures, 32 high-efficiency washing machines, 77
Challenger space shuttle, 87–89 trade-off curves, 78
Cheaper pressure tanks, 27 Downtime trade-off curve, 85
97
98 ◾ Index
E M
Efficiency of visible knowledge, 14–21 Manufacturing companies
bending stress, 16 better, faster, cheaper, 69
safe bending moment, 17 conduct effective design reviews, 64
standard pipe sizes, 15 create visible knowledge, 63
Engine crank, 3 development process, 65–67
Engine crankpin, 2, 74 knowledge management organizations,
European Space Agency, 88 59–62
Exhaust system trade-off curve, 6 management roles and skills, 62–63
supplier relationships, changes in, 67–68
F test organization, 68–69
Market knowledge, 86
Failure modes and effects analysis (FMEA), 24, Metal inert gas (MIG) welding, 51
91 Microsoft Excel, 21
Fishbone diagrams, 31 MIG, see Metal inert gas
FMEA, see Failure modes and effects analysis Moment of inertia, 16
Functional knowledge, 86
N
G
NACA, see National Advisory Committee for
Generalized stress factor, 4, 74 Aeronautics
NASA, 88–89
H National Advisory Committee for Aeronautics
(NACA), 12, 13
Harley-Davidson Motor Company, 76, 93 Nominal rupture stress, 50–52
House of Quality analysis, 24, 91
O
I
One-to-one causal relationships, 79
Inertial stress factor, 4 Operational knowledge, 86
Intermediate variables, 30 Organization, of visible knowledge, 59–62
Ishikawa diagrams, 31, 34 O-ring failure data, 88–90
K P
Knowledge-based design process, 65 P-51 Mustang, 12, 13
Knowledge-based development process, 11 Presentation of visible knowledge, 87–90
Knowledge gaps, 92, 93 Pressure tank rupture
Knowledge management organizations, 59–62 causal diagram for, 33
directly controllable factors, 36
L expanded casual diagram for, 35
hypothetical historical, 50
Leadership strength and stress, 34
effective, 91 Project progress, 61
functional, 93–94 Prototype flyer, 10
in instituting visible knowledge, 90 Pump backfill slurry, 83, 84
knowledge gaps, 93
role of, 71 R
trade-off curve development, 92
LiveMath, 21 Rupture stress, 51, 52
Index ◾ 99
S trade-off curves, 12
visual knowledge, 2
Safe bending moment, 17, 18, 20 Trade-off curves, 7, 82, 87, 94
Shielded metal arc (SMA) welding, 51 antiperspirant, 81
Single variable, limit on, 5, 7 backfill rate, 85
SMA, see Shielded metal arc backfill time, 84
Stain removal causal diagram, 77, 78 candidates for, 41
Standard validation test, 69 creating, 86
Strain, Roark’s formula for, 16 detergent, 78
Stress one-page, 25
circumferential, 47 optimal flow rate, 86
circumferential and longitudinal, 48 pipe mass vs. pipe diameter, 19
and cylinder diameter, 43 pressure tank, 30, 31, 38, 39, 54–57
Roark’s formula for, 16
steel and PVC pipe, 6
and wall thickness, 41, 42 U
Supplier relationships, 67–68
Understand-the-limits-then-design process,
11
T
Tank pressure, 27–29 V
equations, 43
trade-off curve sheet, 30, 38, 54–57 Validation, design fails, 9
Test organization, 68–69 Visible knowledge, definition of, 2–4
Timebox technique, 92
Toyota, 21 W
counterparts, 14
crankpin failure, 3 Welding problems, 27
relationship Welding process, 37
changes in, 67 Wright brothers, 10–14
development project, 68

1138577537

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1138577537

Uploaded by

Copyright:

Available Formats

Visible Knowledge for

A PRODUC TIVIT Y PRESS BOOK

Visit the Taylor & Francis Web site at

and the Productivity Press site at

Foreword: How This Book Came to Be........................................................ vii

3 Visible Knowledge and Companies................................................... 59

Compounding the situation, Harley-Davidson had focused for several years

This book is for engineers, engineering managers, and development executives.

Allen C. Ward is considered by many as the patriarch of lean product

Dantar P. Oosterwal is a lean product development practitioner, advisor,

Durward K. Sobek II is a professor and program coordinator of Industrial and

How and Why to Use

What Is Visible Knowledge?

Figure 1.1 Engine crank.

vibrational and cannot be accurately predicted from equations or simulations. So,

Table 1.1 Engine Data Related to Crankpin Failure

Figure 1.2 Relationship of warranty cost to generalized stress value.

The Basic Concept

1. Assemble data about a set or family of products (or manufacturing pro-

Figure 1.3 Absorber efficiency curve.

Exhaust system family limits

Figure 1.4 Exhaust system trade-off curve.

Figure 1.5 Cantilever beam diagram.

Break or radius all edges at

Figure 1.7 Limit on a single variable.

Figure 1.8 Customer value curves with fuzzy limits.

◾◾ Represent the information visually.

How Visible Knowledge Changes the Development Process

1. They cannot promise to produce optimal designs.

To understand this, let’s examine the conventional development process, which

Research Advanced Analyze, simulate,

Figure 1.9 The conventional development process.

in a meeting or through a structured discussion which idea to pursue, and

tests may be physical, analytical, or computational. Design-and-test produces rela-

The Wright Brothers, “Understand Then Design,” and the P-51

Table 1.2 Sample of Airfoil Lift Data

User/market needs Safe

Figure 1.11 The knowledge-based development process.

Cost of evaluating an idea

Figure 1.12 Cost of evaluating an idea versus project time.

aeronautical engineers, however, brought visual knowledge to a peak of refine-

28 0 L.E. Rad.: 0.89 CL

Figure 1.14 P-51 Mustang fighter. (Courtesy of https://s-media-cache-ak0.pinimg.com

The Efficiency of Visible Knowledge

1.6 meters 0.5 meters

End view of saddle support enlarged

Figure 1.15 A simple crane.

Table 1.3 Schedule of Standard Pipe Sizes

Actual compressive force

Figure 1.18 Limit curves of compressive force versus pipe diameter.

Figure 1.19 Trade-off curves of pipe mass versus pipe diameter.

Now ask yourself these questions:

1. It allows engineers to understand how their systems behave under variation.

Overcoming the Objections

Objection 2: “This looks like a lot of work.”

How to Create Visible

As shown in Chapter 1, using visible knowledge can dramatically improve your

Choosing the Issues to Investigate

◾◾ Is important enough to justify the effort

How We’ll Approach the Problem

Issue statement: Characteristic curves:

Figure 2.1 One-page trade-off curve sheet.

Step 1: State the Issue