Product Development

Christopher
A. Mattson · Carl D. Sorensen
Product
Development
Principles and Tools for Creating Desirable and
Transferable Designs
Product Development
Christopher A. Mattson • Carl D. Sorensen
Product Development
Principles and Tools for Creating Desirable
and Transferable Designs
123
Christopher A. Mattson Carl D. Sorensen
Department of Mechanical Engineering Department of Mechanical Engineering
Brigham Young University Brigham Young University
Provo, UT, USA Provo, UT, USA
ISBN 978-3-030-14898-0 ISBN 978-3-030-14899-7 (eBook)

https://doi.org/10.1007/978-3-030-14899-7
© Springer Nature Switzerland AG 2020
This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part
of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or
information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar
methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this pub-
lication does not imply, even in the absence of a specific statement, that such names are exempt from
the relevant protective laws and regulations and therefore free for general use.
The publisher, the authors, and the editors are safe to assume that the advice and information in this
book are believed to be true and accurate at the date of publication. Neither the publisher nor the
authors or the editors give a warranty, expressed or implied, with respect to the material contained
herein or for any errors or omissions that may have been made. The publisher remains neutral with
regard to jurisdictional claims in published maps and institutional affiliations.
This Springer imprint is published by the registered company Springer Nature Switzerland AG.
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
Preface
In preparing to write this book, we reviewed copper smelter. Each of these projects
more than two hundred design-related requires a design process that is
textbooks. With all the existing books, why customized to the particular product being
did we decide to write this book? designed. Yet the existing textbooks give
little or no guidance as to how a process
In more than twenty years of teaching
might be customized. As experienced
engineering design classes, covering more
designers, we know how to customize the
than 700 industrially sponsored design
process. But our inexperienced students
projects with more than 4,500 students,
have yet to learn how to do this. Therefore,
we’ve come to believe that a book could be
when we talk about the generic design
written to better match the needs of both
process as a set of design activities that will
our student teams and practicing design
apply to a typical product, virtually every
professionals.
team can claim that traditional product
In reviewing the design textbooks that are development processes don’t apply to their
currently in print, we’ve identified three specific product.
broad classes of content: (1) the design
Furthermore, the idea of a design process
process; (2) design tools, methods, and
being fundamentally described by the
techniques; and (3) design-related topics
activities currently being pursued by the
such as patent law and ergonomics. The
design team doesn’t square with our
differences in the books are largely in the
experience in industry. When discussing
depth and breadth of each of these
product development projects, team
categories, although there are differences
members are not very likely to classify the
in presentation as well (e.g., the number
product by their actions. Rather, they tend
and detail of the examples or case studies
to describe the characteristics of the
that are used to teach the main topics).
product. We believe that describing the
The books are largely consistent in focusing
design process by the evolution of the
their discussions of the design process on
product is clearer, more easily understood,
the activities of the designers during
and more consistent with the way
different phases of the process.
experienced designers think about their
In our capstone class, each team has a work.
different project. Although all projects
A fundamental shift in this book, then, is
require engineering design, they vary
away from the focus on prescribing the
significantly in scope, expected results, and
work of the designer toward a focus on the
involved engineering disciplines. For
evolution of the product. This shift in focus
example, one year we had teams designing
is both challenging and liberating to the
vehicles, improving a potting process for
students (and by extension, to design
X-ray tubes, improving the packaging and
professionals). The challenge comes
distribution process for a nutritional
because we no longer prescribe actions;
supplement company, designing the
instead, we prescribe outcomes. The
next-generation extension ladder, and
student must determine the actions that
developing a plan to prevent the release of
will best lead to the desired outcome. For
visible water vapor from a cooling tower in a
v
vi PREFACE
an inexperienced designer, this can be the evolution of the design. We introduce

hard work, fraught with uncertainty. And design activities, outcomes, and the activity
yet, for all its difficulty, this work is innately maps that link them together. We describe
rewarding, as the student successfully the evolution of design information as it
wrestles with issues of real importance. applies to all product development projects.
We show the importance of coordinating
The liberation in the focus on product
the work of all team members and
evolution comes from the same source as
demonstrate how an activity map forms the
the challenge: we no longer prescribe
basis for customizing the development
actions. Students feel no pressure to follow
process to the needs of the team and the
a particular action because it is part of the
project. Finally, we discuss some personal
recommended process. Instead, they need
characteristics of designers that we have
only focus on actions that are appropriate
seen influence success.
for their particular design project. For the
industry professional, this book can serve We also include a case study of product
as a ”field guide” for product development. development. Through showing how a
It provides concise guidance about both team successfully dealt with the unique
the activities and the outcomes of product challenges of their assigned product
development. The book also presents development opportunities, we hope to give
effective development tools and techniques some concrete guidance and inspiration to
for the real world. those who are struggling with their own
project.
Having tested these principles in our senior
capstone design class, we have found that Part II of the book is a Product
they work. Students learn better, work Development Reference, a brief reference
better, and accomplish more when they to product development tools, methods,
focus on the evolution of their product and techniques. The Development
rather than an accounting of their activities. Reference is certainly not exhaustive, either
They are much more likely to consider in coverage or in depth. However, we have
instructor guidance as suggestions to help attempted to include a reference entry for
them reach their desired product each of the tools, methods, or techniques
evolutionary state. Furthermore, they that is mentioned elsewhere in the text.
appear to better understand and are
Only the first part of the book, the product
certainly better able to articulate the
development process, is intended to be
reasons why they are involved in a
read consecutively. The remaining parts
particular activity.
can be browsed through or
For the industry professional, this book can cross-referenced from Part I. We hope that
serve as a ”field guide” for product the book will be inviting to read, and
development. It provides concise guidance friendly to review, and that it will provide
about both the activities and the outcomes insight and inspiration not only during a
of product development. The book also classroom design experience, but
presents effective development tools and throughout a long and successful career in
techniques for the real world. engineering design.
Part I of this book covers the fundamentals We thank WHOlives.org for allowing us to
of the product development (or design) share the story of the Village Drill
process as we have come to understand it. (human-powered water well drill)
We introduce four principles that underlie development. They’ve helped improve the
product development, including the world not only by bringing clean water to
importance of demonstrated desirability more than a million people in Africa with
and transferability for product designs. We the Village Drill but also by providing an
explain how design skills are applied in an example of the application of the principles
incremental and iterative fashion to cause
PREFACE vii
in this book to help improve product book. Without her help, the book would be
development. far less readable.
We gratefully acknowledge Nichole Cross
for providing a style guide to achieve Provo, UT, USA Christopher A. Mattson
consistency in the figures and for her Carl D. Sorensen
capable creation of the illustrations in this August 2019
Contents
Preface v
Contents viii
List of Figures xii
List of Tables xv
I Product Development Process 1

1 Getting Started 3
1.1 On the Shelves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 What This Book Offers . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Four Principles of Product Development . . . . . . . . . . . . . . . . . 5
1.4 Moving Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Product Development Fundamentals 13

2.1 Designing the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Design Evolution and the STEP Cycle . . . . . . . . . . . . . . . . . . . 15
2.3 The Sequence of Design Activities and Outcomes . . . . . . . . . . . . 18
2.4 Coordination of Effort . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 Stages of Development . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6 Approval at Stage Completion . . . . . . . . . . . . . . . . . . . . . . . 27
2.7 Obtaining Design Approval . . . . . . . . . . . . . . . . . . . . . . . . 31
2.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.9 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 Design Skills 37
3.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2 Discovering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Creating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4 Representing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.7 Experimenting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.8 Evaluating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.9 Deciding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.10 Conveying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.11 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
viii
CONTENTS ix
4 Opportunity Development 49
4.1 Design Evolution During Opportunity Development . . . . . . . . . . . . 49
4.2 Example of Opportunity Development . . . . . . . . . . . . . . . . . . . 54
4.3 Top-Level Activity Map for Opportunity Development . . . . . . . . . . . 57
4.4 How to Gather and Process Essential Information . . . . . . . . . . . . 59
4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.6 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5 Concept Development 67
5.1 Design Evolution During Concept Development . . . . . . . . . . . . . . 67
5.2 Example of Concept Development . . . . . . . . . . . . . . . . . . . . 74
5.3 Top-Level Activity Map for Concept Development . . . . . . . . . . . . . 84
5.4 How to Develop a Strong Concept . . . . . . . . . . . . . . . . . . . . . 84
5.5 How to Generate Concepts . . . . . . . . . . . . . . . . . . . . . . . . 88
5.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.7 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6 Subsystem Engineering 95
6.1 Design Evolution During Subsystem Engineering . . . . . . . . . . . . . 95
6.2 Example of Subsystem Engineering . . . . . . . . . . . . . . . . . . . . 101
6.3 Top-Level Activity Map for Subsystem Engineering . . . . . . . . . . . . 103
6.4 How to Design a Vital Custom Component . . . . . . . . . . . . . . . . 111
6.5 How to Develop and Use Engineering Models . . . . . . . . . . . . . . 113
6.6 How to Develop and Use Prototypes . . . . . . . . . . . . . . . . . . . 118
6.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.8 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7 Product Refinement 123

7.1 System Refinement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.2 Producibility Refinement . . . . . . . . . . . . . . . . . . . . . . . . . 129
7.3 Post-release Refinement . . . . . . . . . . . . . . . . . . . . . . . . . 133
7.4 How to Release a Design . . . . . . . . . . . . . . . . . . . . . . . . . 136
7.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
7.6 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
8 Customizing the Product Development Process 141

8.1 Creating a Customized Project Plan . . . . . . . . . . . . . . . . . . . . 141
8.2 Evaluating the Quality of the Project Plan . . . . . . . . . . . . . . . . . 145
8.3 Using the Customized Project Plan . . . . . . . . . . . . . . . . . . . . 146
8.4 Human-Powered Drill Example . . . . . . . . . . . . . . . . . . . . . . 148
8.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
8.6 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
9 Seven Ways to Become a Better Designer 157

9.1 Expect Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
9.2 Be Mindful of the Design . . . . . . . . . . . . . . . . . . . . . . . . . 158
9.3 Be on the Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
9.4 Diverge Then Converge . . . . . . . . . . . . . . . . . . . . . . . . . . 159
9.5 Embrace Multifidelity Models and Prototypes . . . . . . . . . . . . . . . 159
9.6 Validate Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
9.7 Always Have a Back-Up Solution . . . . . . . . . . . . . . . . . . . . . 160
9.8 Beyond These Seven Suggestions . . . . . . . . . . . . . . . . . . . . 160
10 Conclusion 163
x CONTENTS
II Product Development Reference 165

11 Product Development Tools and Techniques 167
11.1 Basic Design Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
11.2 Benchmarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
11.3 Bill of Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
11.4 Bio-Inspired Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
11.5 Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
11.6 CAD Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
11.7 Catalog Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
11.8 Codes and Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
11.9 Concept Classification Tree . . . . . . . . . . . . . . . . . . . . . . . . 184
11.10 Controlled Convergence . . . . . . . . . . . . . . . . . . . . . . . . . . 186
11.11 Cost Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
11.12 Cost Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
11.13 Critical Path Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
11.14 Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
11.15 Delphi Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
11.16 Design for Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
11.17 Design for Manufacturing . . . . . . . . . . . . . . . . . . . . . . . . . 200
11.18 Design of Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
11.19 Design Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
11.20 Design Structure Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 206
11.21 Dimensional Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
11.22 Drawing Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
11.23 Drawings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
11.24 Engineering Change Order (ECO) . . . . . . . . . . . . . . . . . . . . . 214
11.25 Ergonomics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
11.26 Experimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
11.27 Failure Modes and Effects Analysis . . . . . . . . . . . . . . . . . . . . 220
11.28 Fault Tree Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
11.29 Financial Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
11.30 Finite Element Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . 226
11.31 Focus Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
11.32 Goal Pyramid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
11.33 Internet Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
11.34 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
11.35 Method 635 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
11.36 Mind Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
11.37 Multivoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
11.38 Nucor’s Circles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
11.39 Objective Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
11.40 Observational Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
11.41 One Pager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
11.42 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
11.43 Patent Searches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
11.44 Performance Measures . . . . . . . . . . . . . . . . . . . . . . . . . . 254
11.45 Personas and Locales . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
11.46 Plan Do Check Act (Shewhart Cycle) . . . . . . . . . . . . . . . . . . . 258
11.47 Planning Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
11.48 Product-Focused Requirement Statements . . . . . . . . . . . . . . . . 262
11.49 Project Objective Statement . . . . . . . . . . . . . . . . . . . . . . . . 264
11.50 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
11.51 Quality Function Deployment . . . . . . . . . . . . . . . . . . . . . . . 268
CONTENTS xi
11.52 Rapid Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

11.53 Recombination Table . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
11.54 Requirements Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . 274
11.55 Requirements Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
11.56 Revision Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
11.57 Robust Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
11.58 SCAMPER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
11.59 Scoring Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
11.60 Screening Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
11.61 Sensitivity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
11.62 Six Sigma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
11.63 Sketching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
11.64 Storyboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
11.65 Surveys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
11.66 Theory of Inventive Problem Solving (TRIZ) . . . . . . . . . . . . . . . . 300
11.67 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
11.68 Uncertainty Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
11.69 Value Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Appendix A Summary of Evolution in Product Development 309
Appendix B Human-Powered Water Well Drill 327

B.1 Case Study Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 327
B.2 Project Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
B.3 Main Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
B.4 The Team’s Final Design . . . . . . . . . . . . . . . . . . . . . . . . . 330
B.5 Exploratory Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
B.6 Team Conclusions and Recommendations . . . . . . . . . . . . . . . . 340
Appendix C Product Development Terminology 341
Bibliography 345
Index 347
List of Figures
1.1 Docking station for handheld computer . . . . . . . . . . . . . . . . . . . . 4

1.2 Principle 1: Product developers create a design . . . . . . . . . . . . . . . . 6
1.3 Principle 2: designs should be desirable and transferable . . . . . . . . . . 7
1.4 Principle 3: designs evolve as a result of design activities . . . . . . . . . . . 8
1.5 Principle 4: optimal evolution requires customization and coordination of ac-
tivities. Notice that this purposeful coordination of activities among the people
doing them leads to a valuable outcome. . . . . . . . . . . . . . . . . . . . 9
1.6 Principle 4: Coordination and customization of activities is essential . . . . . 10
2.1 Steps, paths, and milestones . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Design evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 The co-evolution of the requirements, tests, and the design . . . . . . . . . . 16
2.4 The STEP cycle: Shrink, Try, Evaluate, Preserve. . . . . . . . . . . . . . . . 17
2.5 Top-level activity map for developing initial requirements for a human-powered
water well drill for the developing world. . . . . . . . . . . . . . . . . . . . . 20
2.6 Activity map symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7 Independent activities and their activity map logic. . . . . . . . . . . . . . . 22
2.8 Dependent activities and their activity map logic. . . . . . . . . . . . . . . . 23
2.9 Activity map levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.10 Design changes during development . . . . . . . . . . . . . . . . . . . . . 26
2.11 A top-level activity map for the concept development stage . . . . . . . . . . 28
2.12 Evaluation of desirability and transferability during a development stage . . . 29
2.13 Activity map for obtaining approval . . . . . . . . . . . . . . . . . . . . . . . 32
4.1 A model of the near finished human-powered water well drill . . . . . . . . . 55

4.2 The system requirements matrix at the end of the opportunity development
stage for the human-powered water well drill. . . . . . . . . . . . . . . . . . 56
4.3 Top-level activity map for the opportunity development stage. . . . . . . . . . 58
5.1 Subsystem requirements from system performance measures . . . . . . . . 71

5.2 Early-stage concept sketches for human-powered water well drill. . . . . . . 73
5.3 Mid-stage concept renderings for human-powered water well drill. . . . . . . 75
5.4 Late-stage concept renderings for human-powered water well drill. . . . . . . 76
5.5 Drill schematic, as produced by the team at the end of concept development. 77
5.6 Interface matrix for drill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.7 Structural decomposition of the drill. . . . . . . . . . . . . . . . . . . . . . . 79
5.8 Subsystem requirements matrix for structure subsystem. . . . . . . . . . . . 80
5.9 Subsystem requirements matrix for wheel subsystem. . . . . . . . . . . . . . 81
5.10 Subsystem requirements matrix for wheel support subsystem. . . . . . . . . 82
5.11 Top-level activity map for the concept development stage. . . . . . . . . . . 83
5.12 Activity map for developing a strong concept . . . . . . . . . . . . . . . . . 86
xii
LIST OF FIGURES xiii
5.13 Factors determining solution set adequacy. . . . . . . . . . . . . . . . . . . 86

5.14 Concept classification tree for human-powered drill. . . . . . . . . . . . . . 87
5.15 Sample concept screening matrix for human-powered drill . . . . . . . . . . 89
6.1 Subsystem requirements matrix with measured values . . . . . . . . . . . . 102

6.2 The drill subsystems as they existed at the end of subsystem engineering.
a) drill string, b) hoist, c) wheel, d) wheel support, e) pump system. . . . . . 104
6.3 Engineering drawing of the kelly bar assembly. . . . . . . . . . . . . . . . . 105
6.4 Engineering drawing of the square tubing for the kelly bar. . . . . . . . . . . 106
6.5 Engineering drawing of inner pipe for the kelly bar. . . . . . . . . . . . . . . 107
6.6 Engineering drawing of end plate for the kelly bar. . . . . . . . . . . . . . . . 108
6.7 A representation of the 44 drawings created by the team, organized
by subsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.8 Top-level activity map for subsystem engineering . . . . . . . . . . . . . . . 110
6.9 Top-level activity map for engineering a single subsystem. This map will be
repeated for each subsystem. Included in this map are submaps dealing with
mundane off-the-shelf components, vital off-the-shelf components, mundane
custom components, and vital custom components. Note that a given sub-
system may have zero, one, or more than one of any or all of these kinds of
components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.10 Models of the mass distribution of a horse with various fidelities. . . . . . . . 114
6.11 Solution characteristics of model types. . . . . . . . . . . . . . . . . . . . . 115
6.12 Improvement of models with iteration . . . . . . . . . . . . . . . . . . . . . 117
7.1 Top-level activity map for system refinement. . . . . . . . . . . . . . . . . . 127

7.2 Acceptance test prototypes used during the system refinement stage of devel-
opment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
7.3 Top-level activity map for producibility refinement. . . . . . . . . . . . . . . 132
7.4 Small refinements made to the drill during the producibility refinement stage
of development. (a) Original handle, (b) refined simplified handle. . . . . . . 133
7.5 Top-level activity map for post-release refinement. . . . . . . . . . . . . . . . 136
7.6 The human-powered water well drill as placed on the market . . . . . . . . . 137
7.7 The lazy susan bearing interface between the wheel and the wheel support for
the human-powered water well drill. . . . . . . . . . . . . . . . . . . . . . . 137
7.8 Activity map for releasing a design . . . . . . . . . . . . . . . . . . . . . . . 138
8.1 Scoped Development for Human-Powered Water Well Drill. . . . . . . . . . . 143

8.2 Activity map with financial, human, and temporal resources added
to each activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
8.3 Customized activity map for human-powered drill . . . . . . . . . . . . . . . 151
8.4 Resource allocation to the human-powered drill project (opportunity
development stage only). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
9.1 Diverge then converge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
A.1 Evolution during product development . . . . . . . . . . . . . . . . . . . . . 310

A.2 The co-evolution of requirements, tests, and design . . . . . . . . . . . . . . 311
A.3 Evaluation of desirability and transferability during a development stage . . . 312
A.4 Top-level activity map for the opportunity development stage. . . . . . . . . . 315
A.5 Top-level activity map for the concept development stage. . . . . . . . . . . 317
A.6 Top-level activity map for the subsystem engineering stage. There is a great
deal of complexity not shown in this map related to the engineering of each
individual subsystem. Please refer to Figure A.7 for the detailed top-level map
for engineering a single subsystem. . . . . . . . . . . . . . . . . . . . . . . 319
xiv LIST OF FIGURES
A.7 Top-level activity map for engineering a single subsystem. This map will be
repeated for each subsystem. Included in this map are submaps dealing with
mundane off-the-shelf components, vital off-the-shelf components, mundane
custom components, and vital custom components. Note that a given sub-
system may have zero, one, or more than one of any or all of these kinds of
components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
A.8 Top-level activity map for system refinement. . . . . . . . . . . . . . . . . . 322
A.9 Top-level activity map for producibility refinement. . . . . . . . . . . . . . . 324
A.10 Top-level activity map for post-release refinement. . . . . . . . . . . . . . . . 326
B.1 The full system design being tested in Tanzania. . . . . . . . . . . . . . . . 328

B.2 Requirements matrix (reduced) for drill. . . . . . . . . . . . . . . . . . . . . 331
B.3 CAD rendering of team’s final design. This represents the design at the end of
the system refinement stage of product development. . . . . . . . . . . . . . 332
B.4 Slip plate close up photo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
B.5 Pump power requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . 336
B.6 Field tests of drill system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
B.7 Photo used as evidence that the drill was capable of cutting rocks. . . . . . . 338
B.8 Photo used as evidence that the slurry was capable of lifting the cuttings out
of the borehole. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
List of Tables
2.1 Overview of desirability and transferability testing . . . . . . . . . . . . . . . . 30
3.1 Typical evaluation activities used in various development stages. . . . . . . . . 42

3.2 Motivations for decision making . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1 Summary of the opportunity development stage. . . . . . . . . . . . . . . . . 50

4.2 Guidelines for writing effective product-focused requirement statements . . . 63
5.1 Summary of the concept development stage. . . . . . . . . . . . . . . . . . . 68

5.2 A sample of the interface definition for the drill. . . . . . . . . . . . . . . . . . 79
5.3 Typical creation activities used in various development stages. . . . . . . . . . 91
6.1 Summary of the subsystem engineering stage. . . . . . . . . . . . . . . . . . 96

6.2 Predicted and measured values for structure subsystem. . . . . . . . . . . . 109
6.3 General characteristics of engineering models and their solutions . . . . . . . 115
6.4 Purposes for prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.1 Summary of the system refinement stage. . . . . . . . . . . . . . . . . . . . 124

7.2 Predicted and measured values for human-powered drill. . . . . . . . . . . . 128
7.3 Evaluation of market requirements by market representatives. . . . . . . . . . 130
7.4 Summary of the producibility refinement stage. . . . . . . . . . . . . . . . . . 131
7.5 Summary of the post-release refinement stage. . . . . . . . . . . . . . . . . . 134
8.1 Development milestones for the human-powered water well drill project. . . . 149
8.2 Specific end-of-stage outcomes for human-powered drill. . . . . . . . . . . . 150
8.3 Development schedule for the human-powered drill (opportunity development
stage only). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
A.1 Overview of desirability and transferability testing . . . . . . . . . . . . . . . . 313

A.2 Summary of the opportunity development stage. . . . . . . . . . . . . . . . . 314
A.3 Summary of the concept development stage. . . . . . . . . . . . . . . . . . . 316
A.4 Summary of the subsystem engineering stage. . . . . . . . . . . . . . . . . . 318
A.5 Summary of the system refinement stage. . . . . . . . . . . . . . . . . . . . 321
A.6 Summary of the producibility refinement stage. . . . . . . . . . . . . . . . . . 323
A.7 Summary of the post-release refinement stage. . . . . . . . . . . . . . . . . . 325
xv
Part I
Product Development Process
1
CHAPTER 1
Getting Started
1.1 On the Shelves the production line weeks earlier in China.

But when I saw it in that store — away from
I’ll never forget the first time I saw my desk, away from the computer models,
something I designed on the shelves of a and away from the to-do lists — I began to
store1 . It was a simple docking station for a see the big picture. My understanding of
handheld computer (Fig. 1.1). When I saw product development began to mushroom,
it, I picked it up and marveled at every as did my love for it. I could see then, with
piece of plastic, every screw, and every better clarity than before, the importance of
layer of plating on each of the precisely the seemingly endless number of decisions
formed electrical contacts. It was one of that went into designing the product. I
those rare and embarrassing moments could see the many people who were
where I’m sure I heard dramatic music involved in its development; what they
from a movie soundtrack playing in the worked on versus what I worked on and
background. To say I was proud about how we often helped each other out in
what was on that shelf would be a huge various ways. I could see that the product
understatement. had evolved little-by-little — and not in a
haphazard way — from a simple idea to a
Certainly no one else paused to admire the manufactured product that people could
product’s finer details, nor did anyone buy now buy at stores.
the product because of the plastic wall
thickness, or the screw diameters, or *****
because of the plating on the contacts. But It would be misleading to imply that I had
somehow — and not by chance — all of always had a good relationship with the
those things (and many, many more) docking station. The truth is that it caused
worked together to form a product that was a significant amount of stress for me and
desirable enough for people to want to buy, others on the development team.
and so desirable that we ended up selling
over 12 million of them. I had been working for the company as an
engineering intern for about two years
It was not the first time I had seen the when I was assigned the project. Until that
product — that very one in the store could point, I had spent most of my time
have been one of hundreds I saw come off troubleshooting problems and developing
reliable test methods for other products. To
1 my boss, perhaps this new assignment was
This is Chris’s personal experience.
© Springer Nature Switzerland AG 2020 3

C. A. Mattson, C. D. Sorensen, Product Development,
https://doi.org/10.1007/978-3-030-14899-7_1
4 CHAPTER 1. GETTING STARTED
Figure 1.1:
Docking station
for handheld
computer.
no different. The docking station was in the successful product, they also led to the
very early stages of product development, creation of this book, which is designed to
and despite the best of efforts, the docking help anyone who is in the same or similar
station’s most critical component — the situation — charged with the task to
custom electrical connector system — was develop a product, but not quite sure how
not looking promising. My job was to fix the to do it, or how to do it well.
situation and get a working design ready for
What ultimately sprang from that study and
production.
from the development of many products
Things were urgent, as they often are, and (including the docking station) was simple,
within hours my boss and I were on a plane but very powerful — it was an
headed to work in the Taiwanese office, understanding of what happens to the
where some of the other team members design during product development and
were based. what the team does to cause the
development to happen.
I’ll be honest; as a good engineer, I could
analyze many things. But I had no clue
how to create something from scratch. I 1.2 What This Book Offers
knew basically nothing about product
development — and it scared me. This book offers precisely what I needed —
and in the format I needed it — while on
In an attempt to remedy this, I studied a that plane to Taiwan. It describes what
textbook on product development for the happens to a design as it evolves through
entire flight to Taiwan. Although that book distinct stages of development from a
did not solve my problem, I was able to simple idea to a product on the shelves.
extract what I absolutely needed to get Importantly, it will help you understand
started on developing this product. The what stage of development your product is
things I walked away with from that study currently in, and what you and your team
not only gave me the much-needed need to do to advance it to the next stage.
confidence that ultimately led to a In other words, it describes how to design a
1.3. FOUR PRINCIPLES OF PRODUCT DEVELOPMENT 5
product from scratch — and not just any provide you a place to be introduced to a
product, but a product the market loves. particular design action, method, or tool
that will be of immediate help.
While it would have been valuable for me to
have this book while designing the docking
station, it is equally valuable for the design 1.3 Four Principles of Product
of any engineered product. How do I
know? Because Carl and I specifically
Development
created this book to be universal after we The concepts, methods, and discussion
had observed, interviewed, taught, presented in this book assume that you
coached, and/or participated on hundreds understand the Basic Design Process (as
of product development teams. And we described in the Development Reference:
verified the universality of the book by Basic Design Process (11.1)).
testing it on dozens of development teams Furthermore, all of the content in this book
in many settings. is based on four principles that define the
context for product development. While
The Layout simple and logical, these principles and
We’ve created the book in two parts — their deeper meaning are rarely understood
Part I: Product Development Process, and by those just starting with product
Part II: Product Development Reference. development. A solid understanding of
them can help you avoid wasting product
Part I discusses the process of product development time, and can help you avoid
development. Specifically it focuses on the frustration.
stages of product development and how to
manage individual and team efforts during Principle 1: The job of the product
those stages so that it results in a product development team is to create a design
the market really wants. that is desirable and transferable
Part II is an alphabetized reference that
The job of the product development team is
introduces standalone actions, methods,
to create a design (a clear and complete
and tools that have the potential to help the
definition of the product), while the job of
product development team advance the
the production system is to use that design
design. We present them in a
to manufacture the product in quantities
reference-book style because they are often
consistent with the market demand.
used throughout product development and
are not structurally tied to any one chapter Recognizing this subtle distinction
in Part I. Throughout the book, Part II is between jobs will help you focus on
referred to as the Product Development what you’re expected to create as a product
Reference or the Development Reference. development team, and to know how your
work will be judged. It will help put into
Part I also includes a summary of key
perspective the critical — yet transitionary
product development information
— role that prototypes play in advancing the
(page 309), a detailed case study
design from one state to the next, and help
(page 327), and a glossary of product
you avoid the common trap of believing
development terms (page 341). Generally,
that your only job is to produce a prototype.
it’s worth giving Part I and the appendices a
full read, while following citations to the To be successful, the product development
Product Development Reference when team will need to create a design that is
you’re unfamiliar with a particular action, both desirable and transferable. This
method, or tool, or when you simply want to principle is represented by Figure 1.2.
understand our perspective on it. The goal of desirability assumes that for a
Because the Development Reference product to succeed in the marketplace, it
provides the necessary details to carry out must be desirable, meaning that the target
product development, we anticipate that it market wants the product enough to
will be turned to as needed and that it will purchase it. A desirable product results
ket
mar
the
to
le
irab
s
De THE MARKET
e to the prod
sferabl ucti
Tran on
sys
DETAILED tem
DESIGN
PRODUCT DEVELOPMENT TEAM

THE PRODUCTION SYSTEM
Figure 1.2: Principle 1: the job of the product development team is to create a design that is both desirable and trans-
ferable. Notice that the job of the production system is to produce the product according to that design.
when a high-quality production system design that is both clear and complete. A
manufactures the product according to a design is clear if it is unambiguous,
desirable design. meaning that no judgment is required to
interpret what is meant by the design. A
The goal of transferability is that the design
design is complete if all important aspects
be transferable, meaning that anyone
of the product are included in the design. If
producing the product in accordance with
the design is clear and complete, it is
the design will create a product that
impossible for a production system to
matches the intent of the development
create a product that is simultaneously
team in all important ways. To do this, the
consistent with the design and inconsistent
production system needs to receive a
with the intent of the development team.
Increasing Level of Detail / Production Readiness
Visual
Description
Revision 1
Idea Verbal Revision 9
Description
Figure 1.3: Principle 2: The design must evolve, gradually becoming better, more mature, and until it contains all the
necessary information for the production system to manufacture the product and test its quality. Representative stages
of evolution shown here include the idea, a verbal description, a sketch, and multiple revisions of the formal technical
definition. There are many intermediate stages that could be shown.
The desirability and transferability of the complete, transferable definition of the

design should be regularly evaluated during product).
the product development process to ensure
the process is on track. Understanding the principle that designs
evolve can help you avoid frustration when
Throughout this book we focus on the a desirable design does not appear all at
importance of desirability and transferability once. It will help you plan for the desirable
because when designs are both desirable and transferable design to emerge
and transferable, the resulting products gradually as a result of hard work and
succeed in the market. iteration. Importantly, this principle helps
you recognize that in the end, the design
will need to have evolved to the point that it
Principle 2: The design must evolve, includes all the necessary information for
gradually becoming better, more mature, the production system to manufacture the
and until it contains all the necessary product and test its quality. Without this,
information for the production system to the product development effort is
manufacture the product and test its incomplete and requires additional work.
quality
Principle 3: The product development
Designs evolve little-by-little from an team causes design evolution through
embryonic state to a completely defined design activities that result in artifacts
state during the product development
process. The principle of evolution is The gradual and consistent evolution that
illustrated in Figure 1.3. In fact, the occurs during the product development
successful evolution of a design is the sole process only happens as a result of actions
purpose of product development. taken by the product development team.
Importantly, the evolution of the design has This is represented in Figure 1.4. The
been successful when it results in a evolution is often a result of iteration —
desirable and transferable design. As such meaning as a result of repeating some
the design evolves in two important ways; it product development activities as a means
becomes better (more desirable) and it to get closer and closer to a desirable
becomes more detailed (a clearer, more design.
Sketch
Brainstorm
Te
st
Prototype
A B
Product Development Activities Evolving Design
Figure 1.4: Principle 3: the product development team causes design evolution through design activities that result in
artifacts.
And not just any actions result in desired As we seek to evolve the design, we will
evolution. In order to cause the design to carry out many product development
evolve, the transferable representation of activities (Principle 3). Those activities
the design must change. We refer to must be chosen and coordinated for the
elements of this transferable representation purpose of converging (Principle 2) on a
as product development artifacts. Product design the market finds desirable, and the
development artifacts move the design out production system finds transferable
of a designer’s head and into a tangible (Principle 1). Figure 1.5 is an illustration of
form that is transferable. Hence, evolution Principle 4, showing a generic set of design
requires activities that result in artifacts. activities coordinated amongst the people
doing them. These activities are arranged
Understanding this principle is both purposefully, leading to a tested design.
empowering and frightening, as it indicates Without purposeful coordination, the
that the product development team is free actions of multiple people can easily cause
to choose what it should do to cause waste, duplication, and delay as shown in
evolution, but it also indicates that those Figure 1.6.
choices will either make or break the
product. Because every product is different, and
every client has their own needs, and
The bulk of this book is about the stages because every product development team
through which a design passes while it is has its own strengths and weaknesses, the
evolving, and about the activities the product development activities that should
product development team must do in be chosen, and the way they should be
order to move the design through the coordinated (or sequenced) will be different
stages of development. in each case. For this reason, product
development will be most effective and
most efficient when it is customized to the
Principle 4: Optimal evolution requires unique characteristics of the product,
customization and coordination of client, and team.
activities
Customizing product development in this
The product development process is most way is not as daunting as it sounds. A
efficient and effective when the product major goal of this book is to equip you with
development activities are coordinated and the information and tools necessary to
customized to the unique conditions of the customize product development to any
product, the client, and the team. setting you find yourself in. As we’ve
Modeling Prototyping
Experiment Component 1 Evaluate
Solution 1
Engage Component 2
Stakeholders
Brainstorm
Set of
Under- Candidate Design
standing Solutions Tested
Sketch Prototyping Design
of needs Component 2
Modeling Experiment
Solution 2
Observe Evaluate
End Users Component 1
Figure 1.5: Principle 4: optimal evolution requires customization and coordination of activities. Notice that this purposeful
coordination of activities among the people doing them leads to a valuable outcome.
observed designers acquire this skill, we’ve How about evolution? That’s Principle 2.
seen less floundering and less frustration. The excitement I felt seeing the docking
We have also seen industry recognize this station on the shelves was in large part
as one of the designer’s most valuable skills because I had nurtured the design through
and hire them because of it. There is a various stages of development as it evolved
marked difference between a designer who into the final product. I remember planning
can only follow a prescribed process, and to solve the entire problem in just a few
one who can prescribe the process best days while in Taiwan! I hadn’t yet learned or
suited to the unique setting of his or her accepted that great designs only emerge
development team. after a lot of iteration.
***** In fact, we did hundreds of product

development activities aimed at creating
Everything in this book builds on these four and verifying desirability (such as
principles. They are the starting point for systematically dropping dozens of docking
everything we’ll discuss. Keep an eye out stations from 6 feet onto concrete floors to
for them while you go through the book. identify weak points). That’s Principle 3.
Sometimes they’ll be stated explicitly, and We also did many activities centered on
other times they’ll be quietly at the root of transferability. Not only did our product
the subject. development team release (transfer) the
design to our own production system, we
Looking back now — at that moment in the also released it to our client’s
store when I saw the docking station for second-source; this was an important and
sale — it’s clear to me that the four welcomed part of our responsibility to
principles discussed above are a protect the client against the risks
fundamental part of that story. associated with single sourcing.
I stood there — in that store — holding a As simple as the docking station seems,
product that people were buying; not one I there was a sizable team that developed it.
manufactured, but one that our product That team involved people of various
development team fully defined so that it disciplines, and companies higher up and
could be manufactured by a production lower down in the supply chain. I learned a
system! That’s Principle 1. lot about project coordination, not because
DESIGN
Figure 1.6: For real products, there are so many individuals and activities involved in the product development effort
where coordination is required to avoid waste, duplication, and delay.
I did it, but because I saw great people made easier when you use the principles
organize the team and through that taught in this book to cut out the waste and
organization accomplish very difficult avoid the pitfalls that are easy to walk into
things. Those accomplishments are proof while developing a product.
of Principle 4.
1.5 Exercises
1.4 Moving Forward Test Your Knowledge
By this point in the book we hope you can T1-1 Describe the two main parts of this
see that we intend to help you create a book.
design that can be used by a production
system to manufacture a product in T1-2 List the four principles of product
quantities ranging from one to millions. Our development.
focus, however, will not be on just any
T1-3 List the two main attributes of a
design — but instead on a desirable and
design that should be regularly
transferable design. Creating such a design
evaluated during the product
will not happen overnight, but it will happen
development process.
little-by-little as you and your team carefully
choose, coordinate, and customize your
actions. Causing this evolution to happen is Apply Your Understanding
not easy — it wasn’t for me and my team
as we worked on the docking station, and it A1-1 For a specific product development
won’t be for you and your team — but it is project with which you are
incredibly rewarding and it is certainly acquainted, describe how each of the
1.5. EXERCISES 11
four principles of product

development apply or do not apply to
that project.
A1-2 Describe what might happen during
the product development process if a
development team believes that their
job is to produce a product — as
opposed to creating a design.
A1-3 Write some personal goals for a
project you are working on now that
might help you stay focused on your
job to create a desirable and
transferable design.
A1-4 Consider the deeper meaning of
Principle 1. Can someone from the
production system be on the product
development team? Why would this
be or not be a good idea?
A1-5 How can desirability and
transferability be specifically defined
for your development project?
A1-6 In what ways do you believe iteration
can help you during the product
development process?
A1-7 Where can you find out more about
the stages through which a design
will pass as it evolves?
A1-8 What does it mean to coordinate and
customize product development
activities? How is coordination
different in an individual setting
versus a team setting?
A1-9 What do you most want to remember
from this chapter?
CHAPTER 2
Product Development Fundamentals
2.1 Designing the Process that is desirable and transferable, and the
non-obvious one, which is the opportunity
One of the first things to know about to choose the product development
product development is that there are activities that work best for us, for our
countless ways to do it, and what’s even product, and for our client.
more interesting is that there are multiple
right ways to do it. This means we’ll not only choose the shape
and material for a product (among other
To understand this better, consider how things), but we’ll also choose the activities
many products have been developed in the we will do to efficiently and effectively
past 150 years (this number is enormous). identify the best shape and best material
Now imagine the designers of all those for the product. These two opportunities
products, and the things they did to have always been and will always be a part
develop their product. Do you suppose of what it means to be a designer and to
they all did the same things, or followed the develop a product.
same process? Or even that the successful
products followed one process, and the In a way, this can be compared to a journey
failed products followed another? from one point on a terrain to another, by
foot (Figure 2.1). Not only does the person
While it would be romantic for this to be traversing the terrain take the physical
true (not to mention extremely convenient), steps to get from the start to the finish, but
it unfortunately is not. There is no universal she also plots the course, sets the speed,
process for product development, no plans the places to stop and rest along the
universal set of steps that apply to all way, and makes judgments about when to
settings, and there is no universal recipe of check the map and reorient. Just like the
ingredients and quantities that can simply designer, she also has two great
be followed to get a design that is both opportunities: to plan the journey and to
desirable and transferable. take the journey.
But don’t let this discourage you. There is *****
actually something quite beautiful about it;
something that gives our profession a Our goal with this chapter is to help you
deeper meaning. It is that we, as designers, understand fundamental aspects of
have two great opportunities in front of us; product development that are common to
the obvious one, which is to create a design successful development, and to describe

https://doi.org/10.1007/978-3-030-14899-7_2
14 CHAPTER 2. PRODUCT DEVELOPMENT FUNDAMENTALS
Figure 2.1:
Steps, paths,
and milestones
to the hiker are
like iteration,
sequences of
activities, and
stages of prod-
uct development
to the designer.
them in a way that will allow you to see unconscious. As we’ll describe in this
them as building blocks for constructing chapter, to the designer these repetitive
the product development process you’ll footsteps are similar to the STEP cycle that
follow as you develop your product. will be used to evolve the design. Like
footsteps, the STEP cycle is the main
By the time you finish this chapter you engine of progress. The cycle is introduced
should be familiar with three things. (1) the in Section 2.2.
STEP cycle, (2) the activity map (sequence
of design outcomes and activities), and (3) Paths — The hiker won’t walk in a random
the stages of product development. These unplanned way. She’ll choose a general
three things, in this order, represent an path from one point to another, then walk
increasingly wider view of what happens her way closer and closer to the goal. For
during product development. When you the designer, the path is the sequence of
understand them and how they work design activities that will be executed as a
together in harmony, you’ll be in a position way to evolve the design. Just as the hiker’s
to make the most of your time, and avoid path will be accomplished step-by-step, the
wandering aimlessly. designer will rely heavily on the STEP cycle
To put these three things into perspective, while carrying out a sequence of design
let’s again consider the hiker: activities. This is described in Sections 2.3
and 2.4.
Footsteps — During her journey, individual
footsteps will take her from the starting Milestones — The journey will be long, so
point to the ending point. There will be she’ll need to rest, reorient, and re-plan
thousands of them and once she is throughout the trek. She chooses
comfortable with the gear, these stepss will milestones along the way to do this; scale
become mostly automatic and that peak on the left, camp in that valley
2.2. DESIGN EVOLUTION AND THE STEP CYCLE 15
Increasing Detail
1) Requirements for achieving A.

1) Requirements for achieving A.
-Be Happy
-Be Happy
-Don’t Procrastinate
REQUIREMENTS
-Don’t Procrastinate
-Work with your team
-Work with your team
2) Requirements for achieving B.
2) Requirements for achieving B.
-Utilize your advisors.

-Utilize your advisors.
3) Requirements for achieving C. 3) Requirements for achieving C.
-Address root cause -Address root cause
-Communicate your success -Communicate your success
TESTS
MODELS &
PROTOTYPES
DESIGN
A B
Sufficient Details to
Release to Production
Figure 2.2: Design evolution during product development. The design evolves from an idea to a desirable, transferable
design sufficient for use by the production system to manufacture the product. Along with the design, requirements
and tests also evolve. Models and prototypes will be used with the tests to determine how well the design meets the
requirements.
straight ahead, climb the peak on right, transferable to the production system that
and so on. In this way, her difficult journey will make it. The design must evolve into a
is divided into smaller, more manageable clear and complete (fully detailed)
pieces with specific subgoals. To the definition of a desirable product if the
designer, passing milestones is like product is to be successful.
completing stages of product development.
We elaborate on these stages and how to Along with the design, requirements and
benefit from them in Sections 2.5, 2.6, tests will also evolve during product
and 2.7. development. Requirements clarify what is
needed in order for the design to be
desirable. Tests clarify how the
2.2 Design Evolution and the performance of the design will be predicted
STEP Cycle and measured so its desirability can be
evaluated by the development team.
Before a product can be manufactured and Without clear requirement and test
show up on the shelves of a store, its information, the desirability of the product
design must evolve (Figure 2.2). To be cannot be evaluated until it is actually
clear, the design is the deliberate definition placed on the market.
of the product. In its initial form as an idea,
the hope for a product exists in the mind of Prototypes and models play a central role
the designer, but this hope is not yet in product development because they
Initial Revised Second Final

REQUIREMENTS Requirements Requirements Requirements Requirements
Initial Revised Final

TESTS Tests Tests Tests
MODELS & First Models Second Models

PROTOTYPES & Prototypes & Prototypes

DESIGN Design Design Design
Figure 2.3: The co-evolution of the requirements, the tests, and the design as aided by prototypes and models. Proto-
types and models are created as a snapshot consistent with the current design and tested to measure and predict the
performance of the design to compare with the requirements.
represent the current design and are used evolution. Design evolution is iterative
to test how well it meets the requirements. because basic design actions will often be
repeated again and again to cause the next
Figure 2.2 shows the evolution of the
discrete evolutionary increment to be
requirements, tests, and design. As
achieved.
depicted, it appears as if the evolution is
consistent, easy, and smooth, much like Computer scientist Frederick Brooks
driving on an interstate highway. In reality, (2010) describes the incremental and
design evolution is more like driving on iterative nature of design well with a
surface streets — intermittent, difficult, and personal story:
messy.
As a student I spent one summer working
Clearly, we would all like to create the at a large missile company.... After a couple
perfect design right from the start, but of weeks, I had a working [prototype of a
data management system]. I proudly
experience has shown us that this is presented [it] to my client. “That’s fine—it
impossible. Instead, we create a design is what I asked for—but could you change it
that is the best we can do, then identify the so that...?” Each morning for the next few
weaknesses in our work, and refine the weeks, I presented my client with [an
improved prototype], revised yet again to
design. It’s important to recognize that we’ll accommodate the previous day’s request.
do this many times before the design is Each morning he studied the [prototype]
ready to be used to manufacture the and asked for yet another revision.... For a
product. In this way, design evolution is while, this frustrated me sorely: “Why can’t
he make up his mind as to what he wants?
both incremental and iterative. Why can’t he tell me all at once, instead of
one bit a day?” Then, slowly, I came to
It is incremental because design evolution realize that the most useful service I was
occurs in discrete increments — not all at performing for my client was helping him
once. These increments are often relatively decide what he really wanted.
small changes to the design that can seem
almost insignificant. But the cumulative Was Brooks part of an iterative process, or
effect of these increments is significant was the previous day’s work simply undone
2.2. DESIGN EVOLUTION AND THE STEP CYCLE 17
PRESERVE Figure 2.4:

SHRINK the outcome The STEP cy-
your focus cle: Shrink,
Try, Evaluate,
Preserve.
TRY
potential solutions
EVALUATE
solution suitability
each day by an indecisive client? Unless evolved to a point of sufficient desirability

we pay close attention to what’s happening and transferability.
in this story, it’s easy to believe that the
incremental process was ineffective and Understanding this co-evolution makes it
inefficient, when in reality it was a healthy easier to avoid the frustration initially felt by
part of the evolutionary process. What Brooks, and helps the team see the value
Brooks experienced — the co-evolution of — even the essential role — of iteration
the requirements and the design — is a during product development.
common and welcomed part of the product
development process. The STEP Cycle
Incremental and iterative design evolution
The client in Brooks’s story provided insight is facilitated through an informal iterative
that allowed Brooks to add to his pattern of action we call the STEP cycle.
understanding of the requirements, thus This basic four-part pattern, shown in
allowing him to improve the design Figure 2.4, underlies most of what is done
day-by-day. The frequency of Brooks’s during product development. Like the
interaction with his client was a large hiker’s footsteps, this cycle is the main
contributor to the success of this engine of progress. Its four parts are:
interaction.
The way in which the requirements, the 1. Shrink

tests, and the design evolve together during Shrink your focus to a manageable
product development is illustrated in piece of the large problem. We do this
Figure 2.3. As shown, the initial for the simple purpose of making the
requirements guide both the creation of the large problem solvable. Just like the
initial design and the establishment of the hiker’s footsteps, our large journey is
initial tests. The first prototypes and models divided into multiple achievable
are then made according to the initial pieces. The Decomposition entry in
design and are tested according to the the Development Reference:
initial tests. Decomposition (11.14) can help you
develop your ability to do this
The results of these tests will likely lead to effectively.
revised requirements and tests, and will
almost always lead to a revised design. The 2. Try
revised design is then used when creating In the second part of the cycle, we
a second set of prototypes and models, consider possible solutions and
which upon testing is likely to kickstart tentatively choose one that we hope
another design iteration. This iterative solves the smaller more manageable
process continues until the design has piece. This may require various design
skills (described more fully in evolution that occurs when executing a

Chapter 3). During this part of the sequence of design activities is more
cycle, we think about how the chosen significant. It is the difference between a
solution does or would work. hiker completing a single step and the
hiker completing segments of a path that
3. Evaluate required numerous steps.
In this part, we evaluate how well the
chosen solution solves the manageable In this section we discuss the activities and
piece of the larger problem. Based on outcomes that are present in product
the evaluation, we decide whether to development and how to sequence them.
Try additional solutions (in hopes of We’ll also introduce a visual representation
finding something better), or to of the sequence called an activity map.
Preserve the chosen solution by
adding it to the design. In rare
Activities and Outcomes
instances, a third alternative may be
chosen: to abandon this STEP and Design activities and outcomes are
move in a different direction entirely. intimately connected, and either can be
4. Preserve considered primary. That is, we can say
that design evolution occurs through a set
When a tentative solution has been of intentional activities whose results are
evaluated and found worth keeping, outcomes. In this statement, the activities
the work is preserved by formally are the essential elements of development,
making the solution part of the design. with the outcomes being ancillary results of
To preserve the work, the design must the activities.
be changed to reflect the outcome.
Alternatively, we can say that design
For most designers, this pattern of thinking evolution consists of achieving a desired set
(or some representation of it) permeates of outcomes. In this view, the outcomes are
everything they do. For them, the pattern the essential elements of development, with
has been practiced enough, with enough the ancillary activities being used to create
success, that it becomes a natural and the outcomes.
often unconscious way of operating. This is
much like the hiker, whose individual Both views can lead to successful product
footsteps are natural and unconscious, and development. Both views can be found in
in succession take her to her intended common project scheduling theory and
destination. tools. The selected viewpoint is largely a
matter of personal choice.
2.3 The Sequence of Design In this book, we choose to consider the

outcomes as the primary elements in
Activities and Outcomes product evolution. This is because the
By themselves, the hiker’s footsteps are not completion of a stage of development
enough. She must first point herself in the depends on the availability of certain
right direction and chart a path to follow transferable product development
before her steps will lead to progress. artifacts1 , rather than the completion of
certain activities.
It’s no different for the designer whose
iterative (step-wise) efforts will have no In addition, there may be multiple ways of
meaning without a charted path to follow. achieving a particular outcome. When such
To the designer, the path ahead is defined is the case, we believe it is better to specify
by the design activities that will be carried the outcome and provide the development
out to cause the design to evolve.
1
Product development artifacts are objects made
Compared to the relatively small-scale by the product development team; examples include
evolution caused by the STEP cycle, the sketches, test reports, requirements tables, and so on.
2.3. THE SEQUENCE OF DESIGN ACTIVITIES AND OUTCOMES 19
team the flexibility to choose the activities Activity maps use nodes to represent
they will use to achieve the outcome. design outcomes, arrows to represent
design activities, and double-headed
Thus, we recommend that product
arrows to represent interdependent
evolution focus on artifacts that are
relationships, as shown in Figure 2.6. In
transferable representations of design
activity maps, the symbols are arranged to
outcomes. Such artifacts can be used both
show the logical sequencing of activities
to evaluate the current state of evolution
and outcomes.
and to support future evolution. These
artifacts are more useful when they are Arrows leaving a node indicate that the
concrete, specific, and unambiguous. activity cannot be started until the outcome
represented by the node is available.
When an outcome is captured in a product
Arrows pointing to a node indicate that the
development artifact, good design practice
activity represented by the arrow is
requires critical review of these artifacts.
necessary to create the outcome
The team must assess the quality of the
represented by the node.
design decisions made, and should iterate
through the activity until the outcome is Multiple activities can depend on a single
demonstrated to be desirable. The process outcome, and multiple activities can be
of creating artifacts and critically evaluating required to achieve an outcome. But each
their quality is essential to high-quality activity on the map leads to one and only
product development. one outcome.
Multiple outcomes can be combined into a
Activity Maps compound outcome as shown in
Whether explicit or not, every project has Figure 2.6. When multiple outcomes are
an underlying network of design outcomes needed as input for a design activity, it is
that defines the relationship between convenient and clear to represent them as
multiple design outcomes and the design a single compound outcome.
activities that lead to them. We call these To more fully understand this, consider
activity maps. Figure 2.5. Looking at only the two leftmost
Activity maps indicate the relationships arrows, we can see that Outcome 1 is
between design activities and outcomes, achieved as a result of interviewing the
whether they be independent, dependent, client and that creating and revising the
or interdependent. These relationships project objective statement cannot begin
help the team decide the order in which until the client interview is complete. The
outcomes should be pursued and Project Objective Statement (Outcome 2)
consequently choose the order of design results from the activity “Craft and revise
activities. This important information project objective statement.”
dictates, to a large degree, how the efforts Once Outcome 2 is achieved, the activities
of the different people on the product of interviewing well drillers, searching the
development team should be coordinated. internet, and benchmarking competitive
When considered in a detailed (low-level) products can begin in any order or
way, activity maps are different for every simultaneously. The outcome of each of
project. When considered at a less detailed these activities (3, 4, and 5) is shown as
level, activity maps are similar or identical being interdependent on the outcomes of
from project to project. the others. This is represented by the
dashed arrows in the figure. What this
An activity map is a good way to visualize the means is that the interviews with the well
structure of activities and outcomes during driller will influence what internet research
product devlopment. A fairly high-level to do and vice versa. In such cases it is
activity map for developing the requirements likely that multiple interviews or multiple
for a human-powered water well drill internet searches will need to be completed
for the developing world (see AppendixB) before a mutually acceptable outcome is
is provided in Figure 2.5 as an example. achieved for both activities. The interviews
Interview well 3
drillers
Craft and revise Search internet

project for drilling
objective technology
statement 2 information Discuss/brainstorm/establish
Team and requirements based on
Interview client
project 1 interviews, internet, and
assignment benchmarking data
Benchmark 4 7
competitive
products
6
5
OUTCOMES
1 Understanding of client wishes 4 Internet research summary 6 Market research summary
2 Project objective statement 5 Benchmarking summary 7 Initial requirements for drill
3 Well driller interview summary
Figure 2.5: Top-level activity map for developing initial requirements for a human-powered water well drill for the devel-
oping world.
1
“Discuss/brainstorm/establish
3 requirements” depends on all three prior
2 activities.
Outcome Compound outcome *****

While developing your product, you will
encounter times when the amount and
Design activity (consumes time and resources)
diversity of activities that needs to be done
will be significant. At those moments it can
be quite useful to map out the relationship
between key outcomes and activities. Even
Interdependent relationship
when this is done in an informal way (with a
(consumes no time or resources) pencil and scratch paper), it will help you
clearly identify the most critical things to
focus on.
Figure 2.6: Activity map symbols. The compound
Outcome 3 is achieved by having both Outcomes It is equally important to know, however,
1 and 2. that you won’t need to map out everything.
There may be times when an explicit
and the internet research are also activity map won’t help you accomplish
influenced by benchmarking competitive your goal any more efficiently or effectively.
products. All three of these activities are Judging when and when not to use an
interdependent. As discussed shortly, activity map is exemplified by the hiker who
interdependent activities require careful does not chart a detailed path across a
coordination. meadow, but finds she must before
scrambling up a rock face. Just like her,
Importantly, establishing requirements can you’ll need a mapping when the stakes are
only begin once the compound Outcome 6 high and the way forward requires careful
has been completed. This means that treading.
2.4. COORDINATION OF EFFORT 21
Nevertheless, whether it is explicitly drawn maximum benefit, the efforts of all

or not, there is an activity map that individuals must be coordinated to best
describes your work. meet the needs of the product. With poor
coordination, effort will be duplicated and
To help you through those moments where
time will be wasted. In this section we
explicitly mapping out the path is
discuss the impact of the three
beneficial, let us add some formality to the
dependency relationships (independent,
above discussions. Design activities and
dependent, and interdependent) on project
outcomes have one of only three possible
coordination.
relationships with each other: an
independent relationship, a dependent
relationship, or an interdependent Coordinating Independent Activities
relationship. These relationships are shown Independent activities should be carried
as activity maps and are described in out in parallel whenever possible to reduce
Figures 2.7 and 2.8. the overall product development time.
Because the activities and their outcomes
Independent Activities are independent, there are no logic-related
barriers to parallelizing them.
Independent activities have no impact or
influence on each other. In relation to each
other, it does not matter which design Coordinating Dependent Activities
activity is accomplished first. Dependent activities must be carried out in
series. The critical path, or the set of
Dependent Activities activities that determines the overall
product development time, will involve
Dependent activities must be carried out in
multiple dependent activities (See Critical
series, as shown in Figure 2.8. The
Path Analysis (11.13) of the Development
defining characteristic of dependent
Reference). To that end, the product
activities is that the outcome of one is the
development team should pay close
starting point to another activity.
attention to dependent activities and make
sure their progress is well-tracked since
Interdependent Activities failure to successfully complete them
The last way that multiple design activities affects downstream product development
can be arranged is also shown in efforts. Whenever it is possible to decouple
Figure 2.8. Interdependence is indicated dependent activities and make them
by the dashed arrow. Here, the preliminary independent, it is generally worth doing.
outcome of one activity affects another
parallel activity. One characteristic of these Coordinating Interdependent Activities
interdependent activities is that they can be
Interdependent activities require the most
serialized and either activity could be
coordination, since the outcome of one
carried out first. Once serialized, however,
activity affects another parallel activity. By
the activity executed first may be
their nature, they will need to be carried out
re-executed based on new information
in parallel. However, the outcome of any
gained in the second activity. This process
one of the parallel activities cannot be
can (and should) be repeated until a
finalized until the outcomes of all the other
mutually acceptable outcome for both
parallel activities are shown to be
activities is converged upon. Activity maps
satisfactory. Individuals or subteams
don’t explicitly show open-ended iteration,
working on interdependent activities need
but wherever there are interdependent
to plan on having a structured scheme for
activities iteration will likely be required.
collaboration. Perhaps the easiest way to
do this is for the team to establish a short
2.4 Coordination of Effort interval between subteam coordination,
where the interval is no longer than the
Virtually every product development effort amount of lost time the subteams are
includes more than one person. For willing to live with.
ACTIVITY ACTIVITY MAP OUTCOME

RELATIONSHIPS STRUCTURE RELATIONSHIPS
A 1, 3 independent
A and B are 1 2
2, 4 independent
independent 2 dependent on 1
B
3 4 4 dependent on 3
2
A and B are 2, 3 independent
A
independent 2 dependent on 1 (via A)
1 3 dependent on 1 (via B)
B
1
A and B are A 1, 2 independent
independent 3 dependent on 1 (via A)
3 3 dependent on 2 (via B)
Figure 2.7: Independent activities and their activity map logic.
Activity maps and other coordination tools detail in order to be successful or to

can be constructed with various levels of facilitate coordination between product
detail, as shown in Figure 2.9. At the development team members. At their
highest possible level, the product greatest level of detail, each activity map is
development process can be described unique and can ultimately be used to
with a single outcome and a single activity. create a custom project plan for a specific
While this very high level of detail is not project. Creating customized project plans
useful, it’s worth noting that this activity is discussed in Chapter 8.
map applies to all manufactured products,
and that this is the only activity map that Importantly, you’ll need to ask yourself how
applies to all manufactured products. much detail is enough to facilitate
coordination among product development
Every level of increasing detail represents a team members? To help answer that
narrowing of that map’s applicability to question for your particular situation,
other products. For example, at the second consider these principles:
level down (as shown in the figure), we find
a generic set of activities that can be used
to develop an engineered and • The activity map does not equal
manufactured product. Most of the generic coordination; it is only a tool to
product development processes in the facilitate good coordination. Therefore,
engineering literature exist at this level of the activity map alone serves no
abstraction. purpose until it is used by the team.
While some, both experienced and novice, • A person working alone (perhaps on
will find this minimal level of detail an independent activity) need not
insightful, others need a greater level of decompose that activity into
2.4. COORDINATION OF EFFORT 23
ACTIVITY ACTIVITY MAP OUTCOME

RELATIONSHIPS STRUCTURE RELATIONSHIPS
B dependent on A A B 3 dependent on 2 (via B)

1 2 3
2 dependent on 1 (via A)
B dependent on A A B 3 dependent on 2 (via B)

1 2 3
7 dependent on 6
D dependent on A and C (or 2 and 5) via D
5 dependent on 4 (via C)
D
6 7
C
4 5
C
C dependent on A and B 2 4
A 3 dependent on 1 (via B)
D dependent on A and B 2 and 3 dependent on each other
(no activity, interdependent,
A and B must be 1 iteration likely)
4 dependent on 2 (via C)
coordinated because B
5 dependent on 3 (via D)
2 and 3 are
interdependent D
3 5
C dependent on A and B A 6 dependent on 5 (via C)

1 2
5 is composed of 2 and 4
A and B must be 2 dependent on 1 (via A)
coordinated because 2 4 dependent on 3 (via B)
and 4 are interdependent C 2 and 4 are interdependent
5 6
B
3 4
Figure 2.8: Dependent activities and their activity map logic.

Develop product
Final design for release to production
Solve problems Solve problems

Articulate Develop Engineer emerging during emerging during trial
objectives concept subsystems integration test production runs
1 2 3 4 5
OUTCOMES
1 Approved objectives & requirements 3 Approved design 5 Approved design for release
to production system
2 Approved concept 4
Select concept
4
Brainstorm Multiv ts 3
1 ncep
ote Rate co
2
OUTCOMES
1 Candidate set of concepts with 3 Rated set of feasible concepts 4 Selected concept
appropriate novelty, variety,
quantity and quality.
2 Reduced set of feasible concepts
Figure 2.9: Activity map levels. The top map shows the highest level process, while the bottom map shows the lowest
level outcomes and activities. Intermediate maps show intermediate levels of detail.
2.5. STAGES OF DEVELOPMENT 25
sub-activities to facilitate coordination. For all manufactured engineered products

Such a designer may, however, find comprising more than one part, there are
decomposition to be a valuable way to six stages of product development. The six
divide a complex task into simpler stages are shown in Figure 2.10. They are:
dependent tasks.
• Most product development teams have 1. Opportunity development
a coordination interval of sorts, which
represents how often the team meets. 2. Concept development
Activities done by an individual alone
can be decomposed to the level of one 3. Subsystem engineering
activity per coordination interval.
Activities done by subteams can be 4. System refinement
further decomposed into activities that
can be done by an individual within 5. Producibility refinement
the coordination interval for the
subteam (which will be shorter than 6. Post-release refinement
the interval for the team as a whole).
The stages of product development are

2.5 Stages of Development fundamentally stages of design evolution,
where each stage is named for the primary
Up to this point in the chapter we have focus of the evolution during that stage. For
discussed two main concepts: small-scale example, during the subsystem engineering
evolution, and medium-scale evolution. We stage, the focus is on creating a
spoke of small-scale evolution when we transferable definition that has been
introduced the STEP cycle and compared it demonstrated to be desirable for each
to footsteps in a journey across a terrain. engineered subsystem.
We spoke of medium-scale evolution when
we introduced design activities and activity While the design evolves through the stages
maps and compared them to segments of a of development, two other things are
path, which require multiple footsteps to evolving simultaneously and in an
traverse. interrelated way. They are the requirements
and the tests, which are employed as a way
We now discuss evolution on a large scale of verifying whether or not the current
by introducing the stages of product design is desirable. Figure 2.10 illustrates
development and comparing them to the this.
major milestones in a large journey.
Prototypes and models play a significant
Designs generally evolve through distinct role in helping the team evolve a
stages of development, where each stage high-quality design. As shown in
has clearly defined characteristics. Figure 2.10, prototypes and models are
Throughout each stage, the design is constructed based on the current design,
evaluated to determine how well it is and are used in tests to estimate how well
evolving. Each stage culminates in an the product will meet the requirements.
approval that allows the next stage to begin Note that for visual simplicity, we have
with minimal risk. Understanding these shown only one model and prototype icon
stages will help you establish an overall per stage. But any number of prototypes
project goal for a specific project, help you and models can (and probably should) be
define the starting and ending points for created for each stage of development.
the project, and give you a sense for how
resources will need to come together to When the design has evolved to the point
evolve the design through the pertinent that it has been demonstrated to meet the
stages of product development. purpose for the stage, approval is obtained.
Increasing Detail
OPPORTUNITY CONCEPT SUBSYSTEM SYSTEM PRODUCIBILITY POST-RELEASE

DEVELOPMENT DEVELOPMENT ENGINEERING REFINEMENT REFINEMENT REFINEMENT
REQUIREMENTS
TESTS
MODELS &
PROTOTYPES
DESIGN
A B
Figure 2.10: The requirements, tests, and design all evolve through the stages of product development; the design is
eventually released to the production system for manufacturing. Prototypes and models are instantaneous representations
of the design that are used in tests to determine predicted and measured performance that can be compared to the
requirements.
The approvers generally include the client2 producibility refinement stage, the design
as well as people from the development defines a product that is market-ready. This
team’s organization that are external to the is when the design is released to a
team. production system for mass production.
There are two subtle, but important, things
Note that at the end of the third stage, every to glean from Figure 2.10. The first is that
aspect of the product has been engineered. the six stages of development are — in
However, this does not mean that the reality, not just in the figure — generally
engineering on the product is complete. It sequential. We describe them as
continues in the last three stages to refine sequential because it is highly desirable,
the design as the product moves closer to and quite possible, that the design
(and beyond) release to the production continuously evolves to higher and higher
system. Also note that at the end of the states of definition and desirability. Careful
transition between stages ensures this.
2
The client is the person or organization that pro- While these transitions are discussed in
vides the resources for completing the development more detail in Section 2.6, it is sufficient for
project and therefore has a significant stake in the out-
come. Clients are rarely part of the development team.
the present discussion to say that the
But when they are, the approval needs to be an external completion of each stage consists of
action to maintain objectivity. obtaining approval of the design. Once a
2.6. APPROVAL AT STAGE COMPLETION 27
design has been approved as having product development is not trivial nor easy.
completed a stage, it is undesirable to have The activities and outcomes that need to be
the design regress to a previously accomplished, and their coordination, take
completed stage. Such devolution, as it a significant amount of work. If thoughtfully
were, is costly and emotionally painful for coordinated, however, the product
the product development team. development journey can be smoother,
resulting in a more enriching experience for
The second subtlety to glean from the development team and a better product
Figure 2.10 is the controlled overlap of for the client.
adjacent stages of development. The
chevron shapes shown at the top of the While it might be interesting to visualize the
figure are used to convey this. While there whole activity map for product development
are legitimate reasons to carry out two (meaning maps from all stages of
adjacent stages of development development together), this map would be
concurrently — such as to keep the too complicated to show on a single page.
development team actively evolving the For this reason, we break the process down
design while the approvers are evaluating into manageable stages and discuss each
the design at the end of a stage — it is in detail (Chapters 4–7) and provide activity
essential to recognize that there is risk in maps on a stage-by-stage basis. This
the overlap. approach has the advantage of allowing the
team to focus on one stage at a time.
What is the risk? The risk is wasted
development effort. Consider, for example,
the overlap that may exist at the end of the
concept development stage and the
2.6 Approval at Stage
beginning of the subsystem engineering Completion
stage. If a team decides to begin
engineering parts (which is fundamentally To reduce the risk of wasted effort during
part of the subsystem engineering stage) product development, the design’s
before a final concept has been approved desirability and transferability should be
(which is fundamentally part of the concept formally evaluated and approved at the end
development stage), the team risks wasting of each stage of development. This section
resources used to engineer subsystems describes the kinds of tests required for
that may never be used. Clearly, the risk of approval.
wasted development should be minimized,
but minimizing risk must be balanced Approval is generally based on the
against other pertinent concerns facing the successful completion of (i) artifact checks,
team. (ii) performance tests, and (iii) validation
tests. The relationship between these is
illustrated in Figure 2.12.
Activity Maps for Product Development
In Chapters 4–7 we present top-level Artifact checks are performed to ensure
activity maps for each stage of product that the requirements, the tests, and the
development. To effectively manage the design — as captured in transferable
product development project, however, artifacts — are clear and complete, and
customized more detailed maps will need match the product development team’s
to be created by the team for each stage of intent. Artifact checks should be performed
development. Nevertheless, the top-level by a member of the development team
maps provided are helpful starting points other than the person who created the
for each stage. artifact. To avoid mistakes, a formal
process for checking product development
Figure 2.11 shows a top-level activity map artifacts should be implemented and
for the concept development stage. Even followed. The design should be checked to
though this map is for a single stage – and see if any information is missing or any
is only top-level in detail – it shows that ambiguities exist.
From
models, prototypes
Opportunity 12 Compare
Development performance to
requirements
7 9
13 14
Create
candidate
solution set 10 16
8 11
1 Predict/measure 15 Select
performance concept
team
Create supports
Create needed Create needed
needed test models 23 Formalize
prototypes preliminary
Reduce to procedures epts
tractable conc 22 cost models
concept set 24
6 Formalize
predicted Formalize
performance preliminary
Combine/improve Select concepts technical
concepts worth testing models
Make
2 4
tradeoffs and
30 choose target
5 25 values
Seek 18
Rate concepts based approval
on requirements, 31 21 Formalize
feasibility, resources, 29 preliminary
schedule BOM
3 27
26 19 17
Formalize
geometric
33
Develop
32 opportunity and
approval 28 target values for 20 Choose subsystems
information each subsystem for parallel
engineering
To Subsystem
Engineering
Establish interface
requirements and
responsibility
OUTCOMES
1 Candidate solution set 12 23 Preliminary cost models
2 Tractable concept set 13 Reliable/trusted results 24 Preliminary models
3 Concept ratings 14 Concept evaluations 25 Predicted performance of concept

4 Improved concept set
15 26 Target values for system performance
5 Set of rated concepts
16 Evaluated concept set 27 Subsystem requirements
6 Reduced concept set (for test)
17 Final concept 28
Test procedures needed for evaluating
7
concepts
18 Preliminary BOM 29 Requirements
8 Prototypes needed for evaluating concepts
19 30 Necessary information for approval
9 Models needed for evaluating concepts
20 Subsystem list and interface matrix 31 Stage approval
10 Testing essentials
21 Design 32
11 Predicted and/or measured performance
22 Preliminary technical models 33 Approved concept
Figure 2.11: A top-level activity map for the concept development stage. The top-level maps for each stage of development
are shown in Chapters 4–7. The overall map for product development could be created by combining the individual maps
for each stage sequentially, but this map would be too complicated to show on a single page.
2.6. APPROVAL AT STAGE COMPLETION 29
REQUIREMENTS
Assess Assess Assess
Predicted Measured Market
Values Values Response
TESTS
Performance Predicted Measured Market Validation
Testing Values Values Response Testing
Testing T
Testing Validation
Models Prototypes Prototypes
DESIGN
Artifact Checking Team Intent

Complete, Clear,
Follows Standards
Figure 2.12: Evaluation of desirability and transferability testing during a development stage. This shows the relationship
between artifact checks, performance tests, and validation tests. The design is checked for quality and completeness.
Using prototypes and models based on the design, product performance is measured or predicted using the tests. Val-
idation testing consists of having a market representative evaluate a prototype and pass judgment on the quality of the
design. For approval, all required information should be present, the predicted and/or measured performance should
meet the ideal or target values, and the market response should demonstrate that the market requirements are met.
A two-level artifact check should be applied create measured values. Before final
during the checking process. First, the approval of a stage, the predicted and/or
design should be reviewed to determine measured values must meet or exceed all
whether someone trained in the art (but not the acceptable limits, and as many of the
the specific product) could reproduce the target values as possible. Acceptable limits
product from the design without any and target values are part of the
outside help. Second, the design should be requirements as discussed in Chapter 4.
reviewed to determine whether any
Performance tests are carried out by
loopholes exist in the design that could
members of the product development
allow a low-quality product to be
team.
manufactured.
Validation tests are managed by the
Performance tests are carried out to product development team, using market
determine predicted and/or measured representatives3 to provide the evaluation.
values of the requirements. Models and/or 3
A market representative is someone or some group
prototypes are made from the current of people chosen to represent the market. A representa-
design and evaluated using the current test tive can be thought of as a customer, an end user, etc.
procedures. Performance tests on models Because validation is fundamentally about outside ap-
create predicted values; tests on prototypes proval, it is important that the market representatives be
chosen from outside the product development team.
Table 2.1: Overview of desirability and transferability testing. This table summarizes the artifact checks, performance
tests, and validation tests that are performed during each stage of product development.
Artifact Checks Performance Tests Validation Tests

Test Check the quality and Use models and prototypes Have the market
objective: completeness of the design, based on the design to representatives evaluate
requirements, and tests. predict and measure the design artifacts to evaluate
Ensure that these fully and performance of the design the quality of the design from
unambiguously capture what according to the tests. the market perspective.
the team intended. Compare the predicted and
measured performance with
the requirements.
Artifacts Transferable medium Models or prototypes based Prototypes that communicate

used in appropriate for on the design; standard test appropriately to the market
testing: communicating the design methods that govern testing representatives; standard
(e.g., written list, technical test methods that govern
drawing, bill of materials, test validation tests
report, requirements matrix)
Artifacts Formal approval of the Test reports indicating the Test reports indicating the
created artifacts checked; usually results of applying tests to results of validation tests;
during includes release of a given models and prototypes; market response values (in a
testing: revision predicted and/or measured requirements matrix, for
values (in a requirements example)
matrix, for example)
Who is Evaluation performed by Evaluation performed by Evaluation coordinated by

involved: member(s) of the product product development team development team and
development team, performed by market
excluding the person who representatives
created the artifact
Validation tests require prototypes that can Table 2.1 summarizes the nature of artifact
be evaluated by the market representative. checks, performance tests, and validation
The goal of validation tests is to determine tests.
whether the product as designed will satisfy When seeking approval, the test results
the market. Because the team is not the must be clearly conveyed to the project
market, this judgment must not be made approvers. This is rarely trivial since the
by the team. approvers are generally not part of the
product development team and may be
This notion is captured in Figure 2.12, from diverse disciplines such as marketing,
where the market requirements are shown engineering, production, sales, support,
to be validated principally against the service, and finance. Approval is not
validation prototype, not the design. Such complete until all project approvers have
validation is essential, for it is not possible approved the design.
that the product development team can
know all the intentions of the market. For A top-level summary of the process of
this reason, the market representative obtaining approval is provided in
becomes an essential part of the validation Section 2.7.
tests.
2.8. SUMMARY 31
2.7 Obtaining Design Approval The results obtained from testing are
recorded in transferable form as part of the
Design approval must be obtained at the test information. The performance test
end of each stage. However, partial design results must also be checked as part of the
approval may be obtained at intermediate product develpment artifacts, and should
points in each stage, whenever an be assigned a date and a revision number.
important piece of the design is complete.
Conceptually, obtaining design approval is Evaluate Test Results
relatively straightforward — simply The results obtained from performance
demonstrate to the project approvers that testing are compared with the
all of the required elements of the design requirements. An evaluation is made as to
meet the requirements. However, because how well the predicted or measured
the requirements and the design are performance matches the desired values.
co-evolving, and because the choice of This evaluation is recorded in a transferable
which tests to carry out significantly affects artifact that will be reviewed by the project
the approval, the activity map is somewhat approvers.
complex.
Starting with the requirements, tests, and Perform Validation Testing
design that are up for approval, Figure 2.13 The validation prototypes are shared with
shows a general activity map for obtaining the market representatives and the
approval. The activities shown in the map assessment of the market representatives
include the following items. concerning the desirability of the product is
obtained.
Check Product Development Artifacts
The first activities in obtaining approval are Convey Results for Approval
checking of the requirements, tests, and The checked design, the evaluation of the
design. The product development artifacts performance testing, and the market
should be formally checked to ensure they validation results are conveyed to the
meet appropriate standards for the current project approvers for approval. The
stage of development, as summarized in approvers review the items conveyed and
Chapters 4–7. When artifacts have passed make a decision whether or not to approve.
the check, it’s conventional and wise for If approval is granted, the design is
them to be annotated with a date and the approved and the team moves fully into the
checker’s name or initials. next stage of development. If not, changes
are made to the design to resolve
Prepare Test Models and Prototypes weaknesses, and any necessary steps to
obtain approval are repeated.
When the design has passed the checks,
the artifacts to be used for testing are
prepared. These include models and 2.8 Summary
prototypes. Each of these artifacts should
be based on the design that has passed the This chapter has focused on the concept of
checks. The specific artifacts to be created design evolution – the incremental and
are determined by the performance tests iterative transition from a product idea to a
and the validation requirements. manufactured product on the shelves of a
store. We discussed that transition on three
Test the Performance scales, and compared it to a journey by foot
over terrain.
The prototypes and models are tested
according to the checked test methods. It The smallest scale, which was compared to
is important to follow these methods to footsteps, is the STEP cycle. This cycle
obtain repeatable and consistent results. underlies everything that is done during
4 11
Check 9
requirements Assess measured
and predicted
16
Test models and performance
prototypes to
determine
1 performance Seek approval for
12 design
15
5 10
Check tests
7
2
14
Create
performance
testing models
and prototypes Assess market
response
Perform validation
testing with market
representatives
Check design 8
3
13
6
Create validation
testing prototypes
OUTCOMES
Necessary requirements for stage approval Performance testing models/prototypes Assessment of predicted and measured
1 7 12 values
2 Necessary tests for stage approval 8 Validation testing prototypes 13 Market response to design
3 Necessary design for stage approval 9 Predicted and measured performance Assessment of market response
14
4 Checked requirements 10 Test methods, prototypes, models
15 Overall design assessment
5 Checked tests Required, measured, and predicted

11 performance values 16 Approved design
6 Checked design
Figure 2.13: Generic activity map for obtaining approval for a design.
product development; it is the main engine can be greatly facilitated through the
of evolutionary progress. While it may help construction of activity maps.
to think about the four parts of the cycle
explicitly — especially as you train yourself The largest scale discussed in this chapter
in its use — those steps are mostly was compared to major milestone in the
executed in a natural and informal way, just journey. These were described as the
as the hiker’s footsteps are natural and stages of product development. Because it
informal. can be so easy for a product development
team to get off course, it’s essential to
The middle scale was compared to evaluate the development progress at major
segments of a chosen path over the terrain. milestones, and make course corrections
To the designer, these segments are activity before continuing on. The stages presented
maps. There are times during product in this chapter exist for all manufactured
development when the activity map is and engineered products. For this reason,
simple, and others when it is complex. it’s extremely valuable to understand the
Charting a path through those complexities characteristics of those stages since we’ll
2.9. EXERCISES 33
face them again and again throughout our T2-7 For stages where performance can
careers. be predicted or measured, what level
of performance is needed to achieve
A good portion of this book is dedicated to approval?
characterizing the stages of development
and providing you with a top-level activity T2-8 What is a market representative?
map for evolving the design through each
stage. We recognize, however, that Apply Your Understanding
lower-level activity maps (the level at which
day-to-day work is actually done) cannot be A2-1 In your own words, why is design
generically specified for all products. evolution largely iterative and
Therefore the opportunity to plan the incremental?
journey is also yours. Chapter 8 is
dedicated fully to helping you do this for A2-2 Explicitly follow the STEP cycle as
any setting. you create a solution to a problem
(perhaps try this for an engineering
At this point we recognize that these analysis problem, a writing problem,
fundamentals can be overwhelming and a design problem, or any other
that it will take time and effort for you to problem that requires the creation of
absorb, practice, and master them. some specific artifact). For each
Nevertheless, developing a strong step, explain the actions you have
understanding of these fundamentals will taken.
help you become an effective product
developer. As you work with these A2-3 In your own words, explain the
fundamentals, they will become a natural meaning of independent activities,
part of your approach to product dependent activities, and
development. interdependent activities.
A2-4 Prepare a thoughtful paragraph
about the risks of not coordinating
2.9 Exercises
team member efforts during product
Test Your Knowledge development. Be precise about the
risks that will be faced. Write the
paragraph as if it will be used to train
T2-1 What are the three kinds of product new designers.
development artifacts that evolve
during the product development A2-5 Quiz yourself on activity map logic, by
process? covering the activity relationships and
the outcome relationships of
T2-2 What are the three characteristics of Figures 2.7 and 2.8, and stating
useful outcomes in activity maps? them based on the map structure.
T2-3 What are the two kinds of product A2-6 Activity maps can be used for many
development artifacts that are used to activities outside of product
determine how well the design meets development. Demonstrate your
the requirements? understanding of activity maps by
creating one for purchasing a new
T2-4 What are the four parts of the STEP tablet computer. Identify
cycle? independent, dependent, and
interdependent activities and
T2-5 What are the six stages of product outcomes.
development?
A2-7 Choose a relatively complex task with
T2-6 What are the three different which you are familiar and develop
evaluation methods used to obtain an activity map for accomplishing the
approval? task. In your activity map,
Required product development artifacts for each stage of development. Use with Exercise A2-12.
Opportunity Concept Subsystem System Producibility Post-release

Development Development Engineering Refinement Refinement Refinement
Requirements
Tests
Design
demonstrate your understanding of representatives, and how should

independent, dependent, and you mitigate those risks?
interdependent relationships by
having at least one of each. Also
demonstrate your understanding of
compound outcomes by having at
least one.
A2-8 Consider a multi-person project you
are currently working on. Give
yourself an honest evaluation of how
well you are coordinating the efforts
of the people involved, or how well
you are following a project plan
someone else has created that
involves you. If you don’t know how
to evaluate yourself in this area, find
a colleague or mentor who help you
through the evaluation.
A2-9 Through which stages of
development will your design need to
pass for your specific project?
A2-10 What is the role of approval in
evolving the design?
A2-11 What role do market representatives
play in evolving the design?
A2-12 Complete the table here using your
own words to indicate the required
product development artifacts at the
end of each stage of development.
A2-13 Consider a project you’re working on
now.
a) Who is the market
representative?
b) In what ways has your team
used market representatives to
evolve the design information?
c) What risks are associated with
your use of market
CHAPTER 3
Design Skills
The evolution that takes place during We explain these ten design skills and
product development, as the design categorize them as crucial, because either
transitions from an embryonic idea to a in an individual setting or in a group setting,
complete design for a manufactured these skills will be needed to evolve the
product, is not automatic nor is it a design through the stages of development.
mechanical process. It does not occur on In fact, they are often used during every
its own or by chance. Importantly, excellent stage of development and across every
products are not created by rote application activity map. This means that discovering,
of specified design methods. Instead, they for example, is a skill the designer will use
are created when designers apply their best more than once and during more than one
and most skillful efforts to the challenge at stage of development, or across more than
hand. one activity map. It will be something the
designer does multiple times, even
The purpose of this chapter is to explain
continuously in some cases.
ten crucial design skills that we need to
apply when developing great products.
These skills are: Not only will these ten skills be needed to
cause design evolution to occur, they will
also be used to judge how good we are as
• Planning
designers. Understandably, others will
• Discovering evaluate our skills in these areas before
we’re assigned to a new product team, or
• Creating
before we win a bid for a job, or before we
• Representing gain employment. As such, these skills are
crucial to our profession and deserve our
• Modeling ongoing attention.
• Prototyping
• Experimenting In many cases, design tools and methods
have been developed to help us acquire
• Evaluating and refine these crucial design skills.
Consistent, repetitive practice with these
• Deciding
tools and methods leads to the
• Conveying development of greater skills. Many of

https://doi.org/10.1007/978-3-030-14899-7_3
38 CHAPTER 3. DESIGN SKILLS
these tools and methods are included in Goal Pyramid (11.32), Nucor’s
the Development Reference, which is Circles (11.38), Objective Tree (11.39),
Part II of this book. Plan Do Check Act (Shewhart
Cycle) (11.46), Planning Canvas (11.47),
The ten design skills are briefly presented
Project Objective Statement (11.49), and
below with referral to the Development
Value Engineering (11.69).
Reference for more information. As you
read through the skills, take heart in Understanding and practicing these
knowing that we can all improve in these activities will help you develop skills in
ten areas. planning.
3.1 Planning 3.2 Discovering
Planning is the act of considering why a Discovering is the skill of finding existing
design effort is needed, what resources knowledge and ideas. It also includes the
enable it and what constraints limit it, and skill of uncovering customer needs and
allowing that information to guide our preferences. Designers who are excellent
actions to be effective at achieving the at discovering are better able to build on
desired outcome and be efficient in using previous work and develop a desirable
resources. product than those who are not. It’s
virtually always faster to find knowledge
Planning, as a skill, is needed continuously than to create it. A colleague of ours has
throughout the product development expressed this concept by saying “I can
process. It is needed formally, and save myself hours in the library by
informally. For large complex projects, for spending months in the laboratory.” In the
simple ones, and for small pieces of time-critical world of product development,
projects. Planning is needed for people we cannot afford to overlook existing
working alone and for people working in information that is relevant to our design.
teams. Planning keeps us from wandering.
People who are skilled at discovering
Designers who have developed the skill of recognize that at the beginning of a project
planning are curious about the following, they do not know enough to be successful.
and do what they can to get and use this To gain the needed knowledge, they are
information: persistent and creative. They know that
relevant information exists somewhere, and
1. The purpose and objective of a they are relentless in their pursuit of that
project/task information. When they build on existing
2. The starting and ending point of the information, they “stand on the shoulders
project/task of giants,” as stated by Isaac Newton.
3. The constraints of the project/task Specific activities that can be used to
develop your discovering skill are treated in
4. The resources available to carry out the Development Reference. They include
the project/task Catalog Search (11.7), Codes and
5. The schedule related to the Standards (11.8), Delphi Method (11.15),
project/task. and Internet Research (11.33).
Specific activities that can be used to help
At any point while working on a project, it is uncover market needs and desires are also
valuable to check yourself to see if you covered in the Development Reference.
know the information listed above, and if Including Focus Groups (11.31),
you’re using it to improve effectiveness and Interviews (11.34), Observational
efficiency. Studies (11.40), and Surveys (11.65).
Specific activities described in the The better you are at discovering, the more
Development Reference related to planning likely you will be able to create a
include: Critical Path Analysis (11.13), world-class product.
3.4. REPRESENTING 39
3.3 Creating At least four types of graphical

representations are used.
Creating is the skill of generating new
knowledge or combining old knowledge in Sketching
new, unexpected ways. Key actions that
are part of this skill include: organizing, Sketches are used as quick graphical
imagining, formulating, brainstorming, representations of a product. Sketches can
synthesizing, substituting, and conceiving. be simple 2-D representations with
annotations to help explain the sketch.
Inexperienced designers may think that
They can be more highly polished 2-D
creating is the primary skill needed in
representations. They can be perspective
product development. Certainly creating is
or isometric sketches that give an
an important skill. However, if creating is
appearance of 3-D. The best sketch to use
not coupled with other design skills, the full
will depend on the purpose for the sketch.
value of the creations is never fully realized.
Skill in creating requires the ability to Sketching is a skill that needs work to be
suspend judgment as well as the ability to developed. The Development Reference
apply judgment. If judgment is not entry on Sketching (11.63) contains some
suspended early in the creation process, simple suggestions to help you develop
promising ideas will be rejected as poor, your sketching skills.
before they have had the chance to be
Effective sketching is a great help in
revised and improved. If judgment is not
communicating the intent of your design
applied later in the creation process, the
both within and without the team.
designer will be unable to identify
weaknesses of the creation, which will lead
to inferior designs. Engineering Drawing
There are many methods that have been Engineering drawings are drawings that are
successfully used to enhance the creative made accurately and precisely, using
process. The Development Reference drawing tools or precise CAD drawing
includes summaries of Bio-Inspired packages. Engineering drawings are made
Design (11.4), Brainstorming (11.5), to scale and will comprise a major part of
Concept Classification Tree (11.9), the design.
Decomposition (11.14), Method
635 (11.35), Mind Maps (11.36), Engineering drawings can be 2-D
Recombination Table (11.53), representations or isometric
SCAMPER (11.58), Storyboards (11.64), representations that communicate some
and Theory of Inventive Problem Solving 3-D information. Most engineering
(TRIZ) (11.66), all of which can help drawings will have multiple views, each of
develop the skill of creating. which contains 2-D information about that
particular view of the 3-D object.
3.4 Representing Engineering drawings can be part drawings

or assembly drawings.
Representing is making graphical
Engineering drawings can be used early in
representations of the product to
the product development process. As the
communicate the design to others (physical
design evolves, the engineering drawings
representations of the product are
will generally increase in detail.
considered prototypes and are covered in
Section 3.6). Graphical representations are Standard practices should be followed
used to explain the idea of the design to when creating engineering drawings.
others, to define the geometry and other
physical characteristics of the product, and The Development Reference entry on
to promote the product to those who will Drawings (11.23) contains more
approve it, among other uses. information on engineering drawings. The
entry on Drawing Checking (11.22) 3.5 Modeling

describes how a drawing is checked for
quality. An essential characteristic of engineering
design is the use of models to predict the
Solid Modeling performance of the design. The skill of
modeling allows the team to make rapid
An effective graphical representation tool iterations in changing design parameters to
for geometry information is solid modeling. achieve the desired performance.
In solid modeling, a virtual model is created
that has identical geometry to the eventual Engineering models may be analytical,
physical part. Solid model creation can numerical, or statistical. The common
often follow some of the same steps as a thread behind engineering models is that
physical machining process. they allow the designer to make predictions
Solid models can be directly used for about how real systems will perform. When
analysis of volume, mass, and center of engineering models have been validated to
mass. Meshes can be created from the match reality, they allow rapid design
solid model to support finite element through exercising models, rather than just
modeling. STL files can be created from building a series of prototypes.
solid models for use with additive rapid When thinking of creating engineering
prototyping machines. CNC tool paths can models, development teams should
be created from solid models for use in consider the creation of multiple models,
machining the modeled parts. Engineering rather than a single model. Early models
drawings can be created from solid models. are likely to be coarse, while later models
While solid modeling is not essential to will be more refined. Both types of models
product development, most companies are useful in product development.
doing product development use solid Section 6.5 provides a description of how
modeling as part of their development modeling can be used in product
process. development. The Development Reference
Solid modeling is further described in the includes entries on Design of
Development Reference entry on CAD Experiments (11.18), Dimensional
Modeling (11.6). Analysis (11.21), Finite Element
Modeling (11.30), Sensitivity
Presentation Graphics Analysis (11.61), and Uncertainty
Analysis (11.68), all of which are related to
Presentation graphics are graphical the skill of modeling.
representations that are prepared to
communicate the design to people outside
the development team, generally to a 3.6 Prototyping
non-technical audience. They may include
sketches that have been colored with Prototyping is the skill of creating physical
chalk, marker, or airbrush; approximations to the product based on the
computer-generated renderings from solid current design that will help answer
or surface models; photographs of rough important questions about how well the
physical prototypes; or other high-quality product works. Key actions that are part of
graphical representations. this skill include mocking up, machining,
Presentation graphics can have a great casting, 3D printing, and breadboarding.
effect on the audience. A product that has Designers who are skilled in making quick,
high-quality presentation graphics is often effective prototypes are highly valued.
perceived as better than one with A detailed discussion of prototyping —
moderate- or low-quality graphics. As you including the six types of prototypes — is
seek to convey your work, you will be wise found in the Development Reference
to make sure your presentation graphics entries for Prototyping (11.50) and Rapid
reflect the quality of your design. Prototyping (11.52).
3.8. EVALUATING 41
3.7 Experimenting Evaluation Types
Experimenting is the skill of using models, There are three types of evaluation that we
prototypes, and people to measure how the often use during the product development
product should and does work. Key actions process:
that are part of this skill include setting up
experiments, instrumenting test setups,
statistical analysis, and working with 1. Intuition-based evaluation
human subjects.
Formal and informal experimentation is Characterized by: Judgment made
extremely valuable to the goals of product without the need for conscious
development. Informal experimentation reasoning
involves simply trying it. We often do this by
Representative activity: Multivoting
spending very little money and time setting
up an experiment. The objective with such
experiments is to very quickly get a sense 2. Qualitative evaluation
for if something is likely to work or not. A
natural consequence of this is that, unlike Characterized by: Judgment made
formal experimentation, the results are based on a qualitative evalution
generally anecdotal. of the alternatives, which
generally involves subjective
Formal experimentation often provides the
assessments that by their nature
best and most expensive information
have limited repeatability.
available about the performance of the
design. Because experimentation can be Representative activities: Screening
so costly, it should be well-planned. Some and scoring matrices
suggestions for getting more value out of
your experiments are given in the
Development Reference under 3. Quantitative evaluation
Experimentation (11.26).
Characterized by: Judgment made
Good experimental skills are often a key
based on a generally objective
discriminator for excellent designers.
measurement of the alternatives.
In general, quantitative
3.8 Evaluating evaluations have less variability
and more repeatability than
Evaluating is the skill of integrating all the qualitative evaluations.
information at hand to determine the quality
of a design outcome (which may include Representative activities: Lab testing,
the entire product). In general, the quality FEA, engineering analysis
of a design outcome will be determined by
its desirability and transferability. Key
actions that are part of this skill include It is valuable to understand that these types
comparing, applying judgment, evaluating of evaluation exist, because each of them
objectively, and concluding. requires a different level of time and detail
to carry out. Intuition-based evaluation
Throughout the product development
generally requires less information and time
process, the desirability and transferability
than qualitative evaluation; and qualitative
of the design are evaluated. The best
less than quantitative evaluation.
designers frequently evaluate the team’s
Understanding this helps us plan when and
work, including their own. Frequent honest
how to use these evaluation types. It is best
evaluation leads to improved performance.
to plan in advance the types of evaluation
The specific types of evaluation tend to vary that will be used to make specific design
depending on the stage of development. decisions.
Table 3.1: Typical evaluation activities used in various development stages.

Cost-benefit Objective Tree Finite Element Fault Tree Cpk , Cp Design of

analysis Multivoting Analysis Analysis (FTA) analysis experiments
Multivoting Scoring and Computational Sensitivity Process FMEA FMEA
Screening Fluid Analysis Cpk , Cp
Matrices Dynamics analysis
Feasibility Design of Process FMEA
Judgment Experiments
Axiomatic Failure Modes
Design and Effects
Analysis
(FMEA)
Axiomatic
Design
Evaluation Activities Even though it is crucial to advancing the

design, product developers may be hesitant
A number of different evaluation activities to make decisions, because they feel like
are used to evaluate the different they don’t have enough information to
alternatives and support decision making in make the right decision. However, all the
product development. Some of the typical desired information is never available.
evaluation activities for each of the stages of Avoiding or postponing decisions is
development are listed in Table 3.1. Many avoiding or postponing progress on the
of these activities are described more fully project.
in the Product Development Reference.
This section provides some guidelines to
help you make effective decisions in a
3.9 Deciding timely manner.
Deciding is the skill of choosing a course of
Mundane and Vital Decisions
action based on the currently available
information. As previously discussed, Not all decisions are created equal. There
product development is the process of are a few decisions (approximately 10-20%)
advancing the design of the product until it that will have a strong influence on how well
is ready to be used for manufacturing the the design meets the market needs. These
product in the desired quantities and with decisions, called the vital few, will take
appropriate quality and performance. Key 80-90% of the design time. Because these
actions that are part of this skill are are so crucial, they require an optimal
choosing and committing. solution, rather than just any solution.
The fundamental act of advancing the Therefore, they should be made with the
design is making decisions that increase best possible design and decision-making
the level of detail captured in the design. practices. For example, if you
Existing as merely an idea, there are yet are designing an automatic transmission
infinite possibilities of specific products that for a car, the gear ratios in the transmission
could be developed to meet the market are likely to be part of the vital few.
requirements. As a production-ready Most of the decisions (approximately
product, on the other hand, every detail of 80-90%) have relatively minor influence on
the design is specified so that a third party how well the design meets the customer
with the appropriate skill can manufacture needs. We call these needs the mundane
identical products based on the design. many. Because they have a small
3.9. DECIDING 43
influence, they don’t need to be optimal; • Let the client or manager make the
satisfactory is good enough. The goal in decision
making these decisions is to spend as little
time as possible to develop an acceptable • Follow the most persuasive person’s
solution. In transmission design, the bolts opinion
holding the case together are likely to be • Accept the choice of the most
part of the mundane many. tenacious team member
One of the key decisions you will make in • Choose the idea with the most detail.
the design process is the decision about
which choices are vital and which are
mundane. The remainder of this section Each of these implicit methods is
deals with decision making for the vital few. dangerous to use, because there is no clear
understanding of how or why a decision
Motivation for Decision Making was reached. However, good products can,
at times, be developed using implicit
Decision making is fundamentally a human decision methods.
activity. Although recommended tools can
help in the decision-making process, Explicit decision methods require the team
ultimately people, not the tools, make the to decide how a decision is to be made.
decisions. The motivations of the people Decisions can be made by individuals, by
involved can affect the process. There are the team, or by a subteam. For decisions
at least three levels of motivation for made by individuals, choosing which
decision making in product development, person will make the decision is important
as shown in Table 3.2. in an explicit process. The decision maker
might be the boss, the client, the team
Some of these motivations lead to decision member with the most expertise, the team
making that is good for the product, while member who feels most strongly about the
others can lead to decisions that neglect decision, or a team member who has been
the product. In general, decisions that are given the assignment to make the decision.
made with the success of the product But in each of these cases, the reason why
explicitly considered are likely to lead to a an individual is making the decision has
better product, and are also likely to lead to been explicitly declared.
most of the positive outcomes identified in
Table 3.2. Individual decision making is likely to be a
good choice when the decision is to be
Decision-Making Processes made between a few very good candidates,
or when the choice is part of the mundane
Decision-making processes can be many. However, if the choice is part of the
classified into implicit and explicit methods. vital few and there are some inferior
candidates, individual decision making may
For implicit methods, the process used to be less effective than a team-based
arrive at a decision is not clearly specified. decision.
It often seems as if the decision just
happens. Common pitfalls associated with When a team chooses to make a decision,
implicit processes include the following: there are two fundamental methods: voting
and consensus. Voting requires individuals
to decide on a preference, and then the
• Everybody agrees to the first proposal, candidate decision with the majority of the
without expressing true feelings votes will be selected. Voting can be an
• Go with the loudest person’s efficient way of deciding things, but it can
recommendation also be dangerous. The dangers of voting
include alienating team members on the
• Go with the most senior person’s “losing” side of the vote, and failing to
recommendation come to a common understanding of the
Table 3.2: Rep-

resentative moti- Individual Motivations Team Motivations Organizational Motivations
vations for deci- Get promoted Minimize risk of failure Develop product
sion making. development capability
Avoid conflicts with team Maximize product Strengthen team cooperation
members performance
Minimize time spent on Please management Develop successful product
decision
Avoid responsibility for the Develop a successful Improve individual
decision product capabilities
Do a good job on the project Maintain good working Let somebody else accept
relationships the responsibility
solution candidates. However, voting can another day or two they will have all the
be a good process for making some of the information they need to decide. As long as
less-important decisions. decisions are not being made, the design is
not moving forward. Be aggressive about
Consensus is likely to be the slowest way to making decisions. Decide, test, and
make a decision, but usually results in the validate. This is a key to effective progress
best decisions. Consensus requires the in product development.
individual team members to agree that a
given decision is the best. Note that
consensus is not compromise. 3.10 Conveying
Compromise implies that two people who
disagree find an alternative that makes Conveying is the skill of sharing the design
both of them somewhat unhappy. In information in a way that meets the needs
contrast, consensus requires two people of others and advances the design, often by
who disagree to find an alternative that facilitating appropriate evaluation by people
both can fully support. both inside and outside the team. Key
actions that are part of this skill include
One tool that is often used to help build salesmanship, writing, speaking,
consensus is the evaluation matrix presenting, summarizing, and advocating.
(sometimes called a decision matrix).
Evaluation matrices can be used The design team is very familiar with the
throughout the design process, but it is strengths of the design, and readily sees
common to use evaluation matrices in why it is desirable and transferable. Those
concept selection, such as the Concept outside the design team are less familiar
Screening and Concept Scoring matrices. with the product, and are generally less
A related, but somewhat different use of enthusiastic about the product. It is the
evaluation matrices is the Controlled responsibility of the design team to convey
Convergence method advocated by Pugh their successes (and concerns) to those
(1991, pp. 74–85). outside the team who are stakeholders in
the development project.
Evaluation matrices do not make decisions.
They simply present the results of Effective conveying requires the team to
evaluations to help individuals and teams understand the needs of the audience and
make decisions. prepare effective communication materials
to meet those needs. The team must
Decide to Decide clearly share the benefits of the product,
while being honest about its limitations.
One of the major mistakes made by The team should be advocates for their
product development teams is to work. Remember that rapid and effective
unnecessarily postpone making design progress is dependent on having the
decisions, assuming that if they wait just necessary resources. The resources are
3.11. EXERCISES 45
most often made available based on the A3-6 Explain the difference between
perception of management concerning the compromise and consensus.
benefits of the project. By effectively
advocating for the project, the development A3-7 Make a sketch of a solution for
team can ensure the availability of the carrying a notebook computer safely
necessary resources to succeed. on a bicycle. Show your sketch to
three different people to see if they
An excellent design that is poorly conveyed understand it.
is at risk of being judged as a poor design. A3-8 Make an engineering drawing of a
Thus, for your designs to be approved for wooden pencil. Ask someone familiar
production, you must develop the skill of with engineering drawings to check
conveying the design to those who make your drawing and give you feedback.
decisions about implementation.
A3-9 Using a 3-D modeling system, make
a solid model of an actual wooden
3.11 Exercises pencil.
Test Your Knowledge a) Use the system to predict the
mass of the pencil.
T3-1 List the crucial design skills. b) Weigh the pencil and see how
well the calculated weight
T3-2 State the goal of prototyping. matches the actual weight.
c) What do you believe is the major
T3-3 State the goal of experimenting. source of the discrepancy
T3-4 State the goal of evaluation. between the calculated and
actual weights? What evidence
T3-5 List three types of evaluation that are do you have for your belief?
often used during product
A3-10 Using a 3-D modeling system, create
development.
a rendering of a solid model suitable
T3-6 State the goal of deciding. for presentation. You may use any
solid model available, including one
T3-7 State the goal of conveying. downloaded from the internet.
A3-11 Poor decision making: Think of a
Apply Your Understanding time when you have been involved
with a team that had poor
A3-1 In which of the crucial design skills decision-making practices.
are you the strongest? How have you a) What do you believe was the
developed your strength in these main dysfunction exhibited by
areas? the team?
A3-2 In which of the crucial design skills b) What could you have done to
are you the weakest? What plans do help overcome this dysfunction?
you have to improve your skills in A3-12 Good decision making: Think of a
these areas? time when you have been involved
A3-3 Describe the difference between with a team that had good
mundane and vital decisions. decision-making practices.
a) What do you believe was the key
A3-4 Explain why explicit decision
practice that led to good
methods are generally better than
decision making?
implicit decision methods.
b) How might you replicate this
A3-5 Explain one strength and one practice in future
weakness of deciding by voting. decision-making opportunities?
A3-13 Assume you are just beginning to

develop concepts for a device to hold
a smartphone on the handlebars of a
bicycle to use as a GPS.
a) List a few possible engineering

models that might be helpful in
this stage of development.
b) For one of these models,
develop and solve it.
A3-14 Make a low-fidelity prototype of the

smartphone holder referenced in
Exercise A3-13. What is the purpose
for this prototype? How well did it
meet the purpose?
A3-15 Thoughtfully create a design portfolio
that conveys your skills in a few or all
of the design skills discussed in this
chapter. Treat the portfolio like a
product and use the design skills
discussed to create an excellent
portfolio.
CHAPTER 4
Opportunity Development
The next four chapters of this book focus one or more of these stages during product
on the stages of product development. As a development. So it’s worth spending time
detailed guide, they describe the purpose to understand them.
of each stage, the development outcomes
you’ll produce and have approved, and This chapter discusses opportunity
some useful tools1 aimed at helping you development, which is the first stage of
evolve the design through each stage of product development. Generally speaking,
development. We also identify some during the opportunity development stage
common pitfalls to avoid in each stage. the team works to evolve information that
characterizes the problem being solved.
When we discuss the development The purpose of this stage is to combine this
outcomes, we focus on the required and other information to define the
information for each stage of development. opportunity.
As the design evolves, new kinds of
information will be created and will need to
be captured in transferable artifacts. The
kind of information discussed is consistent 4.1 Design Evolution During
across varying industries and companies, Opportunity Development
but the artifacts can vary. Thus, we focus
on the kind of information in these The initial idea, which is often sparked
chapters, and only indicate typical artifacts when considering the needs and
as possible ways of conveying the circumstances of people and organizations,
information to others. By understanding marks the beginning of this stage. Key
and applying the principles of the required characteristics of the project to develop the
information for each stage, you will be able idea are captured in the project objective
to make good decisions about the artifacts statement 2 , which is a brief summary of the
you create. scope, schedule, and resources of the
product development project. The project
We devote four chapters to these stages
objective statement serves as a foundation
because all manufactured engineered
supporting all of the work on the project.
products pass through the six distinct
stages discussed. As such, you will work in
2
Sometimes called the design brief or mission state-
1
These tools are listed in the chapters and described ment. See Project Objective Statement (11.49) in the
in more detail in the Product Development Reference. Development Reference for more information.

https://doi.org/10.1007/978-3-030-14899-7_4
50 CHAPTER 4. OPPORTUNITY DEVELOPMENT
Table 4.1: Summary of the opportunity development stage.
Opportunity Development: Develop clear statements of market and engineering requirements that capture the market’s desires for
the product.
Required
Typical artifacts Checking criteria Approval criteria
information
Consistent level of generality?
Capture the most important Complete and appropriate as
Market Section A of the
requirements? Appropriate number evaluated by market
requirements requirements matrix
of requirements? Reasonable representative
differences in importance?
Clearly measurable (even for
subjective)? Capture market Market representatives (for less
requirements well? Generally technical measures) and/or
Requirements
Performance Section B of the

dependent, rather than project approvers (for highly
measures requirements matrix
independent? Units given and technical measures) find the
appropriate? Number appropriate? measures to be appropriate.
Appropriate importance ratings?
All requirements have at least one
measure? All measures have at
Requirement-
Section C of the least one requirement? More than Judged appropriate by project
measure
requirements matrix just one-to-one correlations? approvers
correlations
Appropriate, defensible
correlations?
Values make sense? Values are Judged appropriate by project
Section D of the
Ideal values consistent with market approvers and market
requirements matrix
requirements? representatives
Reports of team interactions

Not approved directly, but used
with market representatives Are the interactions accurately
Tests
None required to support approval of the

(e.g., surveys, interviews, conveyed in the report?
requirements
etc.)
Simple models that relate

desirability to measured Not approved directly, but used
Models
None required performance of competitors Do the models make logical sense? to support approval of the
(e.g., screen size, battery requirements
life)
Rough prototypes
(foamboard, paper, foam,
clay, cardboard, plywood, Do the prototypes facilitate Not approved directly, but used
Prototypes
None required etc.) used to communicate communication with market to support approval of the
with market representatives. representatives? requirements
Don’t fully reflect eventual
product design.
Rough sketches or drawings
of competitors or generic Do the sketches or drawings Not approved directly, but used
Design
None required product possibilities. Don’t facilitate communication with to support approval of the
fully reflect eventual product market representatives? requirements
design.
Basic design process, competitive benchmarking, financial analysis, focus groups, interviews, observa-
Useful tools: tional studies, patent searches, planning canvas, project objective statement, quality function deployment,
requirements matrix, surveys.
Common Assuming, not validating; using only subjective performance measures; delaying feedback; devaluing the
pitfalls: opportunity development stage; spending too much time.
4.1. DESIGN EVOLUTION 51
Progress is made during the opportunity Purpose

development stage as the team gathers
information about the market needs and The purpose of the opportunity
conditions, and comes to understand and development stage is to create clear
articulates what would be required of a statements of market and engineering
desirable product. requirements that capture the market’s
desires for the product.
To be clear, a well-defined opportunity At the end of this stage, these elements are
comprises the following information: checked and validated to ensure they are
thoughtfully articulated, unambiguous, and
accurately reflect the market’s expectations.
1. Market requirements, which define the
requirements for a desirable product Development Outcomes
in terms the market understands and The following development outcomes will
uses. be achieved as the design evolves through
the opportunity development stage. During
2. Performance measures, which are opportunity development, as in each
characteristics of the product that will development stage, development outcomes
be measured by the development may be part of the requirements, tests, and
team. design; or they may be models and
prototypes that are used to predict and/or
3. Requirement-measure correlations, demonstrate the desirability of the design.
which identify the performance
measures that have a significant effect Requirements
on each market requirement.
There are four essential elements of the
4. Ideal values, which define the values requirements during opportunity
that the market would prefer for the development.
performance measures in the absence
of trade-offs. 1. Market Requirements
Market requirements clarify what is
needed for the product to be desirable to
While the items listed above can be the market. They are objective and
documented in a variety of ways, we find it subjective product characteristics that
extremely convenient to capture and customers use to make decisions about
present them in the form of a requirements the products they will purchase. Thus,
matrix 3 , which is described in detail in the market requirements identify key factors
Product Development Reference. that determine desirability.
Therefore, we will use requirements
matrices throughout this book to discuss For the maximum benefit, there will
and present the opportunity definition. typically be from five to twenty
requirements. If there are too few
As a guide to the opportunity development requirements, either some are left out or
stage, we have prepared Table 4.1. This the requirements are too general to be of
table summarizes the purpose, much use in making design decisions. If
development outcomes, approvals, useful there are too many requirements, it is
tools, and common pitfalls that characterize difficult to consider them all during the
the opportunity development stage. These development process. And in fact,
items are explained more fully below. consumers seldom use more than a few
criteria to decide on their purchases.
3
An example of a requirements matrix is shown in All of the requirements should be
Figure 4.2. expressed at approximately the same level
of generality. They should also be specific description of the desired

expressed in the form of product-focused qualitative performance can help
requirement statements. To develop this minimize subjectivity of the evaluation.
succinct but representative list of market Rubrics for performing the qualitative
requirements, follow the guidelines laid evaluation can provide a quantitative
out in the Development Reference under assessment for qualitative performance.
Requirements Hierarchy (11.54) and
Product-Focused Requirement There should be a unit of measurement
Statements (11.48). associated with each performance
measure to help clarify what is being
It may be desirable to list a relative measured and to avoid confusion among
importance for each of the market team members and other stakeholders.
requirements. This relative importance
helps the team focus on the most Performance measures should generally
important requirements. The relative be dependent, rather than independent,
importance is sometimes indicated as a characteristics of a product. This is simply
percentage (especially when there is a because if the designer is free to
small number of requirements). It can independently choose some
also be given a geometric scaling such as characteristic, it’s not really a performance
1 (30 ) for low importance, 3 (31 ) for measure, and the design team can just
moderate importance, and 9 (32 ) for high choose a desirable value. Instead,
importance. performance measures should require
that the designer choose proper values of
Assigning importance to requirements is some other independent parameters in
necessarily a subjective process. After order to assure that the performance value
importance has been assigned, the team is met.
should carefully check whether the listed
importances actually reflect the opinion of In order to help the development team
the market. focus on the most important measures, it
is often useful to have an importance
Because the requirements capture the rating for each of the performance
desires of the market, rather than the measures. The importance rating may be
desires of the team, market assigned by the team in consultation with
representatives must be involved in the market representatives. It may also be
approval process for the market obtained by combining the importance of
requirements. the market requirements with the
requirement measure relationships (see
2. Performance measures Quality Function Deployment (11.51) in
the Development Reference for more on
By definition, the market requirements how this is done).
reflect the concerns of the market. Also by
definition, the development team is not Some performance measures are easily
the market. Therefore, in order for the understood by market representatives
team to develop a desirable product, they (e.g., fuel economy). Such measures
must have some means of determining should be approved by market
whether the product is desirable. The representatives before the end of
performance measures are product opportunity development. Other highly
characteristics that can be measured by technical measures need only be
the team and provide information about approved by the project approvers.
the desirability of the product.
3. Correlations between market
Where possible, performance measures requirements and performance measures
should be quantitative. However, in some
cases it is necessary to use qualitative Performance measures are often
performance measures. In these cases, a developed by considering ways to
measure how well the product meets a 4. Ideal values for performance measures
particular market requirement. In such
cases, there is a strong correlation These values represent the desires of
between the market requirement and the the market for the performance measures
performance measure. However, it may in the absence of trade-offs. For each
take several performance measures to performance measure there should be
adequately measure the achievement of an ideal value, which indicates the value
some market requirements. Similarly, a the market most prefers. There may also
single performance measure may help to be upper and/or lower acceptable limits,
determine multiple market requirements. which indicate the limits to the values
that the market will find acceptable.
The correlations between market Values outside of the acceptable
requirements and performance measures limits will lead to an undesirable product.
can be easily captured in matrix form, It is possible that either the upper or lower
such as that shown in Figure 4.2, where a acceptable limit does not exist. In such
dot indicates the performance measure in cases, this should be explicitly indicated.
the column is correlated with the market
requirement in the row. Tests
The correlations captured here should be No tests (of the design) are required during
measurement correlations. For example, opportunity development, simply because
consider the design of a car, with a market the design has not yet started to take form
requirement of good gas mileage and in this stage of development. However, as
performance measures including vehicle performance measures are created, it is
weight and EPA city fuel economy rating. useful to consider tests that can be used to
EPA city fuel economy rating is a measure evaluate the performance of a design that
of how good a vehicle’s gas mileage is, so will begin to emerge in the next stage of
these have a measurement correlation. development.
Measurement correlations are captured in Interaction with market representatives
Section C of the requirements matrix. (surveys, interviews, etc.) can be
considered tests of the market
In contrast, vehicle weight is not used to requirements as they are developed. Such
measure gas mileage, even though weight interactions generally lead to better market
is correlated with gas mileage. Because requirements.
this is not a measurement correlation, it is
not captured in Section C of the Models
requirements matrix.
No models (of the design) are required at
All market requirements should have this stage of development. However,
at least one performance measure, or else market understanding is often facilitated by
they will be largely unassessed by the team. the creation of simple technical models that
relate desirability (e.g., sales, product
Performance measures without market ratings) to measured performance of
requirements indicate either an incomplete competitive or existing products (e.g.,
understanding of the market requirements screen size, battery life).
or an irrelevant performance measure.
Prototypes
Generally some measures are correlated
with multiple requirements. Also, many No prototypes (of the design) are required
market requirements at this stage of development. However,
require more than one performance mock-ups (foamboard, paper, foam, clay,
measure. A strict one-to-one correlation cardboard, plywood, found items, etc.) can
between market requirements and often be used to improve communication
performance measures is likely to indicate with market representatives and obtain
a superficial job of identifying correlations. better market requirements information.
Design of assuming what the market wants.

Seek and listen to honest feedback.
No design — meaning no definition of the Unproven assumptions cause
product — is required during opportunity significant problems.
development. However, it is often desirable
to create sketches of generic product • Teams using only subjective
possibilities to use in interactions with performance measures: Avoid
market representatives. Because these converging on only subjective
artifacts are not focused on the intended performance measures. Work to
product, but rather on possibilities, they are define these items to the point that
not part of the design (i.e., they don’t define most can be measured with objective
the product being developed). performance measures.
• Teams trying to refine and perfect their
Useful Tools work before seeking feedback:
Embrace the concept of failing often to
To advance the design through this stage of succeed sooner (Kelley and Littman,
development, the product development 2001, Chapter 15).
team completes design activities. To help
you get started, and for later reference, we • Teams failing to see the value of this
list the following tools as often useful during early stage of design: The trajectory for
the opportunity development stage: the product and the project is
established in this stage of
For information gathering: development. Spending too little time
Benchmarking (11.2), focus or giving too little attention to this stage
groups (11.31), interviews (11.34), of development means having a higher
observational studies (11.40), patent risk that the final product is not
searches (11.43), surveys (11.65), wanted by the market.
literature search. • Teams spending too much time on the
For establishing the market requirements: design activities: More time can
Quality function deployment (11.51), always be spent on a stage of
requirements matrix (11.55), development; avoid endless
requirements hierarchy (11.54), development by passing through this
product-focused requirement stage of development quickly, but with
statements (11.48), goal a sufficient understanding of the
pyramid (11.32). market requirements to do a good job
at subsequent stages of development.
For general design work: Basic design
process (11.1), financial
analysis (11.29), planning 4.2 Example of Opportunity
canvas (11.47), project objective
statements (11.49), Development
storyboards (11.64).
To clarify the product development artifacts
that result from the opportunity
Common Pitfalls development stage, an example product is
Having interacted with or participated on presented. The product chosen is a
numerous product development teams, human-powered water well drill for the
we’re familiar with the pitfalls of this stage developing world, which is shown in
of development. Here’s a short list of finished form in Figure 4.1, and is
common pitfalls to avoid: described in detail as a case study in
Appendix B (found on page 327). This
• Teams assuming — not validating — example will be revisited for each of the
what the market wants: Avoid stages of development, so you may find it
substituting team, supervisor, sponsor, valuable to review Appendix B now.
or end-user judgment for all The approved project objective statement
stakeholder judgment. Avoid the risk for the human-powered drill is:
4.2. EXAMPLE 55
Design, build, and test a human-powered

drill that reaches underground potable
water at depths of 250 ft in all soil types by
March 25, 2011 with a prototyping budget
of US$2,800 and for less than 1,700 man
hours of development.
As listed in Table 4.1, the requirements at

the end of the stage must include a defined
opportunity, which can be captured in
Sections A, B, C, and D of the requirements
matrix. Figure 4.2 shows these sections of
the matrix for the drill at the end of
opportunity development4 . As seen in the
figure, the market requirements are listed
on the left-hand side. This list represents
what the market requires. For this
example, the team identified the list by
speaking with the client and experts, by
benchmarking, and by using other forms of
research.
After establishing the market requirements,
the team considered them one-by-one, and
chose performance measures for each Figure 4.1: Model of the finished human-powered
requirement. These measures define the water well drill. This drill resulted from an engi-
attributes of the product that will be neering effort to bring clean drinking water to ru-
measured or evaluated to determine ral communities in sub-Saharan Africa. The de-
whether the design meets the market vice was designed to drill a 6 inch diameter hole
requirement. For example, the market 250 feet into the ground to access clean drinking
requires that the drill reach potable water water.
beyond 100 ft (market requirement #1).
Considering this requirement alone, the
team chose how it might be measured or
evaluated. The team chose maximum achieves desirable values of maximum
borehole depth (in units of feet) and time borehole depth and time to cut through six
required to cut through 6 inches of rock (in inches of rock.
units of minutes) as the relevant
performance measures. The relationship The team carried out this process for each
between performance measures and of the market requirements. To minimize
requirements is captured by the dots the risk that they are not representative of
placed in the relationships section of the the market requirements, all product
matrix. development team members should ask
themselves if they believe the performance
By choosing these performance measures, measures to be correct — that this set of
the team indicates that the market measures adequately represents the
requirement for reaching potable water market requirements.
beyond 100 feet will be met if the drill
Check the requirements: Do you think
the performance measures adequately
4
As described in the Product Development Refer- represent the market requirements for
ence, the full requirements matrix includes the real val- the human-powered water well drill?
ues at the bottom of the matrix, and the market response
on the right side of the matrix. These two elements are Would you have chosen additional or
not developed as part of this stage. different performance measures?
water well drill.
10 The Drill is portable
Product: DRILL
12 The Drill is attractive

Subsystem: N/A
8 The Drill is affordable

56
13 The Drill attracts investors

2 The Drill cuts through rock
Market Requirements (Whats)
3 The Drill uses existing drill bits
11 The Drill is comfortable to operate

6 The Drill works at an efficient speed
9 The Drill requires simple training to operate

7 The Drill uses only manual labor to function
5 The Drill removes cuttings from the borehole
Ideal Values
1 The Drill reaches potable water beyond 100 ft

Importance
Importance
3
1
1
9
9
9
9
3
3
4 The Drill seals borehole sides to prevent cave-in 3
3
1
9
Upper Acceptable Ideal Lower Acceptable Performance Measures Units
– 250 100 9 1 Maximum borehole depth ft
60 45 – 10 2 Time required to cut through 6 inches of rock min
– 3,000 500 10 3 Downward drilling force lbs
– 400 200 10 4 Torque applied to drill bit ft-lbs
– 100 90 3 5 Compatable with X% existing drill bits %
– 113 50 6 6 Water pressure down the pipe psi
5 0 – 3 7 Percentage of water that leaks through sides %
– 100 95 3 8 Percentage volume of cuttings removed %
– 36 4 3 9 Depth cut per 8 hours of drilling ft
12 3 – 9 10 Number of required people people
400 50 – 9 11 Weight of heaviest subassembly lbs
96 48 – 9 12 Longest dimension (l,w,h) of biggest subassembly in
– 100 85 9 13 Percentage of drill manufacturable in Tanzania %
5,000 1,000 – 9 14 Cost to produce 1 drill after development USD
20 4 – 9 15 Time required to learn how to operate hr
5 3.5 2 1 16 Height of hand operated parts ft
Drill can be operated Drill can be operated with
– continuously without the occasional rest, and requires 1 17 Feels comfortable n/a
need to rest. Does not awkward movements that
require awkward movements. leave the user sore.
Drill has a professional look. Drill looks like a piece of

– People are interested in 4 18 The Drill is attractive n/a
machinery for drilling holes.
looking at it.
Drill captures media
The drill, when explained to
attention. Investor s are n/a
– investors, is something they 12 19 The Drill interests investors
proactive in contributing.
want to invest in.
Drill has iconic look.
Figure 4.2: The system requirements matrix at the end of the opportunity development stage for the human-powered
CHAPTER 4. OPPORTUNITY DEVELOPMENT
4.3. TOP-LEVEL ACTIVITY MAP 57
Once the performance measures are Compound Outcome 5 in Figure 4.3 is an

established, they become excellent talking approved project objective statement.
points for deeper conversations with the Crafting and revising this statement helps
client, experts, and end users. They are the team understand the scope of the
also specific enough that competitive project. Notice that this outcome is
products can be benchmarked against achieved by completing multiple activities
them. These talking points and competitive including Interacting with the client,
benchmarking results become a useful part Creating and revising a project objective
of choosing ideal values and acceptable statement, and seeking approval.
limits for each performance measure. The
acceptable limits and ideal values establish Recognize that the project objective
bounds within which the design should be statement is achieved through significant
created. interaction with the client, while Outcome 6
(market/customer statements) is focused
on interactions with people who represent
4.3 Top-Level Activity Map for the market — which are typically not the
Opportunity Development client. Also notice that Outcomes 9 (market
requirements) and 10 (performance
The previous sections have shown the measures) are not fundamentally about
outcomes of the opportunity development interactions with clients nor market
stage, but have said little about the representatives, but are worked through
activities and sub-outcomes used to within the team as the market statements
achieve these outcomes. To that end, this are processed. Although the initial market
section provides a relatively high-level requirements and performance measures
activity map that can be used to produce are independent, the final requirements
the main outcomes for opportunity (Outcome 15) and performance measures
development. (Outcome 14) are interdependent as
indicated by the double-headed dashed
While we provide this section as a guide, it arrow. This means that market
is important to remember that it is the requirements and performance measures
product development team’s privilege and affect each other.
responsibility to choose the specific
arrangement of design outcomes and the To solidify this concept, consider market
design activities that will lead to them. requirement #6 for the drill, and
Ultimately, the specific outcomes and performance measure #9 as shown in
actions chosen need to meet the unique Figure 4.2. Requirement 6 is the drill works
needs and conditions of their project, at an efficient speed. The ideal value for
client, and/or product development team. performance measure #9 is that the drill
Figure 4.3 provides a top-level activity map cuts 4.5 feet per hour. Now, which was
for the opportunity development stage. This identified first: work at efficient speed, or
activity map can be thought of as a cut 4.5 feet per hour? If the team chooses
somewhat more detailed look at what goes to serialize, either one could have come
on during the opportunity development first. When the market requirement comes
stage. first, the team chooses one or more
performance measures to represent it.
Notice that we have not specified definitive When the performance measure comes
activities that should take place. We have, first, the team must discover what (often
however, provided some example activities unspoken) market requirement(s) it
that could be used to accomplish the represents.
outcome. The fact is that there are multiple
design activities that could be used to To handle the activities that lead to the
achieve the outcomes. Many of the interdependent outcomes in Figure 4.3
example activities listed here are described (Outcomes 13, 14, and 15), the team first
in the Product Development Reference. develops an initial requirements matrix
requirements,
Initial performance measures,
idea and correlations, and ideal
team Translate values
market
statements Identify missing or 15 21
Interact with 6 8 hidden
client Organize requirements
Capture
requirements
performance
into hierarchy
measures from
t
arke
1
market
19 22
ith m
Create Project statements Identify

9
Objective Statement further
act w
to which team can correlations

commit
Inter
11 12 13
10
Seek approval 20
Objective Identify initial from client
Statement Capture reqt.-measure Identify missing
2 3 performance correlations performance Seek feedback
measures found measures from market
in benchmarking
5 7 14
Seek approval Model market
for Objective preferences
Study competitive
Statement
products and 17 18
4 technology in 16
general Use market model to
establish acceptable
limits and ideal values to Concept
Development
OUTCOMES
Client’s wishes about scope, schedule,
1 8 Product-focused requirement statements 15
resources
2 Initial project objective statement 9 Initial market requirements Models of market acceptance vs
16 performance
3 10 Initial performance measures Ideal values and acceptable limits for
17 performance measures
4 Approval of project objective statement 11 Initial measures and requirements
18
5 Approved project objective statement Initial requirement-measure correlations
12 19 Approval of opportunity development
Market/customer statements related to the
6 product Market feedback on requirements,
13 20 measures, and ideal values
7 General benchmarking data
14 21
22
Figure 4.3: Top-level activity map for the opportunity development stage.
4.4. HOW TO GATHER AND PROCESS ESSENTIAL INFORMATION 59
using information obtained from specific context, the team seeks approval
benchmarking and customer statements. for the market requirements, the
The team then may do either of the performance measures, the correlations
following: between them, and the ideal values.
Together, these define the opportunity.
• Complete the activities “Identify Ultimately this activity map for the
missing or hidden requirements,” opportunity development stage results in an
“Identify further correlations,” and approved opportunity (Outcome 22), which
“Identify missing performance is exactly what the team will need when
measures” in any order, one at a time, beginning the concept development stage.
repeating until no further items are Remember that Figure 4.3 is just one
identified. possible activity map; others could be
• Complete the activities listed above in developed to accomplish the same
parallel, simultaneously progressing on high-level outcome. We reiterate that within
all three until no further items are this activity map, there is substantial
identified. freedom for the team to customize the
process by further decomposing and
choosing more specific design activities.
If the team chooses to run the activities in
parallel, it is wise to choose a short Recognize that the details in the activity
coordination interval. This allows all three map are not superfluous, but are the
activities to be executed to result in details that will help you plan and carry out
preliminary outcomes, which are then your product development work.
examined together. All three activities
would then be re-executed, if needed, to 4.4 How to Gather and Process
result in improved outcomes. This process Essential Information
would continue until all three outcomes
(13, 14, and 15) are desirable. In this way One of the most important
the activities are carefully coordinated. things to recognize about the opportunity
development stage is that it is not merely
We can also see in Figure 4.3 that about formalizing the opportunity, it’s about
Outcome 9 (market requirements) and developing it. What this means is that
Outcome 10 (performance measures) are our understanding — and the client’s un-
compound, which is shown as a gray oval derstanding — of the market requirements,
comprising both outcomes and labeled performance measures, requirement
Outcome 11. This graphical representation measure relationships, and the ideal
means that the activity “Identify initial values will grow as the opportunity evolves.
requirement-measure correlations”
requires both the initial market The activity map provided in Figure 4.3
requirements and the initial performance shows the sub-outcomes of the stage; but
measures as input. Notice that this is simply getting something for those
subtly different from “Model market outcomes will not be enough. We’ll want to
preferences,” which only needs develop the opportunity as effectively and
Outcome 14 as input (represented by the efficiently as possible. To do that, we will
arrow coming from Outcome 14 and not need to be thoughtful about how we choose
from the compound node), even though to gather and process information. To this
Outcome 14 cannot be complete until both end, we use this section to describe a few
Outcomes 13 and 15 are complete. things we like to keep in mind when
working through the opportunity
Continuing in the map, we see that development stage.
Outcomes 13-15 and 17 are all needed
before “Seek approval from client” can Representing the Market
begin, which makes them a compound It is impossible to know exactly how the
outcome (labeled Outcome 18). In this market will respond to a new product,
without actually putting it on the market. Development Reference. They are:

However, it is possible to obtain information surveys, focus groups, interviews,
from potential customers, users of observational studies, and product
competing products, experts in related benchmarking. In general, product
fields, marketing experts, etc. These development teams will use all or most of
sources of market information are these techniques in a strategic mix as they
collectively referred to as market seek to understand what the market wants.
representatives.
For successful product development, it is Surveys
vital that the market representatives Surveys obtain written feedback about cus-
actually reflect the real market. Care in tomer preferences. They may be performed
choosing market representatives will be in various ways, such as by telephone,
rewarded with higher-quality information post, email, website, or in person. Surveys
about the real market. generally are the cheapest way to obtain
information and are therefore used to
When choosing market representatives, it is
sample a very broad section of the market.
important to consider the specific market
A major limitation of surveys is the inability
segments at which the product is aimed,
to ask effective follow-up questions to better
rather than the overall market of related
understand the responses that are given.
products. For example, if a team were
designing a new automobile, different
market representatives would be used for Focus Groups
an economy car and a luxury sports sedan.
Focus groups are group interviews of small
Although the development team members groups of potential customers. In a focus
should do their best to understand the group, a facilitator will ask the participants
market, it is very risky to completely to discuss the issues relating to the product
substitute the team’s judgment for that of or the needs leading to the product. Focus
the market. The market representatives groups will often use props such as
that are chosen during the opportunity competitive products to help the
development stage will be used to validate conversation become more real and
the design at the end of each stage of focused. Because the facilitator is
development. Different individuals may be interacting with the group members,
used, but the collection of individuals follow-up questions can be used to better
should represent the same market clarify and understand any concerns or
population. needs expressed.
Focus groups are limited to relatively small

Understanding the Market groups, so multiple focus groups will be
If we are to have products that the market held if a large market sample is desired.
finds desirable, we must understand the Information obtained from focus groups is
market thoroughly. In this section, we generally of higher quality than survey
describe some design activities that are information, but comes from a less broad
often pursued to understand the desires of spectrum of the prospective market.
the market.
Interviews
The objective in understanding the market
is to find out what the market cares about Interviews are one-on-one discussions
in a product or a potential product. with potential customers. Props
Different techniques are used, with varying such as competitive products can be used
breadth, cost, and quality of information. to help spur and focus the conversation. In
Five techniques that are particularly interviews, the subjects are not influenced
pertinent here are described briefly below, by others (as they are in focus groups),
with more details found in the Product so information may better reflect an
individual’s feelings. On the other hand, the benchmarking – helps in a variety of ways.
lack of others in the interview may result in a Benchmarking can help the development
subject overlooking some important issues. team understand the performance, cost,
and technology of competitive products. It
To capture effective market information, the can help determine the target performance
number of interviews required is values and financial implications of the
significantly larger than the number of product under development. It can provide
focus groups. The cost of an interview is valuable seeds for creativity in the
only marginally less than the cost of a focus development team.
group. For this reason, focus groups are
often preferred to interviews. Techniques for discovering and
understanding the competitive landscape
However, quiet individuals are more free to are described in this section.
speak in interviews than in focus groups.
Interviews are also free from groupthink Products for competitive benchmarking
and from influence exerted by dominant should be chosen from the leading
individuals. Because of these strengths, products of the market segment(s) at which
interviews should generally be part of the your product is aimed. Determining these
process to determine market desires. benchmark products requires discovering
the products that are currently in use. The
benchmarking will be no better than the
Observational Studies
range of other products considered, so it’s
In observational studies, a member of the important to be thorough and thoughtful in
development team goes to the location of a choosing the benchmark products.
potential customer and observes what the
There are two basic kinds of benchmarking:
subject does, rather than what the subject
says. A perceptive observer will learn much
more about the subject’s needs and desires • Technical benchmarking: One method
than will ever be expressed by the subject of analyzing competitive products is
in words. This information tends to be technical benchmarking. In technical
some of the highest quality information that benchmarking, the performance
can be obtained. measures5 identified in the opportunity
are measured for each of the
However, this information is also expensive competitive products. At the end of
to obtain. It is likely that subjects will only this activity, the team will understand
be interacting with the potential product for in detail the performance of the
a short fraction of the time they are together competitive products in the market
with the observer. Therefore, the time segment.
required to do a single observational study
will generally be much larger than the time • Market benchmarking: A second
for an interview. method of analyzing competitive
products is market benchmarking. In
The quality of observational studies makes market benchmarking, the market’s
them essential; their cost means that they rating of the strengths of the
must be used wisely. competitive products is obtained.
Competitive evaluation can be
Product Benchmarking obtained directly from market
representatives, using the techniques
To create excellent solutions, it is vital to listed above such as surveys,
understand the range of available products. interviews, and focus groups. Market
Even for products that are truly ratings can also be obtained from
groundbreaking, there are alternative ways various product reviews, such as
that the requirements are currently being magazine reviews and online reviews.
met. Understanding everything possible
5
about competitive products – called One of the four things that defines the opportunity.
In addition, market performance Developing a Requirements Hierarchy

information is often available from
published market share analyses. A requirements hierarchy results from
The goal of market performance translating the customer statements into
benchmarking is to thoroughly product-focused requirement statements,
understand what the market thinks then organizing the resulting requirement
about the benchmark product, both in statements into related groups. For each
overall evaluation and in evaluation of group, a summary requirement statement
the specific market requirements you is created that represents the more specific
have chosen. requirements in the group.
Table 4.2 lists six guidelines developed
from those presented by Ulrich and
Taken as a whole, the results of technical Eppinger (2012, pp. 81–83) for writing
benchmarking and market benchmarking effective product-focused requirement
provide a valuable source of understanding statements. While these guidelines may
the desires of the market. seem arbitrary, in our experience we think
more clearly about the product when we
follow the guidelines.
Processing the Information Gathered
During This Stage If the number of summary requirements
statements is appropriate (5 to 20), the
In order for the gathered market
summary requirements become the market
information to be valuable to the team, it
requirements. If there are too many
needs to be processed and condensed so
summary requirements statements, the
that it can be continually used by the team
organizing process may need to be
to evaluate the desirability of the design
repeated until a manageable number is
throughout the remaining stages of product
reached.
development. Here, we briefly discuss the
processing of information as it pertains to
the sub-outcomes of this stage. Developing Performance Measures
For each of the market requirements, the
Capturing Customer Statements team should ask itself “How might we
measure this requirement?” Each of the
Customer statements are statements made answers to this question will become a
by individuals who are part of the market performance measure. Beware of the
representatives about their desires for the temptation to only get a single performance
product being developed. They should be measure for a given requirement. Because
recorded in the customer’s own words. the requirements are summaries of multiple
They can be obtained from interviews, needs, it’s likely that there will be multiple
focus groups, online surveys, paper performance measures for a given need.
surveys, or any other method of hearing
what the customer thinks about the It’s also helpful for the team to ask itself
product. Capturing the information in a “What else might be useful to measure on a
form as close as possible to the customer’s competitor’s product?” This may lead to
actual words is important in order to avoid additional performance measures that
substituting the development team relate to multiple market requirements or
judgment for the market judgment. that relate to market requirements not yet
identified.
Customer statements tend to be narrowly
focused on specific desires, although Determining Requirement-Measure
top-level desires are also expressed at Correlations
times. The different levels of specificity for
customer statements will be rationalized Once the market requirements and
using a requirements hierarchy. performance measures are identified, the
Table 4.2: Six guidelines for writing effective product-focused requirement statements from customer statements. Exam-
ples are given for customer statements found in online reviews of cordless circular saws.
Guideline Customer Statement Good Requirement Inferior Requirement

Statement Statement
Express the requirement It just doesn’t have the The saw resists binding The saw doesn’t bind
with positive, not negative, torque of a corded saw when cutting plywood. when cutting plywood.
phrasing and will choke in a slight
bind while cutting
plywood sheets.
Express the requirement I wish it had a case to The saw is resistant to The saw is rugged.
as specifically as the user protect it from dents and dents and dings.
statement dings.
Express the requirement The trigger safety interlock The saw can be started People can easily reach
as a requirement of the is aggravating! I have easily by most people, the safety interlock.
product, not the incredibly large hands even with safety interlock
environment or the user and still find the trigger features active.
interlock a stretch to
reach.
Express a requirement, The battery lasts for three The battery lasts a long The battery lasts for three
rather than a performance hours of typical carpentry time. or The battery life hours.
measure work. allows typical carpentry
work.
Express a requirement, Having the blade on the The saw provides clear The saw has the blade on
rather than a product left side gives a sight to the cut. the left side.
feature right-handed user a great
line of sight.
Express the requirement The saw does not have a The saw illuminates the The saw should illuminate
independent from its light which I miss. cut area. the cut area. or The saw
importance must illuminate the cut
area.
team should review the correlations captured by the performance measures.

between the requirements and the For these requirements, it is important to
measures. This can often reveal additional develop subjective performance measures
correlations that help the team focus on the to ensure that the market requirements are
most critical measures. The Development fully accounted for in later decisions.
Reference entry on Goal Pyramid (11.32)
After determining the requirement-measure
teaches a process for identifying the
correlations, the team should be satisfied
measures that will have the greatest
that the market requirements are fully
influence on the success of the product.
captured in the performance measures. To
A matrix that shows only one-to-one the extent possible, the performance
correlations between requirements and measures should be objective. In addition,
measures likely reflects superficial thinking subjective performance measures should
about requirements, performance be used where necessary to fully capture
measures, or both. Also, a matrix that the market requirements.
shows correlations between most
requirements and measures is probably Determining Ideal Values
giving too much credit to weak correlations.
The most significant competitive products
At this point, there may be some market
should be benchmarked according to the
requirements that are not adequately
performance measures (technical Multiple activities were introduced in this

benchmarking). This will provide a list of chapter that can help the team understand
the performance of competing products. and process the desires of the market.
The performance data can then be coupled
with the market rating and market share Thoughtful completion of the opportunity
data obtained in market benchmarking to development stage, including the validation
determine how the market responds to of the defined opportunity with carefully
various levels of performance. Thoughtful selected market representatives, can
evaluation of this data allows the greatly increase the chances of developing
determination of ideal values and a desirable design.
acceptable ranges for each of the objective
One of the most important messages of this
performance measures.
chapter is that by itself the team does not
For the subjective performance measures, have enough information to successfully
a description of each of the competitive define the opportunity. To succeed, the
products can be written. When compared team must interact with at least the client
with the market rating and market share and other market representatives. It is
data for the product, a description of ideal likely that the team will also need to engage
performance and the acceptable limits in with subject matter experts.
the subjective criterion can be written.
4.6 Exercises
4.5 Summary
Test Your Knowledge
During the opportunity development stage
the team evolves the design by capturing T4-1 List three characteristics of the
market requirements, determining project that are included in the
performance measures, defining project objective statement.
requirement-measure correlations, and
establishing ideal values of performance. T4-2 List four pieces of information that
Generally speaking, the opportunity comprise the opportunity as it’s
development stage is complete when these developed during this stage.
items are approved.
T4-3 List the necessary requirement, test,
It is worth noting, however, that companies and design content at the end of
often require additional project-related opportunity development.
items6 to be approved at the end of this
and other stages. These can include the T4-4 List six guidelines for writing effective
approval of a project plan for the upcoming product-focused requirement
stage of development, a development statements.
budget assessment/plan, or the approval of
a change management procedure. T4-5 List five techniques that are used to
understand the market desires.
Performance measures with their ideal
values and acceptable limits are essential T4-6 List two kinds of benchmarking that
to the development process. These will are used to understand market
allow the team to estimate the desirability of desires.
the design throughout the product
development process. Apply Your Understanding
A top-level activity map – comprising 22
outcomes – has been presented as a guide A4-1 Think of an idea for simple consumer
for accomplishing the goals of this stage. product. Write a project objective
statement that could be used for a
6
As opposed to the design-related items presented project to develop your idea into a
in this chapter. product.
4.6. EXERCISES 65
A4-2 In your own words, define a market A4-6 Take two of the market requirements
representative. from Exercise A4-5 and develop an
appropriate list of performance
A4-3 Come up with an idea for a simple measures for these requirements.
household product. Once you have
the product idea, discover six market A4-7 Validate your understanding of the
desires for the product. Describe the market requirements from
desires and the process used to Exercise A4-5 by sharing them with a
obtain the desires. market representative and obtaining
feedback.
A4-4 Imagine you are on a development
team tasked with designing a new A4-8 Write a brief stage report for
pen. Discover and understand the Opportunity Development that can be
competitive landscape for pens. used during the stage approval
process for a project you’re working
a) What classes of pens do you
on. Structure your report so that it
find in the market?
answers these two fundamental
b) What class of pen would you questions: What are the product
choose to design? requirements for your project (i.e.,
c) What are the major competitors requirements matrix parts A–D)? And
in that class? how have you validated that they
d) What are the strengths of the accurately reflect the market’s
major competitors? desires? As a way of supporting the
report’s claims attach and refer to
A4-5 One source for customer information product development artifacts that
is customer reviews on online the team has produced.
shopping sites. For this exercise, pick
a product with which you are familiar
and in which you have interest. Go to
an online marketing site (such as
amazon.com) and obtain a selection
of 5-10 reviews for the product.
a) Obtain a list of customer
statements from the reviews.
These statements can be likes,
dislikes, or suggestions for
improvement. Capture the
customer statements in the
reviewer’s own words.
b) Write product-focused
requirement statements for
each of the customer
statements you have obtained.
c) Organize your requirement
statements, creating a set of
market requirements.
d) List any new market
requirements of which you are
aware that did not come from
the customer statements. Why
do you think these requirements
were not included in the
customer statements?
CHAPTER 5
Concept Development
5.1 Design Evolution During Generally speaking, during the opportunity

Concept Development development stage the team worked to
evolve information that characterizes the
The second stage of product development problem being solved. In the concept
is concept development. During this stage, development stage the team works to
the concept for meeting the design evolve the information that characterizes
opportunity evolves from a very general the solution to the problem being solved.
idea to a high-quality system architecture, By the end of this stage, the design is
which includes the following items: checked for desirability and transferability,
the predicted performance of the product is
1. An accurate, unambiguous, compared against the requirements, and
transferable definition of the selected the design is validated to ensure it is
product concept, where enough detail desirable to the market representative.
is provided about the spatial and
structural relationships of the principal A guide to the concept development stage
subsystems that basic cost, size, is provided in Table 5.1.
weight, and feasibility estimates can
be made. There should also be a Purpose
transferable demonstration of how the
The purpose of the concept development
concept’s parts and its whole meet the
stage is to create a concept for the product
opportunity.
and evolve it to contain enough information
2. The decomposition of the system into to create basic estimates for cost, size,
major components or subsystems. weight, and feasibility. The concept that is
evolved should be the one deemed most
3. The definition of the interfaces capable of satisfying the market
between the subsystems. requirements while simultaneously being
4. Opportunity definitions1 for each of the capable of development within budget and
subsystems. according to the development schedule.
5. Target values for the system and In addition, the concept development stage
subsystems. lays the foundation for the subsystem
engineering stage by broadly defining
1
Sections A, B, C, and D of a requirements matrix. subsystems and their interfaces. The

https://doi.org/10.1007/978-3-030-14899-7_5
68 CHAPTER 5. CONCEPT DEVELOPMENT
Table 5.1: Summary of the concept development stage.
Concept Development: Create a concept for the product and evolve it to have enough information to create basic estimates of cost,
size, weight, and feasibility. Also include subsystem definitions, interface definitions, and target values for performance.
Required
information
See the Opportunity
Subsystem Section A-D of the requirements matrix Development summary for the Complete and
Requirements
requirements for each subsystem checking criteria for appropriate.

requirements matrices.
Consistent with ideal values?
Achievable with the selected
product concept? Target values
Target values for the Consistent with
Section E of the requirements matrix for for all performance measures?
system and the expectations of
the system and all subsystems. Distinction between constraints,
subsystems. market
success measures, stretch
goals? Trade-offs to less than
ideal performance justified?
List, chart, or summary of considered
Justification for
concepts.
concept selection,
Evaluation summary of considered Are the test methods complete
including model The desirability of
Tests
concepts demonstrating feasibility of and correct? Is there enough

analysis and/or the concept is
selected concept. detail for a third party to repeat
prototype test data demonstrated.
Model and/or prototype test reports the tests?
demonstrating
demonstrating the validity of the
concept feasibility.
selected concept.
Low-fidelity fundamental models of the
Rough technical concept’s operating principles. Are the models reported in Not directly
Models
models of the Statistical models describing the enough detail to allow a third approved; used
product concept. performance of experimental party to use them? with tests.
prototypes or related existing products.
Rough prototypes (foamboard, paper,

Prototypes
Simple prototypes of Not directly

foam, clay, cardboard, plywood, etc.) Are the prototypes appropriate
the product approved; used
used to show how the concept for the intended use?
concept. with tests.
functions.
One or more of the following: The design is

Annotated hand sketches of concept. sufficiently
Geometric and other Is the design clearly
Overall system CAD model. Layout transferable to
appropriate communicated? Can a third
drawing. Skeleton drawing. Notes on support cost,
definition of the party understand the intended
sketches/drawings explaining concept. size, weight, and
concept. design?
Block diagrams of electrical or fluid feasibility
systems. estimates.
The
Decomposition of Tree or other relationship diagram that decomposition is
Are the subsystems and their
product concept shows structure of decomposition. List appropriate for
relationships clearly shown?
Design
into subsystems. of subsystems. the selected

concept.
Interface matrix showing where
Is the interface matrix complete?
subsystems interact. Product-focused
Are the interface definitions The interfaces
requirement statements for each of the
Subsystem interface complete? Are the interface are fully defined
interfaces. Performance measures for
definitions. definitions appropriate to and appropriate
each of the interfaces. Subteam
achieve the desired for the concept.
responsibility assignments for each
performance?
interface.
Spreadsheet or database table that lists The bill of
Preliminary Bill of Is the BOM complete at the level
all known components, even if they materials is
Materials. of known detail?
have only a part name at this time. appropriate.
Bill of materials, bio-inspired design, brainstorming, competitive benchmarking, controlled conver-
gence, decomposition, internet research, interviews, literature review, method 635, mind maps, proto-
Useful tools:
typing, recombination table, requirements matrix, scoring matrix, screening matrix, sketching, theory
of inventive problem solving (TRIZ).
Common pitfalls: Concept fixation; premature concept critique; reinventing the wheel; vague interfaces; decision delay.
opportunity for each of the subsystems — the various performance measures will
meaning the requirements, performance become more clear. It is rare that the
measures, requirement-measure concept will be able to achieve the ideal
correlations, and ideal values — is also values for all of the performance
defined. measures. The team will often need to
compromise in one area to achieve ideal
Finally, during this stage the trade-offs values in other more important areas.
between the various market requirements Using rough technical models of the
are considered, and specific target values selected concept (often based on the
for performance measures are chosen. performance of competing products), the
team can choose target values for each of
Development Outcomes the performance measures. In all cases,
Transferable artifacts containing the the target values must be within the
following information must be approved at acceptable limits of the ideal values. In
the end of concept development. some cases, the ideal value will be chosen
as the target. In other cases, due to
trade-offs, the target value will be between
Requirements the ideal and the acceptable limit.
There are two primary elements in the
For example, the human-powered water
requirements for this stage of development.
well drill team selected a concept similar
to that seen in Figure 4.1; for this concept
1. Subsystem requirements the deeper the borehole, the more
Each subsystem has its requirements substantial the structure needs to be so it
defined in the context of the entire system can support the weight of a long drill
to ensure that the combination of string. Consequently, for this design
subsystems will lead to desirable system concept, the deeper the borehole, the
performance. Like the system opportunity, more expensive the structure to support it
the subsystem opportunity comprises becomes. Therefore, when choosing a
requirements, performance measures, target value for borehole depth, the team
requirement-measure correlations, and may choose a depth that is different than
ideal values. However, the opportunity is the ideal value shown in Figure 4.2.
focused on the specific subsystem, rather
than the system as a whole. Can you think of a concept for which
there is no tradeoff between maximum
One important difference in the borehole depth and the cost to
subsystem opportunity definition is the manufacture one drill?
requirements. Rather than using market
requirements, the subsystem opportunity As the team chooses target values for
definition uses selected system performance measures, it can be helpful
performance measures as the subsystem to recognize that peformance measures
requirements, as shown in Figure 5.1. generally fall into four classes: basic
Subsystem performance measures are requirements, constraints, key
chosen to measure the achievement of the performance measures, and stretch goals.
selected system performance measures. A clear understanding of the class of each
The relationships in the opportunity are performance measure can dramatically
relationships between the subsystem affect success in product development.
performance measures and the selected Target values for basic requirements are
system performance measures. important only to the extent that they need
2. Target values for the system and to lie within the acceptable range. Basic
subsystems requirements whose values differ from
ideal have a minimal effect on the
Once an overall product concept is market’s perception of the quality of the
selected, the need for trade-offs between product. Therefore, it is generally not wise
to use significant development effort to development requires more than just a

optimize these values. guess as to the desirability of the concept.
Constraints can usually be recognized by The team must balance the need for
yes/no performance measures. As long as transferability of the evaluation methods
the constraint is met there is not much with the need to evolve the design quickly
concern about how well it is met. and efficiently. As a guideline, the
Therefore the target values for constraints evaluation methods should focus mostly on
are simply yes or no. For example, a car the selected concept, but provide sufficient
designed for the US must meet the rationale for its selection that someone
Federal Motor Vehicle Highway Safety outside the team would support the
Standards in order to be a viable product. selection as appropriate.
During this stage, the concept should be
Target values for key performance tested using prediction or test methods to
measures have a strong effect on the determine how well the concept is
perceived quality of a product. For expected to meet market requirements.
example, fuel economy is a key
performance measure for an economy car.
It represents one of the major criteria Models
customers use to make purchase Rough technical models of the selected
decisions. Hence, an economy car might product concept are helpful in making
have a target value for fuel economy of 45 trade-off decisions and choosing target
miles per gallon. values for performance. These models,
which are often based on evaluation of
Stretch goals are target values for key competitive products in the marketplace,
performance measures that would be define expected relationships between the
amazing to reach, but are somewhat various performance measures for a given
unlikely. In 2019, an electric car range of concept. For example, relationships exist
400 miles between charges would be a between engine displacement, horsepower,
stretch goal. It represents a target that has and fuel economy for various classes of
not yet been achieved, but if achieved it automobiles. These relationships can be
would dramatically increase the electric used to help define the target values for a
car market. new automobile being designed.
Development teams should choose the
key performance measures that will make Prototypes
the biggest difference in market Rough prototypes are often used in the
acceptance for the product. They should concept development stage to
be sure they understand and meet the communicate and explore how concept
constraints. And they should have a ideas function. Prototypes are very helpful
limited number of stretch goals, in order to to get the development team out of the
challenge the team but not distract from virtual world and into the real
the key performance measures. world.
Teams should use prototypes, focusing on
their use to evolve the design (definition of
Tests
the product), rather than making the
As part of the concept selection process, prototyping process or the prototypes
the development team must evaluate themselves the purpose of the product
alternative concepts in terms of market development process.
requirements. Although these evaluation
methods are generally high-level and Design
somewhat qualitative, it is important that
the critical methods be documented in a There are four required design outcomes
transferable way. Effective product for the concept development stage.
Figure 5.1:
Subsystem
requirements
come from
the target val-
ues of system
Units
performance
Units
Units
measures.
Subsystem Performance Measures

Not all system
Subsystem Performance Measures

System Performance Measures
performance
Target Design Requirements Importance
Target Design Requirements Importance

measures ap-
Market Requirements Importance
ply to every
subsystem.
Importance
Importance
Lower Acceptable
Lower Acceptable
Importance
Lower Acceptable
Ideal Values
Ideal Values
Upper Acceptable Ideal

Ideal Values
Ideal
Upper Acceptable
Ideal
Upper Acceptable
SYSTEM SUBSYSTEM 1 SUBSYSTEM 2

REQUIREMENTS REQUIREMENTS REQUIREMENTS
1. Definition of the concept 2. Decomposition of the concept
A product concept describes the means A formal definition of the subsystems

for achieving major market requirements, included in the design permits
where enough detail is provided about the independent work on each of the
spatial and structural relationships of the subsystems. This allows development
principal components and subsystems subteams to work in parallel and
that basic cost, size, weight, and feasibility accelerates product development. At this
estimates can be made2 . The product stage, the product definition includes a list
concept must have a sufficient level of of the subsystems; the subsystems will be
detail to be evaluated relative to the developed fully during subsystem
opportunity. The concept definition often engineering.
takes the form of annotated sketches
(manual or computer-generated) or a It can also be helpful to show a tree or
layout drawing. Along with the graphical other representation of the logical
representation of the concept, notes relationships between the subsystems.
identify key aspects that are not readily
understood from the drawing. 3. Subsystem interface definitions
Where complex functionality is part of the The interfaces between subsystems are
selected concept, a block diagram is often crucial constraints on the design for each
included as part of the concept definition. subsystem. The definition of the
interfaces includes an interface matrix
The concept definition must be clear and that defines which interfaces exist, and an
unambiguous enough to be interface definition for each interface.
understandable to a third party.
An interface definition consists of the
2
This definition is based on that provided by Dym following items (examples of each are
and Little (2008). given in Table 5.2):
• A description of the function that the of materials may only list the names of
interface must provide to each of the major parts. However, it forms a scaffold
components or subsystems involved on which the final bill of materials can be
with the interface. This could be built. It also helps plan the remainder of
expressed in the form of the development process.
product-focused requirement
statements (see Product-Focused Useful Tools
Requirement Statements (11.48) in
the Development Reference) for the During the concept development stage one
interface. final system concept will be selected from a
• Performance measures for the set of candidates. Therefore, the team will
interface functions as available. For need to consider activities for both concept
a complex interface, a full creation and concept selection. We
function-measure correlation matrix recommend that the team consider the use
could be made, following the of one or more of these activities for this
principles of a requirements matrix. stage of development. Most of these
For a simple interface, these activities are described briefly in the
performance measures can be Development Reference. Section 5.4
correlated with a single interface provides insight on how to develop a strong
function. final system concept.
• Responsibility for each of the
For generating concepts: Bio-Inspired
interface functions. In many cases, a
Design (11.4), Brainstorming (11.5),
subteam in charge of one interfacing
Decomposition (11.14), Internet
subsystem will have primary
Research (11.33), Method
responsibility for creating the
635 (11.35), Mind Maps (11.36),
interface definition, and the other
Recombination Table (11.53), Theory
subteam will simply use that
of Inventive Problem Solving
definition in their design. In other
(TRIZ) (11.66).
cases, the interface definition will be
created separately from any of the For selecting concepts: Controlled
subteams developing the interfacing convergence (11.10), scoring
subsystems. Whichever way is matrix (11.59), screening
chosen, the responsibility for defining matrix (11.60), multivoting (11.37).
the interface should be made clear. For establishing target values:
The interface definition is often captured Benchmarking (11.2),
in an Interface Control Drawing (ICD), interviews (11.34), literature review,
which is a formal specification of the internet research (11.33).
interface. The subteam responsible for For general design work: Bill of
defining the interface is the owner of the materials (11.3), prototyping (11.50),
interface control drawing. As with all requirements matrix (11.55),
engineering drawings, the ICD is placed sketching (11.63),
under revision control. All subsystems storyboards (11.64).
using the interface refer to the ICD as part
of the constraints on the subsystem Common Pitfalls
design.
4. Bill of materials • Concept fixation: Avoid fixation on one
concept by thoughtfully exploring
At the end of concept development, major many concepts before converging.
components and subassemblies are Identifying the best concept can only
known. A bill of materials (see Bill of be done in the context of multiple
Materials (11.3) in the Development concepts. Similarly, avoid fixation on
Reference) should be used to track all of one particular class of concepts. For
the information about parts used in the example, avoid considering only
design. In concept development, the bill human-powered water well drill
Figure 5.2:
Early-stage con-
cept sketches for
human-powered
water well drill.
concepts that remove earth using a • Vague interfaces: Be sure to

spinning bit. thoroughly define and control the
interface definitions. Without
• Premature concept critique: Avoid
well-defined interfaces, subsystem
critiquing ideas during concept
teams cannot work effectively in
generation activities. Infeasible ideas
parallel.
can lead to innovative feasible
concepts.
• Decision delay: Set and stick to
• Reinventing the wheel: Avoid aggressive deadlines. Only consider
reinventing solutions that already exist; allowing schedule slippage when
use existing, proven, technologies specific deficiencies are described and
when they are available and suitable. a plan to overcome them is identified.
5.2 Example of Concept principal components and subsystems. To

Development that end, we can see that the design is
evolving to the point that basic cost, size,
To solidify the principles introduced so far weight, and feasibility estimates could be
in this chapter, let’s return to the example made from the design information.
of the human-powered water well drill, the
By the middle of the concept development
details of which are provided in
stage, the concept has indeed evolved, but
Appendix B. We first consider how the
the team was not satisfied with the
design evolved and the state of the design
vulnerability and cost of the bevel gearset.
at the end of this stage.
After various tests, and other research, the
To provide insight regarding the team eliminated the bevel gear concept,
development of the concept, we briefly and moved ahead with the back-up
examine early-stage concept development, concept. The back-up concept as it existed
mid-stage concept development, and near the end of concept development is
late-stage concept development as it shown in Figure 5.4a and 5.4b.
unfolded for the drill team. Figure 5.2
shows four sketches that represent the Importantly, the end of the concept
concept in the early stages of concept development stage requires that the
development. At this point, the transferable product concept be captured in a
design exists only in the form of annotated transferable format. The drill team provided
sketches. These sketches are just a few of a detailed description of the product
the dozens and dozens of sketches created concept and a concept schematic. The
by the team. description is reproduced verbatim below,
and the schematic is shown in Figure 5.5.
The four sketches capture some of the
team’s ideas about how to harness human
power (Figs. 5.2a and 5.2b) and how to cut SELECTED CONCEPT
the earth (Figs. 5.2c and 5.2d), which were
two of many sub-areas the team The selected concept for the human-powered
considered. Although not described here, water well drill consists of five major subsystems:
the team also considered how to allow the (i) turning wheel, (ii) kelly bar, (iii) support tables,
drill string to simultaneously spin and drop, (iv) structural frame, and (v) slurry pump.
how to add additional pipe segments
during the dig, how to retract the drill string When operated, the drill cuts the earth with a
commercial six-inch tri-cone or drag drill bit as it
from the hole, and how to prevent the drill
is rotated up to 30 RPM, depending on the
string from falling back into the hole while
required torque. The added weight of the pipe
bringing it out. (up to 1,800 lb)3 provides natural downward
Using the kinds of activities and tools listed pressure to grind through hard rock. A pump
in Table 5.1 the team evolved the forces a thick slurry (made from water and a
sealant called bentonite) down the pipe and
early-stage concepts into those shown in
back up around it, both carrying out the cuttings
Figure 5.3. We can see in Figs. 5.3a – 5.3c
and sealing the borehole walls with the added
that the team converged on using a bentonite. To add and remove additional pipe,
horizontal bicycle-driven shaft connected to an eight-foot structure is set into place that
the drill string by way of a bevel gearset. At facilitates the use of pulleys and clamps. The
this point in the development process, the selected concept is an integration of professional
team was concerned that the cost of the and homemade systems, as detailed below.
bevel gearbox may make this concept
infeasible, so the team selected a second The wheel consists of eight spokes that come out
concept as a backup (Figure 5.3d). of a steel plate in the middle, as shown in
Figure 5.5. The spokes are one-inch square
The details in the renderings, though still
somewhat abstract, are about the main 3
As shown in an appendix provided by the team, but
spatial and structural relationships of the not reproduced in this book.
5.2. EXAMPLE 75
Figure 5.3: Mid-

stage concept
renderings for
human-powered
water well drill.
steel tubing providing strength as well as ease in welded inside it. This makes it possible to screw
welding them to the plate. The spokes are into the other sections of pipe. The kelly bar fits
connected at the outer ends by more steel through a square hole in the middle of the steel
tubing, creating a circular wheel six-feet in plate of the wheel, allowing it to turn as the wheel
diameter with twelve evenly spaced pegs around is turned, thus turning the pipe as well. While
the outside. This diameter and number of pegs the wheel rests on a simple thrust bearing on top
allows for several people to operate, or turn, the of the table to minimize friction, the kelly bar and
drill comfortably at a sufficient RPM without pipe move downward through the square hole as
having to walk around in circles, based on the drill cuts the earth. This allows the drill to be
preliminary testing. turned and dropped simultaneously in a very
simple manner without gears or complex
The kelly bar is a five-foot long section of
components.
four-inch square tubing that has a section of pipe
Figure 5.4: Late-

stage concept
renderings for
human-powered
water well drill.
The abovementioned table is at a height of three plate is made up of a web of steel strips instead
feet, supported by eight braces which are of a solid plate, as seen in Figure 5.5.
connected to a three-foot square base plate on
the ground. Based on a standard human height When the pipe needs to be lifted, the wheel is
and comfortable range of motion, this height is removed, and the structural frame is attached to
ergonomically optimal for the operators, and also the base plate. The cylindrical supports of the
allows the structure to be short enough for frame fit into hollow, cylindrical sections sticking
mobility, structural integrity, and the desired low out of the corners of the base plate. The top of
cost. Another, smaller, table is connected to the the structure is held together by a single steel
base plate at a height of eight inches to support piece with hollow cylindrical sections that slip
the clamps that hold the weight of the pipe over the top of the supports. This design makes
during its removal. To reduce cost and weight the structure extremely simple to assemble and
while maintaining necessary strength, the base disassemble while still being sturdy. The
5.2. EXAMPLE 77
Figure 5.5: Drill

structure top schematic, as
produced by
kelly bar the team at the
pulley 4X
hose end of concept
development.
rope
swivel attachment
steel wheel
steel base
kelly bar clamp

pump
structure shafts
plywood hose stand

foundation
drill pipe
structure incorporates a pulley system in which nearby trough back down the center of the pipe
two or more people pull in opposite directions in to lift out the cuttings as the drill digs through dirt
order to lift out the thousands of pounds of pipe and rock. A treadle pump is selected because it
with relative ease. The combined impact of the utilizes the operator’s body weight to create the
pulleys will reduce the required lifting force to necessary pressure and volumetric flow rate
1/16 of the actual weight of the pipe. Therefore, down the pipe, and is based on common treadle
the lifting burden for each individual is at pump designs that are currently made and used
maximum 115 pounds (based on 2 operators). in developing countries.
Once a five-foot length of pipe has been drilled The system described above is a combination of
into the ground, the entire drill pipe assembly is the professional drilling technology with the
lifted up and clamped in place. The kelly bar is manual and inexpensive nature of homemade
removed from the top pipe, a new pipe is added drilling systems. Designed for developing
on top, and the kelly bar is attached to the new countries, it utilizes a nearly tool-less assembly
pipe. When the pipe is again lowered into the and relies heavily on welding which is virtually
borehole, the kelly bar will have its full length to available all over the world. Due to the trade-off
travel down through the square hole as it rotates. between torque and angular velocity and the
The process to remove the pipe is simply the average capacity of human power output, the
reverse, and the pipe is continuously pulled up, drill is capable of supplying up to 30 RPM at 150
rather than up and down. It is estimated that if ft-lb. or up to 1,500 ft-lb. at 2.5 RPM.
the device drills eight feet each day (as Depending on the attributes of the current soil or
suggested by the client), this process of adding a rock formation, the operators can easily adapt
new pipe will only occur at most twice a day. the input to continue the drilling process4 . The
The final component of the selected concept is a
slurry pump that is used to pump the 4
The team also provided more details and graphs on
re-circulated water-bentonite slurry from a horsepower requirements in an appendix.
selected concept is a product of months of center portion of the matrix shows which
iterative concept ideation, modeling, analyzing, subsystems have defined interfaces with
and selection, all centered on the market other subsystems. These are represented
requirements and performance measures. The by the dot. For each dot in the matrix, an
selected concept is a powerful solution to the interface definition is created.
client’s needs.
Wheel Support
Check the design. Does the above
Pump System
concept description together with the
Drill String
concept schematic (Figure 5.5) and
Wheel
Hoist
renderings (Figure 5.4) unambiguously
define the spatial and structural
Drill String
relationships of the principal components
Hoist
and subsystems? Has a justification been
provided that describes why the selected Wheel
concept has strong potential to meet the Wheel Support
opportunity? Is the concept transferable; Pump System
could it be transferred without confusion
to another team for further development?
How would you improve the desirability or Figure 5.6: Interface matrix for drill. This matrix
transferability of the design? shows which subsystems have interface require-
ments with other subsystems.
In addition to the product concept, a
decomposition is required as part of the
system architecture. The team chose to Table 5.2 shows a sampling of the interface
structurally decompose the drill into the definitions for the drill.
following major subsystems, as shown in
Figure 5.7: With the decomposition in hand, the team
defined the subsystem opportunities in a
set of subsystem requirements matrices. To
• Drill string — includes kelly bar, drill illustrate how this was done, we’ve provided
pipe, drill bit three subsystem requirements matrices for
the drill. They are shown in Figs. 5.8–5.10.
• Drill string support and lift structure
To create these matrices, the team started
(hoist) — includes the structure that
by examining the list of target performance
can support the weight of the pipe,
measures from the system requirements
and the mechanism for providing
matrix and determined which ones applied
humans with mechanical advantage to
to each subsystem. They then created a
lift and lower the pipe with relative ease
requirements matrix for each subsystem,
• Wheel — includes just the wheel where the applicable system target
performance5 was listed as a requirement
• Wheel support — includes whatever of the subsystem matrix6 as shown in
keeps the wheel at an optimal height Figure 5.8. The same procedure used to
determine performance measures for the
• Pump system — includes the pump,
system was used to develop subsystem
hoses, filters, pumping fluid, and chip
performance measures for each system
separation scheme
target. Units, ideal values, and target
values are chosen for each subsystem
To facilitate the independent development performance measure.
of each subsystem, the interface
requirements must also be established and 5
Sections B and D of system-level requirements
adhered to by the developers of each matrix.
subsystem. To do this, the team created an 6
Section A of the subsystem level requirements
interface matrix, shown in Figure 5.6. The matrix.
5.2. EXAMPLE 79
Figure 5.7:
Human Powered Water Well Drill
Structural de-
composition of
the drill.
Drill String Hoist Wheel Wheel Support Pump System
Kelly Bar Structure Pump
Drill Pipe Mechanism for Hoses
Mechanical
Drill Bit Filters
Advantage
Fluid
Chip
Separation
Scheme
Table 5.2: A sample of the interface definition for the drill. Although the team did not create them, it would have been
helpful to have an interface control drawing for each of the interfaces defined in this table.
Interface Interface Functions Performance Measures Responsibility

Between
Drill string and Maintain pressure Pressure drop < 1 psi Pump system team
pump system
Accommodate flow Flow rate 30 – 50 gpm Pump system team
Attach to drill string 2 inch female NPT Drill string team
Allow relative rotation Up to 30 RPM, < 2 lbf-ft of Pump system team
between string and pump torque
Attach to pump system 1.5 inch female NH or NST Pump system team
Drill string and Transmit torque Up to 1,500 lbf-ft Drill string team
wheel
Allow axial motion Maximum of 10 lbf of force Drill string team
Drill string and Support drill string weight Up to 1800 lbf Drill string team
hoist
Connect to hoist, fit with Opening diameter ≥ 1.5 Hoist team
hoist hook inches
Wheel and wheel Minimize torque loss < 2 lb-ft at 30 RPM Wheel support team
support
Maintain drill string location Center moves < 0.5 inches Wheel support team
during use
The set of requirements matrices (including Because of space limitations, they are not
any updated/refined requirements shown in a requirements matrix, but they
matrices) represent the evolved state of the were added to the requirements matrix
requirements. During the concept after the final concept was selected during
development stage the system the concept development stage.
requirements matrix also evolves. New
market requirements may be identified, Both the design and the requirements were
ideal values may be refined, and more. At a checked and tested by the team, and
minimum, target values are added for each approved by the client. The transferable
performance measure after the final nature of the concept description, the
concept is selected. The target values for concept schematic, and the requirements
the drill system are shown in Table 7.2. matrix facilitated the approval process.
10 Drill is attractive
Product: DRILL
80
11 Drill interests investors

Target Design Requirements
1 Borehole depth of 220 feet
Subsystem: STRUCTURE
3 Downward drilling force of 500 lbs

4 36 feet depth cut per 8 hours drilling
6 Longest dimension less than 96 inches

7 90% of drill manufacturable in Tanzania
9 Less than 8 hours to learn how to use the drill

8 $1500 USD produce 1 drill after development
5 Weight of heaviest assembly less than 200 lbs
2 Time 60 minutes to drill though 6 inches of rock
Ideal Values
Importance
Importance
4
9
9
9
9
9
9
3
9
12
10
Upper Acceptable Ideal Lower Acceptable Subsystem Performance Measures Units
50,000 25,000 – 9 1 Maximum stress in structure at twice the borehole depth psi
– 4,500 2,250 9 2 Rating of mechanism used to lift twice the full pipe weight lbs
50,000 25,000 – 9 3 Maximum stress in structure during drill pipe change over psi
– 3,000 500 10 4 Downward drilling force lbs
– 4 1 19 5 Rate of drill string decent ft/min
200 50 – 19 6 Weight of heaviest structure welded sub-assembly lbs
Figure 5.8: Subsystem requirements matrix for structure subsystem.

96 84 – 9 7 Length of longerst structure after development in
– 100 90 9 8 Percentage of structure manufacturable in Tanzania %
Percentage of mechanical advantage mechanism
– 100 0 9 9 %
manufacturable in Tanzania
1,000 750 – 9 10 Cost to produce structure after development USD
100 30 – 9 11 Number of parts in structure subsystem
240 60 – 9 12 Time required to learn to set up the structure min
240 60 – 9 13 Time required to learn to attach an auxilliary subsystem min
Drill has a professional Drill looks like a piece of
– look. People are interested 4 14 Structure is attractive
machinery for drilling n/a
in looking at it. holes.
The drill, when explained
attention. Investors are 15 Structure interest investors
– to investors, is something 12 n/a
they want to invest in.
CHAPTER 5. CONCEPT DEVELOPMENT
11 Feels comfortable
5.2. EXAMPLE
Product: DRILL

Subsystem: WHEEL
3 36 feel depth cut per 8 hours drilling

2 300 ft-lbs applied torque to the drill string
4 4 people maximum required to use the drill

1 Time 60 minutes to drill through 6 inches of rock
Ideal Values
Importance
Importance
4
1
10 Height of hand operated parts to be between 2 and 5 feet 1
9
9
9
9
9
9
3
12
10
10
– 30 3 13 1 Spinning speed RPM
– 8 6 19 2 Wheel diameter ft
50,000 25,000 – 10 3 Maximum stress in wheel with 600 ft-lbs torque applied psi
50,000 25,000 – 10 4 Maximum stress in handle with 600 ft-lbs torque applied psi
– 45 30 9 5 Distance between handles deg
Figure 5.9: Subsystem requirements matrix for wheel subsystem.

200 50 – 9 6 Weight of heaviest welded wheel assembly or component lbs
96 48 – 9 7 Longest dimension of welded wheel assembly ft
– 100 90 9 8 Percentage of wheel manufacturable in Tanzania %
300 100 – 9 9 Cost to produce one wheel after development USD
240 60 – 9 10 Time required to learn to put wheel tolerance min
240 60 – 9 11 Time required to learn to add the wheel to the support min
240 60 – 9 12 Time required to learn how to spin the wheel efficiently min
– 41 39 2 13 Height of lowest point to grab handle (center of palm) in
48 44 – 2 14 Height of highest point to grab handle (center of palm) in
Drill can be operated Drill can be operated with n/a
continuously without the occasional rest, and requires
– need to rest. Does not awkward movements that
1 15 Feels comfortable
81
Drill has a professional look. Drill looks like a piece of n/a

– People are interested in machinery for drilling holes. 4 16 Wheel is attractive
looking at it.
Drill captures media n/a

attention. Investors are
– investors, is something they 12 17 Wheel interests investors
want to invest in.
Product: DRILL
82

1 36 feet depth cut per 8 hours drilling

Subsystem: WHEEL SUPPORT

Ideal Values
7 Height of hand operated parts to be between 2 and 5 feet

Importance
Importance
4
1
9
9
9
9
9
3
12
– 16 1.50 12 1 Size of access area to borehole ft^2
100 25 – 9 2 Weight of wheel support lbs
96 36 – 9 3 Longest dimension of wheel support in
– 100 80 9 4 Percentage of wheel support manufacturable in Tanzania %
200 100 – 9 5 Cost to produce the wheel support and connections USD
240 30 – 9 6 Time required to learn to put wheel support in place min
Figure 5.10: Subsystem requirements matrix for wheel support subsystem.

240 30 – 9 7 Time required to llearn to remove the wheel from the support min
240 30 – 9 8 Time required to learn to add the wheel support to the structure min
- 1.5 3.5 1.5 1 9 Height of wheel support, where wheel is supported ft
continuously without the n/a
– need to rest. Does not
occasional rest, and requires 4 10 Wheel support is attractive
awkward movements that
Drill has a professional look.
People are interested in Drill looks like a piece of
– 4 11 Wheel support style matches the rest of the drill n/a
looking at it. machinery for drilling holes.

attention. Investors are The drill, when explained to
– investors, is something they 12 12 Wheel support makes the drill interesting to investors n/a
Drill has iconic look. want to invest in.
CHAPTER 5. CONCEPT DEVELOPMENT
5.2. EXAMPLE 83
From models, prototypes

Opportunity Compare
12
requirements
7 9 13 14
Create
candidate
solution set 10 16
8 11 Select
1 Predict/measure 15
concept
performance
team
Create supports
needed test prototypes models 23 Formalize
Reduce to procedures epts preliminary
tractable conc 22 24 cost models
concept set Formalize
6 predicted Formalize
Select concepts performance preliminary
Combine/improve worth testing technical
concepts Make models
2 4 tradeoffs and
30 choose target
5 25 values
Seek
18
schedule BOM
3 27
26 19 17
Formalize
geometric
33
Develop
32 opportunity and
engineering
To Subsystem
Engineering
Establish interface
requirements and
responsibility
OUTCOMES
3 Concept ratings Concept evaluations Predicted performance of concept

14 25

17 Final concept 28
7 concepts
21 Design 32
Figure 5.11: Top-level activity map for the concept development stage.
5.3 Top-Level Activity Map for preliminary Bill of Materials (Outcome 18),
Concept Development the geometric and/or logical design of the
system (Outcome 19), and a selection of
Starting with the approved opportunity from subsystems to be engineered in parallel
the previous stage, a top-level activity map (Outcome 20). These three outcomes
for the concept development stage is constitute the design for concept
shown in Figure 5.11. development (Outcome 21).
The first half of the diagram (Outcomes With the subsystems identified, we are
1-17) focuses on developing a strong ready to complete the requirements by
concept (Outcome 17) for the overall establishing the interface definitions
product. Converging on a strong product (Outcome 28) and the subsystem target
concept is perhaps one of the most values (Outcome 27). Together with system
important parts of the product development target values and predictions of
process as it determines what will be performance, these constitute the
involved in finishing the design. Because it requirement information for the concept
is so important, the top-level activity map is development stage.
relatively detailed. With the approval information complete,
Concept development begins with stage approval can be sought. Note that
generating a candidate solution set stage approval may be an iterative process,
(Outcome 1) and refining through requiring updates to any or all of the
evaluating and reducing the set to a approval information.
tractable number (Outcome 2). Concepts Although this activity map has many
are rated, combined, and improved to details, we can recognize that it is high-level
arrive at a rated concept set (Outcome 5). because most of the activities in the map
From this rated set, a smaller set is are general activities. In order to use this
selected for testing with models and map on a project, the general activities
prototypes (Outcome 10). The models and must be made more detailed and specific
prototypes are used to predict and measure to a unique project by at least one level.
performance of the concept, which is
compared with the requirements, and used
to further refine the concepts (Outcome 5.4 How to Develop a Strong
16). Finally, the team selects a concept to Concept
carry forward to further development
(Outcome 17). At virtually any stage of the product
Note that a team will develop strong development process, when we need an
concepts many times during product optimal way to meet a critical design need,
development, including concepts for we are likely to use the pattern of
subsystems. A more generic process, along developing a strong concept. The purpose
with some key methods, for developing of this section is to show how to develop a
strong concepts, is discussed in strong concept to meet a design need.
Section 5.4. A concept is an idea for solving a design
Once a concept has been selected, it is need that includes a description of the main
time to formalize the required information operating principles, major components,
for approval. This includes preliminary and structural, logical, and operating
technical and cost models (Outcomes 22 interfaces between the components.
and 23) that can be used to establish A strong concept is a concept that has
trade-offs for selecting target values been rated as superior to any other known
(Outcome 26) and provide preliminary concept, with specific advantages and few
predictions for key performance measures or no disadvantages. It has been selected
(Outcome 25). We also formalize a
5.4. HOW TO DEVELOP A STRONG CONCEPT 85
as a concept that is more likely than others concept set. Shah et al. (2003)7 describe
to lead to desirable performance. four attributes of a concept set that can be
evaluated to assess its appropriateness:
There are five fundamental steps in concept quantity, concept variety, concept
developing a strong concept. These steps novelty, and concept quality. Three of these
are shown in Figure 5.12. The first is to attributes are illustrated in Figure 5.13.
create a quality set of potential concepts
(using creating activities). The second is to Ultimately we want to know that we have
reduce the relatively large set of concepts considered a sufficient number of
to a smaller set that can be analyzed in candidates of sufficient quality, variety, and
more detail (using evaluating and deciding novelty. Critical parts of the design should
activities). The third and fourth steps result have large number of candidates with high
in interdependent outcomes. The third step quality, variety, and novelty in the concept
is to rate each remaining concept set. Mundane parts, however, can have
according to how well it meets the design lower quantity, less variety, less novelty, and
needs (using evaluating activities), and the acceptable quality in the concept set.
fourth step is to combine highly rated
concepts or parts of concepts with others to In order to evaluate variety and novelty, it is
create improved concepts (using creating useful to classify concepts along one or
activities). The interdependence of the more design axes. These axes represent
outcomes means that we will ideally different dimensions that could be chosen
continue to rate and improve the set of to capture general characteristics that differ
candidates until no better concepts are between the concepts. There is no “right”
found. The final step is to select the best set of axes to use for a given design. It is
concept (using deciding activities). sufficient to note that as a team thinks
carefully about their design, it is likely that
axes will become apparent. Shah et al.
A. Create Candidate Solution Set (2003) propose that often there will be axes
One of the challenges of product that include physical principles (weight,
development is determining what the best length) and working principles (combustion
possible design is. It’s important to engine, electric motor).
recognize that the best design can only be
One of the tools used to classify concepts is
identified in the context of multiple designs.
a concept classification tree8 . A concept
For this reason it’s essential that we create
classification tree graphically presents the
a set of potential solutions, rather than just
different branches explored when
a single solution.
generating alternative solutions or
concepts. In addition to providing a
Concept set quality: Given that we can measure of variety, the concept
only do comparative rating of concepts, it is classification tree may provide additional
important to have a good set of concepts ideas by highlighting branches that are not
with which to make comparisons. It’s not sufficiently explored.
saying much to affirm that a concept is the
best of two alternatives. It’s somewhat A concept classification tree used by the
better to say that it’s the best of ten human-powered drill team is shown in
alternatives. It’s better still to say that the Figure 5.14. Note that although the team
concept is the best of fifty alternatives that had as their primary focus the creation of a
have spanned the design space, including human-powered drill, during concept
some that have pushed the boundaries of
7
current knowledge. This paper also includes a quantitative
method for evaluating novelty, variety, and qual-
If the rating of the concepts can be no ity. As of July 2013, the paper is available on-
line at http://w.ecologylab.net/research/publications/
better than the quality of the concepts ShahVargas-HernandezSmith2002.pdf
against which they are rated, it is important 8
See Concept Classification Tree in the Development
to evaluate the appropriateness of a Reference.
Rate concepts
based on
requirements,
3
feasibility,
resources,
schedule
Create Reduce to Select the
candidate tractable strongest
Needs for design solution set concept set concept To next design
opportunity 1 2 5 6 activity
Combine and
improve
concepts
4
OUTCOMES
1 Candidate solution set 3 Ratings for each candidate 5 Set of rated concepts
2 Reduced candidate solution set 4 Improved concept set 6 Selected concept
Figure 5.12: Typical activity map for developing a strong concept.
Figure 5.13: Factors determining QUANTITY VARIETY NOVELTY

solution set adequacy. Black lines
represent the borders of the known
design space and dots represent
candidate solutions. Candidate set
quantity is the number of distinct
LOW
candidate solutions. Variety is an in-
dication of how broadly the design
space has been explored. Novelty is
a measure of how the design space
has been expanded. Although not
illustrated here, quality is an evalu-
ation of how well the candidate solu-
tions meet the needs of the design.
HIGH
creation they expanded their thinking to Creating the solution set A solution set
consider solar power as a potential energy should be developed using the methods
source. Perhaps their solution set would similar to those described in Section 3.3.
have been even better had they considered The solution set should have appropriate
wind and rain as potential energy sources quality, quantity, variety, and novelty, as
as well. By placing the concepts in a tree described above.
that shows logical relationships, we can see
Deciding when the solution set is sufficient
areas that could profitably be explored
requires the use of judgment. Certainly, the
more fully.
more critical the design problem is to the
5.4. HOW TO DEVELOP A STRONG CONCEPT 87
Figure 5.14: A
Obtain Energy
concept clas-
For Drilling
sification tree
for the harness
energy sub-
function of the
Harness Solar
human-powered
Human Power Power
drill.
Body Stays Body

Pendulum
In Place Moves
Stationary Rowing Railroad Pull on Hand Walk in

Falling Jumping Climbing
Pedaling Machine Pump Rope Crank Circle
overall product, the more challenging it is matrix9 or a Pugh concept selection

to converge on a good solution, as higher matrix10 . The market requirements11 are
levels of quantity, quality, variety, and listed as labels for the matrix rows. The
novelty in the solution set will likely be concepts under consideration are listed as
needed. Short-circuiting the solution set labels for the matrix column, with a
creation process may lead to missing an reference or benchmark concept listed in
ideal solution. Prolonging the solution set the first column. The choice of the
creation process may put the overall reference concept is up to the team. It is
development project behind schedule. often the lowest-risk or least novel concept
in the set.
Once a solution set is deemed appropriate,
reduction of the solution set is undertaken. With the market requirements and the
concepts in place, ratings are then given to
each of the concepts for each of the market
B. Reduce the Candidate Solution Set requirements. First, the column of the
If an excellent job of solution creation has reference concept is filled with “=,”
been done, there will likely be too many meaning “the same as the reference.”
concepts to thoroughly evaluate all of them. Then, working row by row, each concept is
Therefore, some form of intuition-based compared with the reference concept to
evaluation is generally done to select see how well it will meet the market
approximately 5-15 concepts from the requirement. The concept will be given a
larger solution set. One common method of “+,” “=,” or “-” if it is better than the
eliminating less-promising candidates is reference, the same as the reference, or
multivoting (Multivoting (11.37) in the worse than the reference at meeting the
Development Reference). market requirement.
Once the solution set has been pared to a Although it may seem like a small detail, it
reasonable size, a more formal and is important to move row by row, rather
thorough evaluation can be undertaken. than column by column, through this
evaluation process. Two important
C. Rate the Concepts 9

See Screening Matrix (11.60) in the Development
Reference for more information
When the potential solution set has been 10
See Controlled Convergence (11.10) in the Devel-
reduced to a tractable number of concepts, opment Reference
11
the concepts are placed in a screening Section A of the requirements matrix.
objectives are met by moving row by row. now choose the best concept. The best
First, it is much easier to be consistent in concept is not necessarily the one that has
the evaluation of a particular market the highest score from the screening
requirement if all the concepts are matrix. In fact, it is possible that several
evaluated at the same time. Second, concepts will have equal scores. In addition
moving requirement by requirement helps to the market requirements, there are likely
prevent gamesmanship in artificially raising to be other criteria that may be important to
or lowering scores for specific concepts. the team. These other subjective
requirements should also be considered.
After all of the market requirements have
been considered, the ratings of each When the best concept is selected, the
concept are summarized at the bottom of team should be able to identify why the
the matrix. The number of pluses, concept is superior without referencing the
minuses, and equals in each column is score on the screening matrix. The
counted, and a net score is calculated as strengths of the concept should be clear,
the difference between the number of and should be easily listable by the team.
pluses and the number of minuses.
Having selected a best concept, the concept
D. Combine and Improve Candidates should be evaluated to see if the team really
believes it is strong enough to proceed
If the ratings indicate that one concept is to further development. If so, the concept
clearly superior, it may be selected. In most creation activity is complete. If not, the
cases, however, there will be no single concept creation activity should be iterated
concept that is clearly superior. Each in order to develop a stronger concept.
concept will have its strengths and
weaknesses. The next step is to try to
combine concepts with complementary 5.5 How to Generate Concepts
strengths to see if a combined concept can
be created that is better than either of the Generating concepts for products can be
original concepts. The lowest-rated one of the most rewarding parts of product
concepts are then removed from the development. There are two general
matrix, the new concepts added, and the methods of generating concepts: exploring
rating process repeated. existing solutions and creating new ideas.
As the number of concepts is reduced Existing Solutions

through eliminating weaker concepts, the
level of detail for both the concepts and the The world is exploding with products to
evaluation is increased. Some practitioners meet the needs of billions of people.
recommend that for final concept selection Ignoring the existence of these solutions
a concept scoring matrix is used. This when trying to solve design challenges
chapter does not describe the use of a almost certainly guarantees the
concept scoring matrix, but the development of products with one or more
Development Reference does. substantial flaws. At the least, it guarantees
that development will take unnecessary
Figure 5.15 shows an intermediate concept
time and resources.
screening matrix for the harness energy
subconcepts for the human-powered well Existing solutions are helpful to a
team. Note that some concepts are rated development team in at least two ways.
poorly and scheduled for elimination, while First, an existing solution may be able to be
others are scheduled for combination or used as-is or with minimal modification as a
further research and evaluation. component for a newly developed product.
Second, an existing solution may be used
E. Choose the Best Concept as the basis for a new design.
Having evaluated all the concepts relative In order to use existing solutions, relevant
to the market requirements, the team must solutions must be found. We present three
5.5. HOW TO GENERATE CONCEPTS 89
Figure 5.15:
Rota-
Sludge People Concept screen-
Tugging Stationay Rowing Railroad Climbing Hand Solar
(Bench- Walking
with Rope Pedaling Machine Pump or Falling
Pendulum
Crank Power
ing matrix for
mark in in Circle harness energy
Market Requirements Tanzania)
subconcept for
Torque = + + + + + + + + = human-powered
Speed = + + + + + + = + + drill. This matrix
No. People = – – – – + – + + + was created
Simplicity - Device = + + – – – – – – – in the middle
Simplicity - Use = + + + + + + + + + of the concept
development
Manufacturability = + + – – – – – – –
stage.
Stationary = – – + + = – = = +
Body Stress = – – – – – – + – +
Size = + + = = – – – = =
Number of +’s 0 6 6 4 4 4 3 4 4 5
Number of =’s 9 0 0 1 1 1 0 2 2 2
Number of –’s 0 3 3 4 4 4 6 3 3 2
Net Score 0 3 3 0 0 0 –3 1 1 3
Keep
Decision Keep Combine Keep Discard Discard Discard Discard
Research Combine
commonly used methods for finding One potential problem with internet
existing solutions, each of which is searching is the assumption that all the
explained more fully in the Development good information is on the first few pages
Reference. returned. In some cases, later pages have
the best solutions. Deciding when it’s time
to end a search requires good judgment.
Internet Search
Perhaps the most commonly used method Catalog Search
of finding existing solutions is a search of Catalogs are another source of existing
the internet. Internet search engines can solution ideas. Catalogs are available both
return millions of hits for a given topic. One online and in paper copies. Paper catalogs
of the greatest challenges can be are often easier to browse through than
separating the desired information from the electronic catalogs, while electronic
noise. catalogs are often easier to search for
specific items.
As an example of the value of an internet
search, a project was recently proposed to Catalogs from specific manufacturers, such
develop an improved portable dental chair as Timken for bearings or Suspa for gas
by modifying an existing chair. A Google springs, generally contain the most specific
search of “portable dental chair” returned information and are very helpful for details
806,000 results. On the first page of the when a concept has been chosen.
results there were images of at least seven Catalogs from distributors, such as MSC or
different commercially available chairs. McMaster Carr, contain a wide range of
There were three different sellers of products and may be useful for browsing
multiple chairs. There was an article just to see what is available.
written by a non-profit world dental
organization that described the strengths Catalogs for consumer, rather than
and weaknesses of various commercial industrial, products are often very helpful in
chairs. In less than five minutes, the finding ideas that can be used as the basis
searcher obtained a good understanding of for a design solution, even though the
the existing solutions. product itself is unlikely to be used.
Delphi Method it would have to use the competitor’s

design. This provided a great source of
The Delphi method is based on motivation, inspiration, and creativity.
interpersonal networking. The person
looking for an existing solution finds a few
people who might have ideas about such a Creating New Ideas
solution. Each of these people is contacted,
and asked about solution ideas. At the end There are many activities for creating
of the interview, the person is also asked for candidate solutions to design problems.
the contact information of other people who Brainstorming is undoubtedly the most
might have solution ideas. often referred to creation activity12 . While
brainstorming is generally useful
The Delphi method is helpful because you throughout the product development
are drawing on the expertise of others process, other methods can also be useful.
without making large demands on their A list of typical creation activities for each of
time. Using only a few minutes from any the stages of development is shown in
one person, the team is able to get access Table 5.3. More information about most of
to a broad collection of expertise. The these activities can be found in the
results from the Delphi search are often Development Reference.
used as a starting point for internet or
catalog searches. The Delphi method was described
previously as a method for discovering
Design Benchmarking existing solutions. If the persons being
interviewed are asked about ideas they
An effective method of evaluating might have for new solutions, rather than
competitive products is design existing solutions, the Delphi method
benchmarking. In design benchmarking, becomes a method for creating candidate
the team discovers how competitive solutions.
products have been designed to meet the
market requirements. This not only
provides the development team with great Decomposition and Recombination
ideas, it also sets a target for the team to Often a design problem is sufficiently
beat. complicated to require concepts in multiple
To perform design benchmarking, the areas in order to define an overall solution.
development team purchases competing In this case, an effective tool for helping
products and disassembles them. Products with concept creation is decomposition and
are analyzed to determine how each of the recombination.
functions are delivered. Estimates of the
manufacturing cost and reliability are made When using this tool, the overall product is
for each of the parts and assemblies. The broken down into manageable pieces.
disassembled products are often attached Ulrich and Eppinger (2012, pp. 120–124)
to visible display boards. recommend functional decomposition,
although they also describe decomposition
The designs judged best in terms of quality, by user actions and by market
manufacturability, and reliability become requirements.
the standards against which all of the
team’s design ideas will be judged. This Once the product is decomposed, idea
helps prevent the creation of inferior generation occurs for each of the pieces.
designs. We term a concept for solving only one
piece of the product a subconcept. Each
One world-class development organization subconcept set can be evaluated for
required development teams to perform
competitive benchmarking for every 12
Kelley and Littman (2001) provide seven rules for
project, with a strict injunction that if the effective brainstorming. Also see Brainstorming (11.5)
team could not develop a superior design, in the Development Reference for more information
5.6. SUMMARY 91
Table 5.3: Typical creation activities used in various development stages.

Brainstorming Brainstorming Brainstorming Brainstorming Brainstorming Brainstorming

Delphi Method Bio-Inspired Bio-Inspired Recombination TRIZ TRIZ
Designs Designs Tables
Method 635 Synectics CAD
Gallery Method CAD
Synectics QFD
Recombination
Tables
Function
Structures
novelty, variety, and quantity13 . It may be The use of decomposition and

difficult to evaluate the quality of an recombination in concept creation can
individual subconcept since product greatly improve the candidate solution set.
performance depends on the integration of
multiple subconcepts.
5.6 Summary
When subconcept sets have been
developed for each of the pieces, complete During the concept development stage, the
concepts are developed by combining one team formalizes the architecture of the
of the subconcepts from each piece. It may product. This includes not only generating
be possible to get multiple concepts from and selecting a concept, but also
one combination. decomposing that concept into major
components or subsystems with defined
The total number of possible combinations interfaces and performance expectations
is the product of the number of ideas in (as laid out in the opportunity definition).
each of the sub-areas. This is not the same To do this, the team will need to both
as the number of concepts developed, for generate and evaluate candidate concepts.
two reasons. First, not all of the Concept generation and evaluation tools
combinations are guaranteed to be can help improve the quality of the concept
feasible. Second, as mentioned earlier, set and the strength of the final concept.
there may be more than one concept for a
given combination. The top-level activity map provided
includes developing a strong concept,
The human-powered drill team developing preliminary technical and cost
decomposed their problem into a number models, developing target values for the
of areas. Two of the most important were system, identifying subsystems and their
harnessing energy and cutting earth. For interfaces, and defining opportunities for
each of these areas, the team developed the subsystems.
ten ideas to evaluate thoroughly. The ten
ideas in each of two areas provide 100 Two of the main messages in this chapter
different combinations. Not all of the are that (i) the act of developing a strong
combinations were turned into concepts by concept is one of the most important things
the development team. we do during product development, and (ii)
developing that concept requires us to gain
13
An approach for evaluating a concept set is de- a rough understanding of what the major
scribed more fully in Section 5.4. components or subsystems are and how
they need to perform in order for the whole b) Create a scatterplot of market
concept to be desirable. These two performance vs. performance
messages are essential, because they lay measure value for each of the
the ground work for the next stage of linkages shown in the House of
development, which is the subsystem Quality. Based on the
engineering stage. scatterplots, propose ideal and
marginal values for the criteria.
5.7 Exercises A5-3 Imagine you have been assigned to

develop a new system for sharpening
Test Your Knowledge kitchen knives. The system should
be usable by a homeowner.
T5-1 List five main elements of a a) Find six existing sharpening
high-quality system architecture. systems by internet search.
T5-2 List the required content of the b) Find two existing sharpening
requirements, tests, and design at systems by the Delphi method.
the end of the concept development A5-4 Review the classification tree for the
stage. human-powered drill, found in
Figure 5.14. Add a new branch and
T5-3 List three elements of an interface
three concepts somewhere on the
definition.
tree.
T5-4 List five fundamental steps in A5-5 Generate a candidate solution set for
developing a strong concept. the problem of storing a snowboard
or a surfboard in an apartment.
T5-5 List four attributes that can be
evaluated to assess the adequacy of a) Develop a concept classification
a concept set. tree for the concepts in the
solution set.
Apply Your Understanding b) Assess the quality, novelty,
variety, and quantity of your
A5-1 In your own words, define a strong solution set.
concept. c) Do an intuition-based evaluation
of the concepts. Are there any
A5-2 Evaluate some existing products that you believe are promising
relative to the performance measures to undergo further
in Exercise A4-6. Also, see if you can development? Why?
obtain market performance
d) Decompose the problem of
information about the evaluated
storing a snowboard or
products.
surfboard in an apartment into a
set of subproblems.
a) Create a “House of Quality” (see
Quality Function Deployment a) List the subproblems.
(11.51)) with the market b) For each subproblem,
requirements from identify four possible
Exercise A4-5 and the solutions.
evaluation criteria from c) By combining one solution
Exercise A4-6. Place the market for each subproblem,
performance information and create five concepts for
the evaluations relative to the storing a snowboard or
criteria in the House of Quality surfboard. Describe each
for the products you have concept in words and
evaluated. sketches.
5.7. EXERCISES 93
A5-6 Using the recombination table from

page 272 in the Development
Reference, generate and sketch 4
new concepts for a bicycle-like
human transportation device.
A5-7 Thoughtfully prepare a screening
matrix to evaluate a small set of
promising concepts.
a) How did the matrix influence
your choice regarding which
concepts to continue
developing?
b) What insights about your
concepts did the matrix help
you see, if any?
c) In your own words, describe the
risks you feel are associated
with using a screening matrix?
A5-8 Write a brief stage report for Concept
Development that can be used
during the stage approval process for
a project you’re working on. Structure
your report so that it answers these
two fundamental questions: What is
the selected concept? And how have
you proven that your concept is best
and that it meets the market
requirements? As a way of
supporting the report’s claims attach
and refer to product development
artifacts that the team has produced.
CHAPTER 6
Subsystem Engineering
6.1 Design Evolution During Purpose

Subsystem Engineering The purpose of subsystem engineering is to
develop high-quality fully engineered
The third stage of product development is subsystems and components that have
subsystem engineering. In this stage, the been independently demonstrated to be
concept’s subsystems and components are desirable. Design for other characteristics
fully detailed. such as manufacturability and ergonomics
should have been accomplished. At the
At the end of the subsystem engineering end of this stage the entire system has
stage, the design is basically complete. been designed, although a full system
Although it will be refined in later stages, it prototype has not necessarily been made or
contains all the information necessary to tested yet.
create the system. The requirements and
tests have also been updated to reflect Development Outcomes
analysis and testing of the engineered
subsystems. Transferable artifacts containing the
following information for a desirable design
must be approved at the end of subsystem
During the subsystem engineering stage, engineering.
the system and its subsystems are being
engineered – even though we simply call it Requirements
subsystem engineering. To be clear about
how this and the next stage of development There are two sets of information that must
are separated, we consider the end of be added to the requirements by the end of
subsystem engineering to be having tested subsystem engineering.
and approved subsystems, while we
consider the end of the next stage of
development to be having a tested and 1. Predicted and measured performance
approved system. values for subsystems.
An important part of developing an
Table 6.1 provides a summary of the engineered product is predicting how the
elements of this stage. Each is now product will perform, so that design
described more fully. choices can be made to achieve the

https://doi.org/10.1007/978-3-030-14899-7_6
96 CHAPTER 6. SUBSYSTEM ENGINEERING
Table 6.1: Summary of the subsystem engineering stage.
Subsystem Engineering: Create high-quality engineered subsystems that have been demonstrated to be desirable. Design for other
characteristics such as manufacturability and ergonomics should have been accomplished. At the end of this stage, the entire system
has been designed, although the integration of subsystems has not yet been demonstrated.
Required information Typical artifacts Checking criteria Approval criteria
The subsystems meet or
exceed the target values of the
Predicted and All predicted values are
Section E of the subsystem performance
measured values for present, even if the value
requirements matrix for measures. If a few of the
subsystem performance is N/A? All measured
each subsystem targets are not met,
Requirements
measures. values present?

performance is at least in the
acceptable range.
The predicted values meet or
Predicted values for all
exceed the target values for the
Predicted values for performance measures?
Section E of the system system performance measures.
system performance Consistent with
requirements matrix If a few of the targets are not
measures subsystem measured
met, performance is at least in
values?
the acceptable range.
Reports on methods and
Test data demonstrating results demonstrating the Are the test methods The tests have been carried
subsystem desirability desirability of the subsystem complete and correct? Is out with sufficient quality and
Tests
(measured values for designs. Plots showing there enough detail for a transferability to provide strong
subsystem performance variation of subsystem third party to repeat the evidence for the measured and
measures). performance with changes tests? predicted values.
in design parameters.
Software source code with
Engineering models
run results. Input files for
used to choose design Are the models reported
Models
commercial software with Not approved directly; used

parameters and predict in enough detail to allow
run results. Excel with tests.
values for subsystem a third party to use them?
spreadsheets. MathCAD
worksheets. Hand solutions.
Prototypes used to help
choose values of design Experimental testbeds used Are the prototypes
Prototypes
parameters. Prototypes to select design parameter appropriate for the

Not approved directly; used
used to measure values. Fully functional intended use? Is the
with tests.
measured values of subsystems for testing fidelity and workmanship
subsystem performance measured values. appropriate?
measures.
Does the design package
Engineering drawings of all
meet the design intent of
custom-designed parts.
the team? Are all relevant
Specifications (and possibly
standards met? Are all
ordering information) for all The design is sufficiently
the necessary
purchased parts. Assembly transferable to allow the
Geometric, material, components included? Is
drawings for the system and creation of complete
and other appropriate the design package
all subsystems. Schematic subsystems and their
definition of the design sufficient to allow a third
diagrams. Piping and/or integration into a complete
Design
for each subsystem. party to correctly make

wiring diagrams. Block system by a third party.
the product and test its
diagrams. PC board layout
compliance with
files. Flowcharts and source
specifications? Are all
code for any software that is
elements under version
part of the design.
control?
Is it complete? Does it
Spreadsheet or database
Complete bill of have all necessary The bill of materials is
table that lists all known
materials information? Is it clear appropriate
components
and unambiguous?
Bill of materials, CAD modeling, checking drawings, design for assembly, design for manu-
facturing, design of experiments, design structure matrix, dimensional analysis, engineering
Useful tools:
drawings, ergonomics, experimentation, failure modes and effects analysis, fault tree analy-
sis, finite element modeling, prototyping, sensitivity analysis, uncertainty analysis.
Avoiding analysis; reinventing analysis; never doing analysis; poor experimental procedure;
Common pitfalls:
focusing on the prototype, rather than the design.
desired performance. This is often done values should be predicted and compared
using models. While not every with the system target values. The
performance measure needs to have predicted values should be captured in a
predicted values, the most critical values design artifact as well. If requirements
should be predicted. During its evolution, matrices are being used, the most recent
the design changes to ensure that the predictions should be recorded in the
predicted values meet or exceed the target system performance matrix.
values. The most current predicted values
are captured in a design artifact (e.g., a Tests
requirements matrix).
During subsystem engineering, models are
As the subsystem engineering stage nears tested to predict performance and
completion and the subsystem design is prototypes are tested to measure
complete, prototypes of the subsystems performance. Information on this testing
are created and tested. The values of the must be captured in a transferable format.
performance measures that are obtained
in testing are recorded as measured The methods used to predict product
values. Where the measured values are performance are an important part of
inferior to the target values, the subsystem product development (specific methods are
design is adjusted to improve the explained more fully in Section 6.5). They
measured performance. The measured too will evolve throughout the product
values are also captured in a design development process. As they are used to
artifact, such as in Section E of a test the current design, the results should
requirements matrix. be archived or if using a requirements
matrix, included in the predicted values for
Some measures will be unable to be the system or subsystem.
predicted; others will be unable to be
measured. When the team decides not to Prediction methods should be explained
measure or predict a value, this should be with sufficient detail that a skilled engineer
recorded in the requirements matrix (for who is not part of the development team
example, the value could be recorded as could accurately apply the method based
“N/A”). Making such an entry shows that on the current design. Prediction methods
the lack of a value is intentional, rather should include the names of program files
than an oversight. and/or data files used, along with any
instructions necessary to use these files.
At the end of subsystem engineering,
Not all performance measures need
predicted and/or measured values for all
performance prediction methods. However,
subsystem performance measures should
key performance measures should
be entered in the subsystem performance
generally be supported by prediction
matrices.
methods. It is often useful to have at least
two different prediction methods for critical
2. Predicted performance values for the
measures. This increases confidence that
system.
the prediction is correct.
During subsystem engineering, the When predicting performance, it is
subsystems have not yet been integrated generally a good idea to vary the
into the system. Therefore, there are parameters of the model to produce curves
unlikely to be measured performance or surfaces, rather than single-point
values for the system. However, based on solutions. With curves or surfaces, the
the decomposition work done in the robustness of the prediction with respect to
concept development stage, there should the model parameters can be estimated.
be models that relate subsystem
performance to system performance. As prototypes are created, they should be
Using the measured subsystem tested to determine the measured
performance values, system performance performance on each of the performance
measures. The procedures used in testing section we focus on two specific types:
the prototypes should be recorded. prototypes used to understand phenomena
related to the subsystem and prototypes
Test procedures should include test used to measure the performance of the
equipment, descriptions of how the testing subsystem.
is performed, the data that should be
recorded, and the analysis methods for the As subsytems are engineered, sometimes
data. There should be enough detail that a not enough is known about the behavior of
person not on the team could repeat the the subsystem to immediately create a
testing work and obtain the same results. single desired design. In such cases it can
be helpful to create a testbed, which is a
Well-documented tests of models and prototype that is designed to have the
prototypes, with results that are consistent ability to quickly change the values of
with the target values, provide strong important design parameters. The testbed
evidence that the design is of high quality. is then tested with various design
parameters to determine the optimal design
Models for the final product.
An essential aspect of engineering design is For example, when developing a Baja SAE
to use mathematical models to predict the vehicle, a team wondered about the effect
behavior of real systems. In subsystem of the location of the center of gravity (CG)
engineering we choose values for critical on hill-climbing and steering performance.
design parameters by modeling the They created a testbed car that was too
subsystems and then adjusting the design heavy to be competitive, but could readily
parameters until the model predictions have its center of gravity location changed.
match the target values for the subsystems. After exploring the effect of CG location
More detail on engineering modeling is with the testbed, they developed a
given in Section 6.5. competition car that was lighter but had
Engineering models range from much less adjustability.
handwritten equations to computer-based After the subsystems are fully engineered,
models involving millions of lines of code. a final prototype of the subsystem is
Regardless of their complexity, models created using materials and processes as
should be transferably captured such that close to the final product intent as possible.
the modeling work could be repeated by a This prototype is then tested to determine
third party. measured values of the subsystem
For models made using commercial performance measures.
software, this means that a set of input files Information about these prototypes should
should be kept and their use documented. be placed under revision control and added
For models that are created by the team, to the product information.
files that are part of the model, such as
source code and data files, should be
added to the product information. Hand Design
calculations should be added to the The following two main elements of the
product information, rather than kept on design are created or updated during
scratch paper or solely in and individual’s subsystem engineering.
notebook.
Like all product information, the models 1. Definition of the system and subsystems
should be placed under revision control.
By the end of the subsystem engineering
Prototypes stage, the design contains all the
information necessary to make or buy the
Many different kinds of prototypes are used components and assemble them into the
during subsystem engineering. In this subsystems and integrate those
subsystems into the system. The design and piping diagrams may also be
will often contain many of the items listed added if necessary.
below. All items included in the design Board layout: Products will often contain
should follow relevant professional custom circuit boards. For such
standards. To greatly reduce confusion products, a copy of the board layout
within the product development team, all should be provided. The board
artifacts that are part of the design should layout may include a graphical image
be placed under revision control, with a of the board. It may also include a
version number listed on the artifact and a variety of files used to produce the
history of changes maintained. board, such as Gerber files and drill
files. The board layout should be
Assembly drawings: The overall system is provided with sufficient detail that
represented with exploded and the board can be reproduced without
unexploded assembly drawings of reverse engineering.
the final product. These drawings
should include critical assembly Block diagrams: For electrical systems, it
dimensions, overall footprint or size, is common to create block diagrams,
assembly tolerances, notes, and a which show the design at a higher
bill of materials defining each part in level of abstraction than the
the assemblies. A numbered balloon schematic diagrams. Block diagrams
points to each part of the assembly. may also be useful in fluid control
There will likely also be assembly systems.
drawings for subsystems or other Logic diagrams: Products often contain
subassemblies. software as part of a control system.
Detailed part drawings: Parts should be When software is included, logic
described in sufficient detail to diagrams of the software should be
purchase or make them. Any part of the drawing package. This
custom-designed parts need may include diagrams such as
engineering drawings. Drawings flowcharts, ladder diagrams,
should include complete pseudocode, and block diagrams.
dimensions, tolerances, material The objective is to document the
types, and appropriate notes. logic that is implemented in the
software.
Schematic diagrams: When products
contain electrical, hydraulic, or Source code: Where the design includes
pneumatic systems, the design of a software component, the source
such systems should be code should be provided in the form
documented. Standard practices for of computer files (not printed).
schematic diagrams should be used, CAD models or IGES files: For complex
including standard symbols for shapes, it may be preferable to
components. define the shape with a solid or
Wiring/piping diagrams: For products with surface model, rather than a
electrical, hydraulic, or pneumatic drawing. The model files used to
systems, there may need to be a define the shape are an important
wiring or piping diagram in addition part of the design, and should be
to schematic diagrams. Schematic referenced in notes on the drawing
diagrams are aimed at describing the and in the bill of materials.
function of the system; wiring and
piping diagrams are aimed at 2. Bill of materials
describing the physical layout of the
system. It will require judgment as to A bill of materials (BOM) is a table
whether both types of diagrams showing all parts in the design in a
should be provided. Schematics hierarchical structure with top assembly,
should always be provided. Wiring subassemblies, and parts. The BOM also
has information regarding each part such It may be difficult for the market
as a part number, a drawing number, and representative to validate the design,
a source for the part. because the subsystems are not yet fully
integrated. However, it is a good practice to
The BOM must be complete enough to do as much as possible to create
allow a third party to aquire all purchased prototypes that are useful for validation. In
parts and the raw materials for all particular, if critical subsystems can be
custom-made parts. evaluated by the market representative, the
The BOM should be placed under revision risk of developing an undesirable product is
control. greatly reduced. For approval, the
validation testing results should show that
More information on the BOM can be the market representative likes the design,
found in the Development Reference with any areas of concern related to
under Bill of Materials (11.3). portions of the design not yet integrated in
the validation prototypes.
Approval
Useful Tools
The requirements, tests, and design are
checked by the product development team
to ensure that the product development For subsystem analysis: Design for
artifacts accurately and transferably assembly, design for manufacturing,
capture the design intent of the team. As design of experiments, design
the design artifacts will be used to transfer structure matrix, dimensional analysis,
the design, it is essential that the artifacts ergonomics, failure modes and effects
be carefully reviewed, rather than just analysis (FMEA), fault tree analysis,
assuming they are correct. finite element modeling, CAD
modeling, prototyping, uncertainty
Engineering models used as part of the analysis.
tests create predicted values of
performance. Ideally, these predictions For subsystem testing: Prototyping, design
should meet or exceed the performance of experiments, experimentation,
targets. At a minimum, they should lie in prototyping, sensitivity analysis,
the acceptable range. uncertainty analysis.
For subsystem design: Bill of materials,
Subsystem prototypes are tested to
CAD modeling, checking drawings,
determine measured values of
design structure matrix, engineering
performance. Ideally, the measured values
drawings, sketching, storyboards,
should meet or exceed the performance
robust design.
targets. At a minimum, they should lie in
Common Pitfalls
Every performance measure for the
subsystem should have a predicted value • Avoiding analysis: It is virtually certain
and/or a measured value. The strongest that assumptions and simplifications
proof of desirability is to have measured will need to be made in order to
values, but in some cases only predictions analyze the problem. Because this
can be made at this point. Where can be difficult, it is sometimes
measured values are not available, tempting to avoid analysis and do
predictions of performance should everything by experimentation. Even
generally be made using at least two simple analysis can often lead to
different prediction methods. Any significant learning, such as identifying
performance measures that have neither a the important variables in the system.
predicted nor measured values are cause
for significant concern and are likely to • Reinventing the analysis: Engineering
prevent approval. analyses of typical systems are often
6.2. EXAMPLE 101
available in handbooks such as The team used two engineering models to

Roark’s Formulas (Young et al., 2012) test performance for the drill. These
or Marks’ Standard Handbook for models were used repeatedly as the design
Mechanical Engineers (Avallone et al., of the drill changed, with the final predicted
2007). Machine design textbooks values being consistent with the target
such as Norton (2006) or Budynas values.
et al. (2011) can also be helpful. Be
sure to explore available analyses The first test method was a model of the
before jumping into your own. wheel RPM as a function of the torque
required to cut through the earth. By
• Poor experimental procedure: examining existing research, the team
Subsystems should be tested under a discovered that a typical human could
variety of conditions, not just under provide about 0.2 hp for a period of 2.5
optimal conditions. It is best to identify hours1 . Given this power output, the team
the limits of satisfactory performance, considered the total power available as
not just verify that satisfactory function of the number of operators from
performance exists under ideal two to eight. The power to the drill is given
conditions. Statistical Experimental by the product of the torque and the
Design techniques should be used to angular velocity. For four operators, the
obtain as much information as torque varied from 150 lb-ft at 30 rpm to
possible from a limited number of 2,500 lb-ft at 2.5 rpm. These torque
experimental tests. numbers could then be used to design the
remainder of the subsystem.
• Never-ending analysis: No matter how
good the analysis model is, it can Another example of a model used to test
always be improved. However, the the drill is a stress analysis on the structure.
improvement is sometimes not Assuming that the drill string weighs 1725
necessary. When the analysis and its lb and including the possibility of the drill
answers are good enough to support string catching on the borehole side as it is
the necessary design decision, it’s time being lifted, a total design load of 4500 lb
to move on to the next critical issue. was chosen for the string. With this load
and the specified geometry and material for
the structure, a safety factor of 1.5 for
6.2 Example of Subsystem yielding was calculated.
Engineering The five subsystems on the drill were
designed in an interdependent, rather than
Let’s again revisit the human-powered independent, fashion. Many of the key
water well drill (presented more fully in performance measures could only be
AppendixB). determined in an assembled drill system,
During subsystem engineering, all three so multiple iterations of subsystem design,
components of the design (requirements, system integration, and system testing were
tests, and design) for the human-powered performed during the subsystem
drill underwent evolution. engineering stage.
As a result of testing the models and
The requirements evolved and were
prototypes, the design evolved throughout
captured by adding measured and
the stage. The design at the end of concept
predicted values to the subsystem
development included CAD models of the
requirements matrices. For brevity, we
various subsystems. Engineering drawings
show only the requirements matrix for the
were created for each of the parts
wheel subsystem (see Figure 6.1). The
identified, and assembly drawings were
measured and predicted values were
created for the subassemblies.
obtained by applying evolved tests to
models and prototypes developed from the 1
http://www.ohio.edu/mechanical/programming/
design. hpv/hpv.html
Product: DRILL

102
... Subsystem: WHEEL
1 Time 60 minutes to drill through 60 inches of rock

Real Values Ideal Values
Importance
Importance
12
10
Measured Predicted Target Upper Acceptable Ideal Lower Acceptable Subsystem Performance Measures Units
– – 30 – 30 3 13 1 Spinning speed RPM
– – 6 – 8 6 19 2 Wheel d iameter ft
– <25,000 50,000 50,000 25,000 – 10 3 Maximum stress in wheel with 600 ft-lbs torque applied psi
– <25,000 50,000 50,000 25,000 – 10 4 Maximum stress in handle with 600 ft-lbs torque applied psi
45 – 45 – 45 30 9 5 Distance between handles deg
19.2 – 150 200 50 – 9 6 Weight of heaviest welded wheel assembly or component lbs
32 – 48 96 48 – 9 7 Longest dimension of welded wheel assembly ft
– 100 100 – 100 90 9 8 Percentage of wheel manufacturable in Tanzania %
112 – 150 300 100 – 9 9 Cost to produce one wheel after development USD
8 – 60 240 60 – 9 10 Time required to learn to put wheel tolerance min
42 – 60 240 60 – 9 11 Time required to learn to add the wheel to the support min
60 60 240 60 – 9 12 Time required to learn how to spin the wheel efficiently min
37 – 40 – 41 39 2 13 Height of lowest point to grab handle (center of palm) in
47 – 46 48 44 – 2 14 Height of highest point to grab handle (center of palm) in
the market requirements and requirement–measure limitations are mostly omitted in this view.
Drill can be operated Drill can be operated with n/a
Marginal continuously without the occasional rest, and requires
– Ideal – need to rest. Does not awkward movements that
1 15 Feels comfortable
Measured
Ideal Drill has a professional look. Drill looks like a piece of n/a
Measured – Ideal – People are interested in machinery for drilling holes. 4 16 Wheel is attractive
looking at it.
Drill captures media n/a

Ideal The drill, when explained to
attention. Investors are
Measured – Ideal – investors, is something they 12 17 Wheel interests investors
want to invest in.
Figure 6.1: Subsystem requirements matrix with measured values for wheel subsystem. Because of space limitations,
CHAPTER 6. SUBSYSTEM ENGINEERING
By the end of the subsystem engineering 6.3 Top-Level Activity Map for
stage the subsystems for the drill had Subsystem Engineering
evolved to the point shown in Figure 6.2.
As can be seen, the subsystems are very Figure 6.8 shows the top-level activity map
similar to (but not exactly the same as) for the subsystem engineering stage of
those at the end of the project (refer to development. This activity map begins with
Appendix B for images of the final design). the output of the concept development
stage — approved product development
The design is captured in the form of
artifacts including the concept, subsystem
engineering drawings. The team created
definitions, interface definitions, and target
44 engineering drawings for this project,
values for performance.
some of which had multiple sheets. Nearly
all of these drawings were created and The initial activity shown in the map is to
checked in the subsystem engineering assign resources to subsystems that will
stage of development. As an example, we allow the engineering of individual
have provided just four drawings; these subsystems in parallel, at least to the point
drawings capture the design for the kelly that the subsystem is ready for integration
bar assembly. These are shown in testing with some other subsystems. In
Figures 6.3 – 6.6. The complete set of some cases, subsystems will be approved
engineering drawings organized by only after successful integration testing with
subsystem is shown in Figure 6.7. other subsystems. In others, the subsystem
can be individually approved.
By the time the stage of development was
complete, the team had been able to Compound Outcome 26 simply indicates
predict or measure the performance of the that all subsystems are approved only after
subsystem as it related to each every subsystem is individually approved.
performance measure. In Table 6.2 we
show the measured and predicted values Importantly, the five arrows proceeding
for the structure subsystem. In all cases from Outcome 1 represent the engineering
but one, the final values lay within the of each subsystem. The activity map for
acceptable region. The sole exception is engineering a subsystem is too complex to
the parts count, where the upper have included in this figure, so that entire
acceptable limit is 100 and the actual activity is detailed out in Figure 6.9, which
number of parts is 107. In consultation shows a top-level activity map covering the
with the sponsor, the team determined that independent engineering of a single
the upper limit was somewhat elastic, and subsystem. The map begins with
that an actual count of 107 would be identifying a list of all the components in the
acceptable. subsystem in a working bill of materials for
the subsystem. The components are then
***** classified as vital or mundane and custom
or off-the-shelf. Each class of component
As a note, the realities of an immovable has a different path; at the end of each
project completion date required the team path the component is integrated into the
to reevaluate the scope during the early subsystem design. Once the subsystem
portions of subsystem engineering. design is complete, performance testing is
Working closely with the client, and after used to demonstrate that the subsystem is
considerable evaluation, the team and ready for any needed integration tests.
client decided to use a gasoline powered
slurry pump in place of the This activity map shows one common
human-powered pump being pursued by relationship between subsystems, namely
the team. While this was a difficult decision that engineering can proceed
to make, it was clear that continuing independently until integration tests are
development on the pump would necessary. However, it is also possible that
jeopardize the successful completion of the there will be interdependencies between
other subsystems. other subsystems that may happen before
Figure 6.2: The

drill subsystems
as they existed
at the end of
subsystem engi-
neering. a) drill
string, b) hoist,
c) wheel,
d) wheel sup-
port, e) pump
system.
a b
c d
24 in. 24 in.
6 in.
24 in. 48 in.
Top View
24 in.
6 in.
Pump
Side View
8 in.
15 in.
Settling Pond e
6.3. TOP-LEVEL ACTIVITY MAP
105
Figure 6.3: Engineering drawing of the kelly bar assembly.

106
Figure 6.4: Engineering drawing of the square tubing for the kelly bar.
6.3. TOP-LEVEL ACTIVITY MAP
107
Figure 6.5: Engineering drawing of inner pipe for the kelly bar.
108
Figure 6.6: Engineering drawing of end plate for the kelly bar.
Figure 6.7: A
representation of
the 44 drawings
created by the
team, organized
by subsystem.
Table 6.2:
Performance Measure Ideal Acceptable Target Predicted Measured Predicted and
Value Limit measured val-
Maximum stress at depth (psi) 25,000 50,000 50,000 30,000 N/A ues for structure
Load rating of support 4500 2250 4500 N/A 3500 subsystem.
mechanism (lbf)
Maximum stress during 25,000 50,000 50,000 1607 N/A
changeover (psi)
Downward force (lbf) 3000 500 200 N/A 1313
Rate of descent (ft/min) 4 1 4 N/A 3
Length of longest piece (in) 84 96 84 84 84
Percentage of structure made 100 90 100 97 N/A
in Tanzania
Percentage of lifter made in 100 0 100 0 0
Tanzania
Production cost (USD) 750 1000 750 842 N/A
Number of parts 30 100 30 107 107
Time to learn to set up (min) 60 240 60 N/A 18
Time to set up (min) 60 240 60 N/A 24
Seek approval for

subsystem A
13
Seek approval for 12

subsystem B
11
Engineer
Subsystem A 2 16
Test integrated A-B 14
performance 15
7 9
Engineer
Subsystem Seek approval for
From Concept 3
B subsystem C To System
Development
19 17
Engineer 18
Subsystem C
Assign 1 4 8 10
resources to Test integrated
22 20
subsystems B-C-D performance
21
5 26
Engineer
Subsystem D
Seek approval for
subsystem D
25 23
Engineer n 24
Subsystem n
6
Seek approval for

subsystem n
OUTCOMES
1 Subsystem assignments 10 Measured B-C-D integrated performance 19 Approved subsystem C
2 Subsystem A ready for integration testing 11 Subsystem A approval 20 Subsystem D approval
3 Subsystem B ready for integration testing

12 21
4 Subsystem C ready for integration testing
13 Approved subsystem A 22 Approved subsystem D
5 Subsystem D ready for integration testing

14 Subsystem B approval 23 Subsystem n approval
6 Subsystem n ready for system testing
15 24 n
7 Integrated subsystems A and B
16 Approved subsystem B 25 Approved subsystem n
8 Integrated subsystems B,C,D
17 Subsystem C approval 26 All subsystems approved
9 Measured A-B integrated performance
18
Figure 6.8: Top-level activity map for the subsystem engineering stage. There is a great deal of complexity not shown in
this map that covers the engineering of each individual subsystem. Please refer to Figure 6.9 for the detailed top-level
map for engineering a single subsystem.
6.4. DESIGNING VITAL COMPONENTS 111
integration testing. Such interdependencies affect the performance. This will often
should be included in a specific activity require a literature search or discussion
map for the interdependent subsystems. with experts who are familiar with the
component technology and can identify
important parameters. As these vital
6.4 How to Design a Vital parameters are identified, the correlations
Custom Component between parameters and performance are
also identified and recorded.
A common design activity is that of
designing a vital custom component. The
Identify Vital and Mundane Parameters
purpose for this activity is to develop a
complete definition of the component, The vital parameters of the component are
along with predicted and/or measured design parameters that strongly affect the
performance that demonstrates the subsystem performance. These will be
component will work as intended. listed at the top of the component
requirements matrix. Values for the vital
An activity map for designing vital custom parameters will be carefully selected;
components is shown in Figure 6.9, determining these values will take up the
between Outcomes 13 and 27. This majority of the time in subsystem
section of the map covers preparing a engineering.
component requirements matrix,
identifying important engineering principles However, the vital parameters of the
related to the component, identifying vital component are typically only 5-10% of the
parameters of the component, developing parameters for the component. Other
analytical or experimental models that design parameters have relatively minor
relate parameter values to performance, influence on performance, and are called
using the models to select parameter mundane parameters. Creating an initial
values, capturing the parameter values in CAD model, sketch, or drawing of the
an engineering drawing, and revising and component can help identify all of the
checking the drawing. parameters necessary to be specified as
part of the design. Values for the mundane
Create the Component Requirements parameters will generally be chosen
Matrix conservatively, using good engineering
judgment.
A component requirements matrix has
subsystem performance measures on the
left and component design parameters on Determine Mathematical Relationships for
the top. The center of the matrix lists Vital Parameters
correlations between design parameters Previously, we identified the vital
and performance measures, although the component parameters that were correlated
specifics of the mathematical relationships with subsystem performance. In this
between the parameters and performance activity, we identify functional relationships
measures are not yet known at the start of that quantify the correlations. To do this we
component design. create analytical and experimental models
One of the first activities in component as described in Section 6.5.
design is to identify the subsystem
performance measures that will be affected Predict the Performance and Choose
by the component. This should be Parameter Values
relatively straightforward, because the
component was chosen to create the Once the parameter–performance
appropriate performance. relationships are identified, they are used to
determine ideal values for the vital
A more challenging activity may be to component parameters. This is done in an
identify the component parameters that iterative process, often using optimization
From
subsystem 30
assignment Create preliminary subsystem test procedures
Create preliminary
subsystem BOM 7
Test component
Determine Identify performance
Create 29
selection criteria candidate set of Evaluate set and subsystem Test
for off-the-shelf off-the-shelf choose best testing design
components components component prototype using
2 3 4 5 6 prototype
Revise 31
component
Fo sys
helf components
su
rm te
selection
all m d
Find any
ya e
dd sig
component that
to n
Identify required will give
performance performance Formally add component to subsystem design 32
8 9 10 28
Identify vital off-the-s
Add to
Identify vital
lf
Use models to subsystem

-she
parameters of 24 design
component 17 23
pon ff-the
Re
performance
vis dra
Rev
Identify Create
ents
e wi
14
com ane o
co ng
engineering component
ise d
m
principles of
po
drawing
nd
ne
e
component
sign
mu
n
t
Determine
tify
mathematical Find parameter

Check
Iden
relationships between values that give

component
performance and desired
drawing
27 25 33
parameters performance
1 13 16 19 21
Identify vital
custom
components
Identify Identify 22 26
preferences for mundane
subsystem parameters of Select some
performance component working values
Ide om c
cu
15 for mundane
st
Formally add to
nti om
parameters
fy
subsystem
mu pone
18 20 design
nd nts
Design the
an
To necessary
e
mundane
component integration tests
11 12
OUTCOMES
1 Working subsystem Bill of Materials 12 Drawing of mundane component 23 Predicted values for performance measures
2 List of vital off-the-shelf components 13 List of vital custom components 24 Engineering drawing of component
3 Selection criteria for vital component Parameters, constraints, performance, Revised drawing
14 correlations
25
4 Candidate set of off-the-shelf components
15 Subsystem performance preferences 26 Drawing check passed
5 Preliminary component selection

16 Component requirements 27 Checked component drawing
6 Component selection
17 List of vital parameters for component 28 Subsystem design
7 Measured component performance
18 List of mundane design parameters 29 Subsystem prototype
8 List of mundane off-the-shelf components
Engineering models relating parameters to
19 30 Subsystem test procedures
Performance requirements for mundane performance
9 component
20 Selected values for mundane parameters 31 Subsystem design, prototype, procedures
10
21 Selected values for vital parameters 32 Measured values for subsystem
11 List of mundane custom components
22 Values for component parameters 33 Subsystem ready for integration testing
Figure 6.9: Top-level activity map for engineering a single subsystem. This map will be repeated for each subsystem.
Included in this map are submaps dealing with mundane off-the-shelf components, vital off-the-shelf components, mun-
dane custom components, and vital custom components. Note that a given subsystem may have zero, one, or more than
one of any or all of these kinds of components.
6.5. HOW TO DEVELOP AND USE ENGINEERING MODELS 113
techniques that adjust the component characteristics. In most cases, the quickest
parameters until the predicted values for and least expensive way to explore design
subsystem performance measures match parameters is with an engineering model.
the target values. This process is described
more fully in Section 6.5. In some form or another, modeling is used
during most product development stages.
Create the Component Design Because many of the models are
developed during subsystem engineering,
Previously, we described creating an initial we have included a deeper discussion of it
CAD model, drawing, or sketch of the in this chapter.
component in order to identify all of the
components design parameters. At this Common uses of modeling include the
stage we create a formal engineering following:
design, most often in the form of one or
more engineering drawings, that captures
all component design parameters, both • Identify the key physics involved in the
mundane and vital. This design serves as problem to be solved
the clear and complete definition necessary
for the production system to create the • Explore limits of the design space to
component. help assess the novelty and variety of
the candidate solutions
Check and Revise the Component Design • Obtain quantitative estimates of the
At the end of the activity map, the performance of candidate solutions to
component’s design is checked to ensure support the selection of a strong
that it and the evidence of its desirability solution candidate
are transferable. The design should be • Choose appropriate values of design
checked by a member of the team other parameters to ensure required
than the one who created the design. It’s performance is obtained
essential to look hard for mistakes in the
design so they can be fixed at this time. • Verify that the required performance is
The Development Reference entry on obtained.
Drawing Checking (11.22) contains a
checklist that is useful in checking the
component design. What Is an Engineering Model?
Once the design has been checked and Models are analytical approximations of the
approved by the drawing checker, the product, where the amount of
component design is added to the approximation varies for different models.
subsystem design. The degree to which the model matches
the real product is the fidelity of the model.
Models with high fidelity are a better
6.5 How to Develop and Use approximation of the product than models
Engineering Models with low fidelity. For example, Figure 6.10
shows various models of the mass
The goal of modeling is to understand the distribution of a horse with different levels
relationship between design parameters of fidelity. The model on the left (the lowest
and performance measures. level of fidelity) would suffice if we were
only concerned about the orbital
A fundamental characteristic of developing characteristics of a horse, but if we wanted
engineered products is the use of to examine stresses in horse’s legs, we
predictive models to determine the would need something more like the model
expected performance of the product. on the right. To that end, it is important for
Such models are used to quickly adjust the the development team to match the fidelity
design to meet the required performance of the model to its expected use.
Figure 6.10: Models

of the mass distribu-
tion of a horse with
various fidelities.
The model on the
left would serve if
only the total mass
were important
and would allow
rapid calculations.
Models with higher
fidelity would be
required if the distri- Low Fidelity Model High Fidelity Model
bution of the mass Low Computational Cost High Computational Cost
were important
for the question
to be answered.
Higher-fidelity
models would
require higher
computational cost.
For the purpose of this discussion, an represents reality — is generally considered

engineering model is a tool that can be to increase as we move from left to right on
used to express the performance measures the figure. When we choose a particular
of the product as a function of the values of kind of model, we are often committing to a
the design parameters. specific fidelity, time required, and set of
limitations. We are also choosing the type
In its most general form, we can consider of insight we are likely to obtain from the
an engineering model to be based on an model. Table 6.3 shows the general
equation (or system of equations): characteristics of each of the model types.
F (P M, DP ) = 0 (6.1)
Planning for Engineering Models
where P M is a set of performance
measures, and DP is a set of design In developing engineering models, it is wise
parameters. This form of the equation is to consider the following planning steps to
not generally useful for design, so we desire ensure the best use of resources.
to solve the general equation for the
performance measures: Define the purpose of the model: Why are
P M = G(DP ) (6.2) we making a model? What
performance of the product do we
We can classify engineering models by hope to predict? How will the model
considering the characteristics of the help us advance the design?
general equation and the solution. When Answering these questions helps
symbolic solutions are available, we can ensure that the model is appropriately
use them directly. If there are no symbolic focused, and that the right kind of
solutions, we must use a number of model is made.
solutions to develop an empirical or
statistical model. Define the fidelity (level of approximation)
of the model: Every model is an
Figure 6.11 shows the kinds of solutions abstraction of the real world.
that are likely to be available for various Low-fidelity models have coarse
types of models. Note that model fidelity — approximations and consider limited
which is a measure of how well a model physical phenomena. But their
Figure 6.11: So-

“Back of the Fundamental Discretized Physical lution character-
Envelope” Model Engineering Model Model Model
istics of model
Symbolic solution available types.
Numerical solution available,

but not symbolic
Experimental solution available,
but not computational
Table 6.3: General characteristics of engineering models and their solutions.
Model and Solution Fidelity Time Required Insight Gained Limitations

Type
Closed-form Low to medium — Low — can often be Important variables Real products
solution to simple often based on done “on the back are identified, along seldom closely
model gross of an envelope” with an estimate of match the
approximations their effects simplifications
assumed
Closed-form Medium to high Low if found in Detailed prediction Sometimes fine
solution to handbook, medium of effects of details are missing
engineering model to high if developed important variables Often applies only to
for your particular very specific cases
project
Empirical model, Depends on High Statistical model of Testing can be very
based on testing of prototype that is performance, expensive.
physical prototypes tested, and number effects of Statistical models
of tests done unanticipated are often just
phenomena that approximations of
didn’t show up in the real behavior.
the pre-test model Extrapolation
beyond the area
tested is risky.
Numerical solution As good as the Low, once equation Insight comes in Sometimes fine
to engineering fidelity level of the is developed. developing, rather details are missing.
model (e.g., equation to be than solving, the Often applies only to
Runge–Kutta solved (generally model. very specific cases.
method for solving medium to high). Systematically Extrapolation
ODE) May be dependent varying design beyond the area of
on characteristics of parameters can systematic
the solution lead to an empirical exploration is risky.
technique (e.g., estimate of
step size) performance
Finite element Various, depending Moderate time, Need systematic Often limited to
methods (and on the features depending on the variation in order to linear behavior. Very
similar techniques) included and the complexity of the get good predictive dependent on
size of the mesh mesh insight. model setup. Model
setup can easily be
poor. The full set of
features may give
spurious solutions.
Fine meshes can
lead to very long
solutions times.
corresponding strength is that they are For critical performance measures, it is a

quick to develop and usually quick to good practice to have at least two
evaluate. Higher-fidelity models independent ways of predicting and
capture more physical phenomena verifying the performance obtained. This
and use finer approximations, but increases the confidence in the quality of
generally take more time to develop the proposed solution.
and execute. Higher fidelity is not
better for all applications. Choose the General Kinds of Models
right fidelity for your purpose. It is
often wise to think about planning for a Figure 6.11 presents four general kinds of
series of models with increasing models. They are:
fidelity.
Simplified “back of the envelope” models:
Define the experimental plan for the model:
Based on fundamental scientific
Once the model is developed, what do
principles and gross approximations.
you plan to do with it? Generally the
model will be run multiple times with Fundamental engineering models: Based
different values of model parameters. on fundamental scientific principles,
Single answers from a model are not but with more refined approximations.
very useful. Much more useful is a
series of runs that can be used to Discretized models (FEM, Finite
develop operating curves or surfaces. Difference): Based on models applied
Engineering models can be used with to discrete portions of the system, with
designed experiments to develop system performance calculated from
approximate response surfaces. Make the collection of the discrete portions.
sure you plan to use the model Discretized models are often used
effectively. when the geometry or boundary
conditions are too complex to create a
Define the schedule for the modeling fundamental engineering model. The
activity: Like any design activity, system is discretized, and appropriate
modeling can be endless if it is not numerical models for each of the
managed properly. Plan a schedule to discrete elements are created, with
limit the amount of time spent on the consistent boundary conditions
model to an appropriate value. between the elements. All of the
discrete models are solved, which
leads to a numerical solution for the
Principles of Engineering Modeling entire system.
Just as in physical prototypes, the quality of Physical models: Based on experimental
engineering models improves as successive results. These are used when it is
iterations are made through modeling unclear how to create the other model
activities. The IDEO adage “fail often early types of the system (often because of
to succeed sooner” applies to engineering uncertainty in how physical principles
models. Most of the improvement happens apply).
when you make the first model; the
improvement continues with the second.
Eventually the improvement tails off, as is Solutions to the Model
shown schematically in Figure 6.12. The availability of a solution is dependent
upon the type of model. There are
Models need to be verified before they can generally three different solution regimes.
be believed. The existence of a model,
even using a commercial analysis program,
does not imply that the model is correct. As 1. The solution is available symbolically
models are being developed, it is important (back of the envelope and
to check and see if the results make sense. fundamental engineering models).
Figure 6.12:
100
Schematic of
90 how models
80 improve with
Percent improvement per iteration
successive
70 iterations. The
60 biggest step in
getting a model
50
is the first itera-
40 tion; the second
30 iteration is also
likely to have a
20 large improve-
10 ment. Eventually
the improve-
0 ments become
0 1 2 3 4 5 6 7 8 9 10 relatively small.
Model iteration number
2. The solution is available numerically, models, you may wish to do your own
but not symbolically (some derivation, starting with related existing
fundamental engineering models and cases.
discretized models).
3. Solution is available experimentally, Using Model Solutions
but not computationally (physical
Once a model has been developed and
models).
solved, the task is not yet done. We still
need to use the solution to affect the
In planning for your models, be sure to design. Here we provide some guidelines
account for the kind of solution you need for using each type of solution.
and the kind of solution you’ll get from the
model.
Symbolic solutions Look at the functional
Finding General Equations for the Model form of the solution. You can make
great inferences from the functional
One of the challenges in engineering form. For example, can you identify
modeling is determining the appropriate which parameter directly affect the
equations to use to model a real-world solution? Can you see which ones
situation, as all general equations involve inversely affect the solution? You can
simplifying assumptions. Below are a few also create curves and surfaces of the
tips that might help as you develop models. solution function, and vary these plots
by changing design parameters.
• Back of the envelope models: Look for
Numerical solutions These solutions
fundamental laws that should apply
cannot generally be used by direct
(Newton’s laws, conservation laws,
inspection, so it will be necessary to
etc.). It is often helpful to consider
generate enough solutions to draw
static or quasistatic conditions before
inferences about the performance of
developing dynamic models.
the system. Ways that this is often
• Fundamental engineering models: done include the following:
Look in engineering textbooks and
design handbooks, such as Roark’s • Use an optimization tool to
Formulas for Stress and Strain (Young optimize, as well as to explore the
et al., 2012). For higher-fidelity design space.
• Run the calculations multiple physical representations of the design at

times and develop a statistical the moment the prototype is created.
model that describes the
performance (response surface Like engineering models, prototypes have
methodology). multiple purposes and can be of varying
fidelity. Like models, a higher-fidelity
Physical models Run the experiments prototype is not always better than a
multiple times and develop a statistical lower-fidelity prototype, given the time and
model that describes the performance cost necessary to produce a prototype.
of the system. Design of experiments
Prototypes can represent the entire design
(DOE) methods are helpful here.
(a comprehensive prototype) or only a
small portion of the design (a focused
Summary of Engineering Modeling prototype). Of course, they can also lie
between these extremes.
There is a need to predict the performance
of your product before it is built, so that a Ulrich and Eppinger (2012, pp.294–297)
version of the product that meets the needs note four purposes for prototypes, to which
can be created. we add performance testing and validation,
as shown in Table 6.4. Note that a single
There are different types of analytical
prototype can have multiple purposes. Also
models, depending on the type of
note that no prototype that requires a
fundamental information available about
significant investment in time or money
the system being modeled and the
should be made without a clear
solvability of the developed equation.
understanding of its purpose(s).
As a team, you should develop a modeling
The process of creating prototypes can
plan to ensure that you are using your
consume a great deal of time and
resources wisely.
resources. To ensure that these are kept
within appropriate bounds, a prototype plan
6.6 How to Develop and Use should be created for each prototype that
will consume significant resources. The
Prototypes plan should include the following (Ulrich
and Eppinger, 2012):
The goal of prototyping is to create a
physical representation of the product that
can be used to help evolve the design. • Define the purpose(s) of the prototype
As the design, requirements, and tests • Establish the level of approximation of
evolve through the product development the prototype
process, it can be difficult for both the
development team and the market • Establish the quantity to be built
representatives to understand and evaluate • Establish the test plan for the prototype
the current design. Manufactured products
are inherently physical objects that we • Establish the schedule for building and
interact with using our physical senses. testing the prototype.
Designs are inherently intangible objects
(although artifacts are tangible) that require
us to process them before we can have a Care should be taken to make effective use
sensory experience with them. of resources in prototyping. The most
obvious means of prototyping may not be
To allow both the development team and the most effective. For example, although it
the market representatives to have a direct may seem that a hand-wired circuit board
sensory experience with the product, may be the quickest way to get a prototype
prototypes are made throughout the board created, commercial services that
development process. Prototypes are produce a small quantity of
6.8. EXERCISES 119
Table 6.4: Possi-

Purpose Description ble purposes for
Learning Understand more about how the design ideas will work in the prototypes.
physical world. These are often related to physical engineering
models.
Communication Share with others the current state of design. Allows people to
obtain sensory input about the product.
Integration See how well the parts of the design work together. The
performance testing and validation prototypes at the end of the
system refinement stage are examples of integration prototypes,
but other partial integration prototypes can be effectively used
in product development.
Milestone Provide a concrete goal for the team to work toward. A milestone
prototype can be a very effective way of getting the development
team to finalize the design by a milestone deadline.
Performance testing Provide a means for the development team to demonstrate that
the performance measures (both subjective and objective) are
being met.
Validation Provide a means for market representatives to express their
perception of how well the product meets market requirements.
professional-quality prototype boards from compatible with one another to form the
CAD data are quick and relatively complete system, but the system has not
inexpensive. In fact, when considering the yet been fully integrated or tested.
generally higher reliability of the
At the end of subsystem engineering, the
commercial board it is often faster and
design is generally complete. However, it
cheaper. Similarly, instead of machining a
will be subject to refinement during later
part from aluminum, a rapid prototyped
stages of development.
plastic part may provide a similar function.
During subsystem engineering, detailed
Particularly in the early stages of design,
designs of components and subsystems
prototypes can be made of materials that
are created. The creation of the detailed
will be significantly different from the final
designs allows modeling and testing to
materials. See Prototyping (11.50) and
predict and measure performance.
Rapid Prototyping (11.52) in the
Development Reference for more Engineering models are used extensively
information on prototype creation. during subsystem engineering to
understand how the required performance
Many product developers believe can be achieved. A series of models with
that effective use of prototypes to test ideas increasing fidelity is often used.
beyond the development team is a vital
component of effective development pro- Prototypes are created to test the
cesses. Getting prototypes in front of others performance of subsystems and to obtain
is a great way to move your design forward. validation from market representatives.
Careful planning for the prototypes ensures
that the maximum benefit is reached.
6.7 Summary
During the subsystem engineering stage, 6.8 Exercises
the design progresses from a complete
system architecture to finished designs for Test Your Knowledge
all the subsystems that have been
demonstrated to meet their individual T6-1 List the required content of
performance requirements. The requirements, tests, and design at
subsystems have been designed to be the end of subsystem engineering.
T6-2 List six activities used to detail a c) In broad terms, define the
component. experimental plan for how you
will use the model once it is
T6-3 List five common uses of engineering developed.
models.
d) Estimate the time and resources
T6-4 List four steps for planning required to support the effort of
engineering models. developing and using the
model.
T6-5 List four general kinds of engineering
models. A6-3 Consider a product development
project with which you are familiar
T6-6 List the elements of a prototyping (perhaps one on which you are
plan that should be completed before currently working). For that project,
starting on a prototype that will identify a prototype that can be
consume significant resources. useful.
T6-7 List six purposes for prototypes that a) What is the purpose of the
are identified in this chapter. prototype?
b) Explain the level of
Apply Your Understanding approximation of the prototype
you intend to use to help the
A6-1 Consider an engineering model that development effort.
you have created or used in the past, c) Determine the number of
possibly as part of a product prototypes to be built, and
development effort. explain your decision.
d) In broad terms, define the
a) What is the general kind of experimental plan for how you
model you created or used? will use the prototype once it is
b) What were the intended and developed.
actual uses of the model (note: e) Estimate the time and resources
models are often used for required to support the effort of
multiple objectives)? developing and using the
c) How was the model useful in prototype.
advancing the design?
A6-4 Write a brief stage report for
d) What were the main resource Subsystem Engineering that can be
challenges associated with the used during the stage approval
model? process for a project you’re working
e) What were the limitations of the on. Structure your report so that it
model? answers these two fundamental
questions: What is the complete
A6-2 Consider a product development system design, including the
project with which you are familiar subsystem designs and their
(perhaps one on which you are integration? And how do you know
currently working). For that project, that the subsystems meet their
identify a model that can be useful. individual requirements and will be
compatible with one another? As a
a) What is the purpose of the way of supporting the report’s claims
model? attach and refer to product
development artifacts that the team
b) Explain the fidelity of the model has produced.
or models you intend to use to
help the development effort.
CHAPTER 7
Product Refinement
At the conclusion of subsystem engineering 7.1 System Refinement

stage, the full system design is basically
complete. All components and subsystems The fourth stage of product development is
have been completely detailed, and the system refinement. The purpose of this
subsystems have been demonstrated to stage is to integrate the subsystems into a
achieve their desired functions. From this high-quality working system and test it.
point on, design evolution generally Importantly, the system is refined as
consists of refinements to the existing necessary to resolve any issues that arise
design, rather than the creation of whole during testing of the integrated system.
new designs. The purpose of this chapter is
to characterize the three main stages of A primary task of this stage of development
refinement. They are: is the interdependent testing of engineered
subsystems. Because a comprehensive,
fully integrated, analytical model of system
• System refinement: The refinement performance is often prohibitive to create,
aimed at improving weaknesses performance testing of the integrated
identified when the entire system is system is largely based on physical
tested as a whole. experiments. These experiments are
essential because approved engineered
• Producibility refinement: The subsystems may work well alone, but not
refinement aimed at improving function well together. This stage seeks to
product weaknesses observed during identify these dysfunctions and refine the
the start of production. subsystems and system so that the product
meets the requirements.
• Post-release refinement: The
refinement aimed at improving product To make the most of the system refinement
weaknesses found by the market stage, it is desirable to identify as many
place, after the product was released. dysfunctions as possible. This generally
means testing the system over a wide range
of conditions, rather than just at the
Although each of the refinement stages has optimum conditions. Aggressive testing in
a unique focus, the common elements of system refinement helps prevent
refinement apply to all. Therefore, all of unpleasant surprises after it is released to
these stages are discussed in this chapter. the production system.

https://doi.org/10.1007/978-3-030-14899-7_7
124 CHAPTER 7. PRODUCT REFINEMENT
Table 7.1: Summary of the system refinement stage.
System Refinement: Integrate the subsystems into a demonstrated, high-quality working system. Refine the design as necessary to
resolve any difficulties encountered during testing.
The system meets or exceeds
Are all predicted values the target values of the system
Measured system Section E of the system present, even if the value performance measures. If a
performance values requirements matrix is N/A? Are all measured few of the targets are not met,
Requirements
values present? performance is at least in the

acceptable range.
Section F of the
Reports on customer Has the market response
Market response to the The market finds the product
response to the product, as been adequately
product desirable.
measured by surveys, focus assessed?
groups, interviews, or other
direct interaction.
Updated methods used results demonstrating the Are the test methods The tests have been carried
to predict and measure desirability of the product. complete and correct? Is out with sufficient quality and
Tests
the performance of the Plots showing variation of there enough detail for a transferability to provide strong
entire system (or system performance with third party to repeat the evidence for the measured and
product). changes in design tests? predicted values.
parameters.
Model source code with run
Engineering models
results. Input files for
Models

values for system a third party to use them?
Prototypes

used to determine values. Fully functional intended use? Is the
with tests.
measured values of systems for testing fidelity and workmanship
system performance measured values. appropriate?
measures.
ordering information) for all
purchased parts.
the necessary
Subassembly and assembly The design is sufficiently
components included? Is
drawings and instructions transferable to support the
Refined definition for the design package
for all subsystems and the creation of the entire system by
the entire system. sufficient to allow a third
system. Schematic a third party.
Design
party to correctly make

diagrams. Piping and/or
wiring diagrams. Block
compliance with
elements under revision
control?
part of the design.
components
and unambiguous?
Useful tools:
drawings, experimentation, failure modes and effects analysis, fault tree analysis, finite ele-
ment modeling, prototyping, sensitivity analysis, uncertainty analysis.
Following poor experimental procedure; creating new and distracting performance measures;
Common pitfalls:
making poor trade-offs; creating new problems; substituting team judgment for the market.
7.1. SYSTEM REFINEMENT 125
Table 7.1 provides a summary of the performance measures. Now it is time to

system refinement stage. ask market representatives what they
think about the product, rather than about
Purpose the design. The results of this
investigation form the market response.
The purpose of the system refinement
stage is to integrate the subsystems into a The development team places the product
demonstrated, high-quality working system. in front of market representatives through
The design is refined as necessary to fix interviews, surveys, focus groups, or other
weaknesses that are identified when the direct interaction. Market representatives
integrated system is tested. are asked to evaluate the product, and the
evaluation data is captured as the market
response and stored in Section F of the
Development Outcomes
The following design information must be
present at the end of the system refinement It is vital that this evaluation be performed
stage. by market representatives, rather than the
development team, although the
development team facilitates the
Requirements evaluation process.
There are two elements of the requirements
that must be added by the end of system Tests
refinement.
Now that an integrated system is available,
the entire system (rather than just
1. Measured system performance values independent subsystems) can be tested.
The methods used to measure system
The values for performance measures performance should be recorded in
obtained in testing the integrated system transferable artifacts.
must be recorded. As the design is
refined during this stage, the updated Results of the system testing are reported
measured values are also recorded. and recorded in the requirements matrix.
As the design is refined, the predicted As the refined system is tested, changes in
values for the system will change, and the the tests may occur. Any such changes
predicted and measured values for some should be reflected in the product
subsystems may change. Changes in the development artifacts, and revisions should
measured or predicted values should be be noted in accordance with the version
reflected in revised product development control procedures for these artifacts.
artifacts, and revisions should be noted in
accordance with the revision control Models
procedures for these artifacts.
Models of system performance have
2. Market response to the product generally been created in subsystem
engineering. New models may be created
At the end of the system refinement stage, during system refinement, and existing
a prototype will exist that is faithful to the models may be changed to reflect a revised
final product design, although it was likely design. These models should be recorded
not created on the final production in transferable artifacts.
system. Because this prototype is so near
the final product, it is ideal for determining Prototypes
the market response.
The prototypes used during system
Throughout the product development refinement should reflect the latest
process, the team has been evaluating the revisions to the design and should be
quality of the product through the transferably captured in artifacts.
Design • Creating new and distracting

performance measures. It’s easy to let
There are two main elements of the refined new, unapproved performance
design. measures distract us from the
measures that have already been
approved. Avoid this problem by
1. Refined definition for the entire system carefully evaluating with the client the
As the subsystems are integrated, impact of adding new requirements
refinements to the subsystem definitions and measures.
will be necessary. The refinements should • Making poor trade-offs. Compromise
be captured in design artifacts, and is a natural part of product
revisions should be noted in accordance development. Trade-offs between
with the revision control procedures for components will have to be managed,
these artifacts. as well as trade-offs between
performance measures. To avoid
The required design information should be
making poor trade-offs, prioritize the
the same as for subsystem engineering.
requirements to match the market
wants, and make decisions that reflect
2. Complete bill of materials this prioritization.
The bill of materials should be updated • Creating new problems: Integrated
(and tracked with revision control) to products often have components that
reflect the changes that occurred during are highly interdependent. Each fix to
system refinement. a problem will possibly create new
problems somewhere else in the
Approval system. Avoid this by examining the
impact of a candidate change on each
To complete this stage, the design must be subsystem, adjusting as necessary.
checked and found to be desirable and
transferable. • Substituting the team judgment for the
market: Because the product has
Performance testing will need to have been been thoroughly tested to see how well
performed on all system performance the performance measures match the
measures. The measured values ideally target, it is tempting for the team to
would meet or exceed the target values. In assume that all is well based only on
all cases, the measured values need to be the performance measures. However,
within the acceptable limits. the performance measures were
created to substitute for the market
Before this stage is complete, validation desires, rather than being the market
with an integrated system prototype needs desires themselves. At the system
to have been performed, and the market refinement stage, it is vital to provide a
representative needs to have found the sample of the product to the market
product desirable. representative(s) and obtain their
independent assessment of the
Common Pitfalls desirability of the product. The market
judgment, not the team judgment, will
ultimately determine the success of
• Poor experimental procedure. The the product.
system as a whole should be tested
under a variety of conditions, not just Top-Level Activity Map for System
under optimal conditions. We do this Refinement
to try to identify the limits of operation.
It’s good to consider extreme practical Figure 7.1 shows a top-level activity map
conditions that could lead to failure. for the system refinement stage. There are
7.1. SYSTEM REFINEMENT 127
Run validation
tests
15 16
Make validation
Reassess and prototype
modify system
design 7
(components,
subsystems) To Producibility
14
3 6
From Identify system Reassess and Seek approval
Subsystem weaknesses modify
Engineering requirements Make testing
prototype 13
2 tests as
Make
necessary 11
system 5
prototype
Run 10 12
Assess system
sytem-wide test
4 performance
1
Run
8 performance
9 tests
OUTCOMES
1 System prototype 7 12 System performance assessment
2 Measured system performance 8 Testing prototype 13 System approval
3 List of weaknesses 9 Testing essentials Approved system

14
4 Improved tests and procedures 10 System measured performance
15 Validation prototype
5 Improved requirements 11 Assessment essentials

16 Market response
6 Improved system design
Figure 7.1: Top-level activity map for system refinement.
three important things to observe from this Example

map. First, the individual subsystems must
be integrated for a system test, leading to We now return to the human-powered
Outcomes 1 and 2. Second, after any water well drill to examine how this stage of
change is made to a subsystem, the entire development unfolded for the team. The
system must be checked and tested as a initial parts of this stage were carried out
whole (leading to Outcomes 9, 11, and 12) completely in the CAD system, where the
— and found to be desirable and various subsystems were assembled
transferable — before approval can be together into a full system. Various small
obtained. Third, as shown by the changes were carefully made to the
interdependent outcomes, iteration is often subsystems and a full system emerged.
required until the desired system The team evaluated the full system looking
performance obtained. for weak points and refinements were
made to improve them.
Table 7.2: Predicted and measured values for human-powered drill.
Performance measure Ideal Value Acceptable Target Predicted Measured

Limit
Maximum borehole 250 100 220 N/A 140
depth (ft)
Time required to cut 45 60 60 N/A 480
through 6 inches of
rock (min)
Downward drilling force 3000 500 200 1313 Not measured
(lbf)
Applied torque to pipe 400 200 300 1000 Not measured
(lbf-ft)
Drill bit compatibility 100 90 95 100 100
(%)
Water pressure down 113 50 113 113 65
pipe (psi)
Water leakage through 0 5 5 N/A Not measured
sides (%)
Fraction of cuttings 100 95 95 N/A Not measured
removed (%)
Depth cut per 8 hours 36 4 36 N/A 182
drilling (ft)
Number of people 3 12 4 4 4
required to drill
Weight of heaviest 50 400 200 332
subassembly (lbf)
Longest dimension of 48 96 96 84 84
biggest subassembly
(in)
Fraction of drill 100 85 90 N/A 66
producible in Tanzania
(%)
Production cost (USD) 1000 5000 1500 1600 N/A
Time to learn to operate 4 20 3.5 N/A 3.5
(hours)
Height of 3.5 Between 2 and 3.5 3.5 3.5
hand-operated parts 5
(in)
Drill feels comfortable Can be Can be Can be N/A Can be
operated operated with operated operated with
continuously occasional rest continuously occasional rest
without rest without rest
Drill is attractive Has a Looks like Has a N/A Has a
professional appropriate professional professional
look machinery look look
Drill interests investors Captures Is interesting Captures N/A Captures
media and when media and media and
investor explained investor investor
attention attention attention
7.2. PRODUCIBILITY REFINEMENT 129
of these refinements (and others) were

motivated by weaknesses identified during
system testing. The components and
subsystem drawings were then updated
and checked by the team.
A full set of drawings was created by the
team (represented by Figure 6.7). They
were released to a fabrication team and the
parts were made and welded into
subassemblies. The team faced very few
problems getting the subsystems to work as
intended. They owe this to the insight
gained from building and testing various
models and prototypes earlier in the
development process. The full
manufactured system, shown in Figure 7.2
as it existed during this stage of
development, was tested by the team in
various locations and under various
conditions (as described in Appendix B).
Multiple things were learned from
performing those tests, including the actual
performance achieved (see Table 7.2), and
small refinements that could be made.
The market requirements were assessed by
the client and by the users in Tanzania,
who served as market representatives.
Their evaluation of the market
requirements is shown in Table 7.3.
7.2 Producibility Refinement

The fifth stage of product development is
producibility refinement. During this stage,
the design is refined as necessary to allow
production at the rates and costs necessary
for the final product.
Note that this is not the first time
producibility has been considered. During
Figure 7.2: Acceptance test prototypes used dur-
previous stages, design for
ing the system refinement stage of development. manufacturability and assembly were
essential parts of the development process.
However, as production moves from
For example, to keep the hose that low-volume manufacturing to mass
transfers the cutting fluid (to the top of the production, weaknesses in the product and
kelly bar) from hitting the wheel as it spins, process designs are almost certain to be
hooks were added to the design. Also the discovered. As these weaknesses are
base of the hoist had open 4 inch by 4 inch found, the product and process designs are
square tubing. To avoid having the inside of refined. As process design is outside the
the tubes exposed to moisture and scope of this book, we focus on the
therefore be more susceptible to corrosion, refinements to the product design in this
end plates were added to the design. Both section.
Table 7.3: Eval-

uation of mar- Market requirement Market representative evaluation
ket requirements Drill reaches potable water beyond 100 ft Excellent
by market repre- Drill cuts through rock Acceptable (slower than desired)
sentatives. Drill uses existing drill bits Excellent
Drill seals borehole sides to prevent cave in Very good (no cave-ins observed)
Drill removes cuttings from the borehole Excellent
Drill works at an efficient speed Excellent
Drill uses only manual labor Acceptable (gas-powered pump)
Drill is affordable Very good (slightly high, but in good range)
Drill requires only simple training Excellent
Drill is portable Acceptable (heaviest piece is a bit heavy)
Drill is comfortable to operate Very good
Drill is attractive Excellent
Drill attracts investors Excellent
Table 7.4 provides a summary of the whole product. When making changes
elements of the producibility refinement at this stage of development, carefully
development stage. The elements are examine each change’s impact on
explained more fully below. every subsystem.
Purpose • Inadequate sample sizes. At this stage

The purpose of this stage is to refine the of the product development process,
design as necessary to allow a desirable we often have access to a reasonable
product to be produced in the desired quantity of the product. As such, we
quality and quantity. A key feature of this should choose adequate sample sizes
stage is fixing producibility weaknesses that for testing and experimentation, so
are identified during production ramp-up. that their results are statistically
representative of the body of products
being produced.
Development Outcomes
No new types of product information are
created during this stage. However, Top-Level Activity Map for Producibility
refinements are made to the requirements, Refinement
tests, models, prototypes, and design.
These should all be captured transferably. Figure 7.3 shows a top-level activity map
Revision control is essential to ensure that for the producibility refinement stage.
the highest quality product can be made. There are two important things to note
about this map. First, note that the stage is
Producibility testing needs to have been started when an initial production run of
performed that demonstrates the product the product is made. As the product is
can be produced at the required rate, made on the real production system,
quality, and cost. weaknesses in the design may show up
and need to be resolved. Second, note that
Common Pitfalls there is typically no market validation
during producibility refinement, as the
• Creating new problems. By this stage function of the product is not changed
of development, many designs have during this stage.
been fine-tuned so that all subsystems
are working well together. Even minor As in system refinement, iteration may be
changes to one subsystem or necessary as shown by the interdependent
component can negatively affect the outcomes.
7.2. PRODUCIBILITY REFINEMENT 131
Table 7.4: Summary of the producibility refinement stage.
Producibility Refinement: Refine the design as necessary to allow a desirable product to be produced in the desired quality and
quantity. Note that this stage is primarily about fixing producibility weaknesses that are identified during production ramp-up.
Requirements

Updated predicted and Part E of the system and
present, even if the value performance measures. If a
measured values of subsystem requirements
is N/A? Are all measured few of the targets are not met,
performance measures. matrix.
acceptable range.
Updated methods used
to predict and measure Are the test methods The tests have been carried
results demonstrating the
the performance of the complete and correct? Is out with sufficient quality and
Tests
desirability of the product.

system. Methods used there enough detail for a transferability to provide strong
Reports of producibility
to demonstrate the third party to repeat the evidence for the measured and
challenges and their
producibility of the tests? predicted values.
resolution.
product.
Engineering models
used to analyze and Model source code with run
adjust design results. Input files for
Are the models reported
Models
characteristics related to commercial software with Not approved directly; used

in enough detail to allow
producibility. Statistical run results. Excel with tests.
a third party to use them?
analysis of producibility spreadsheets. MathCAD
challenges (defects, low worksheets. Hand solutions.
rate, high cost, etc.).
Prototypes used to
Pilot-scale production runs
explore possible
Prototypes
with statistical analysis. Do the prototypes

producibility solutions. Not approved directly; used
Producibility studies on demonstrate the solutions
Prototypes used to with tests.
initial product runs and to producibility problems?
measure producibility of
refined design.
revised design.
purchased parts.
the necessary
Subassembly and assembly
components included? Is The design is sufficiently
drawings and instructions
Refined definition for the design package transferable to support
for all subsystems and the
the entire system. sufficient to allow a third production by a third party.
system. Schematic
Design

compliance with
control?
part of the design.
components
and unambiguous?
Design for assembly, design for manufacturing, design of experiments, experimentation, fail-
Useful tools: ure modes and effects analysis, fault tree analysis, plan-do-check-act, sensitivity analysis, six
sigma, theory of inventive problem solving, troubleshooting, uncertainty analysis.
Creating new problems; inadequate sample sizes; waiting until this stage to consider pro-
Common pitfalls:
ducibility.
10 9
Assess system
From System 4 performance
Run
performance
Reassess and 6 11 tests
Make initial modify
production requirements 13
run of
products
Reassess and modify Seek approval

1 system design To Post-release
5 12
(components,
subsystems) product
Identify Make
production additional
weaknesses production run
7
2 3 8
as necessary
OUTCOMES
1 Products from production run 6 11 System performance assessment
2 List of weaknesses 7 Products from production run 12 System approval
3 Improved tests and procedures 8 Testing essentials Approved system

13
4 Improved requirements 9 System measured performance
5 Improved system design 10 Assessment essentials
Figure 7.3: Top-level activity map for producibility refinement.
Example stock materials in Tanzania. During this

stage of development, the design
To solidify the principles discussed in this underwent these changes.
section, we again consider the
human-powered water well drill as an
example. A different development team The drill was also refined in unexpected
(based in Africa) worked on the ways. For example, the original handles
producibility refinement and post-release that were welded to the base of the hoist to
refinement stages. assist in hoist transport, involved three
pieces, four 45 degree cuts, two 90 degree
The design of the drill indeed underwent cuts, and four welded joints per handle.
some small refinements due to This is shown in Figure 7.4a. The refined
manufacturing considerations, some of handle required only two 90 degree cuts
which were foreseen and some unforeseen. and two welded joints. This was
For the reason that nearly all of the first four accomplished by adding two 90 degree
stages of development were carried out in bends to the piece that makes the handle,
the USA, the development team as shown in Figure 7.4b. The result is a
worked with the stock materials that could much more manufacturable, but slightly
be purchased easily in the USA. It was less comfortable, handle. As manufactured
known and planned for that the cost is much more important than comfort
manufacturing entity would convert the of setting up the drill, this trade-off was
design to one that could be produced using deemed appropriate.
7.3. POST-RELEASE REFINEMENT 133
At the true end of development (or the end

of the stage as seen in Figure 2.10), the
final/updated product design is archived,
sold, or removed from the context where
design changes can be made. A
wholehearted effort to accurately archive
the design is more valuable than most
people would believe, as the archived
design is sometimes reopened for the
purpose of starting a new design, or for
legal purposes.
Unlike the other stages, this stage of
development is not characterized by a
specific evolution in the design. This stage
may be thought of as a series of small
stages, with one stage for each specific
refinement in the product.
The need for refinement at this stage is
often driven by one of the following:
1. The need to lower costs, enhance

performance, or respond to changing
market demands.
2. The occurrence of unforeseen
problems with the product or its
production.
3. The need to maintain a particular level
Figure 7.4: Small refinements made to the drill of product performance.
during the producibility refinement stage of devel-
opment. (a) Original handle, (b) refined simplified
handle. Almost always there is a different budget
for pre-release development (opportunity
development through producibility
Although the artifacts are not shown here, refinement ) and post-release refinement.
the essential outcome in terms of design Likewise, project milestones are often
information is the updated design — in this treated on an individual refinement basis
case the definition of the updated handle. when in post-release refinement.
Table 7.5 provides a summary of the
7.3 Post-release Refinement elements of the post-release refinement
stage.
The final stage of product development
occurs after the mass-produced product Purpose
has been released to the market. During
this stage, the fully integrated, fully The purpose of this stage of development is
functioning, mass-produced product is to refine the design to improve the
refined until the owner of the design desirability of the mass-produced product.
decides to end development. While this This includes items such as reducing cost,
decision is often tied to a decision to retire increasing functionality, and eliminating
the product, these decisions need not be weaknesses that become apparent after the
related. product has been offered on the market.
Table 7.5: Summary of the post-release refinement stage.
Post-release Refinement: Refine the design to improve the desirability of the mass-produced product. This includes items such as
decreasing cost, increasing functionality, and eliminating weaknesses that become apparent after the product has been offered to the
market.
The changes in the market and
product requirements capture
Updated market and
Requirements
the market’s desires.

product requirements,
Updated subsystem and The system meets or exceeds
including the additional Are all of the matrices
system requirements the target values of the system
information that was complete and correct?
matrices. performance measures. If a
learned during this
few of the targets are not met,
stage.
acceptable range.
Are the test methods The tests have been carried
Reports on methods and complete and correct? Is out with sufficient quality and
Tests
to predict and measure

results demonstrating the there enough detail for a transferability to provide strong
the performance of the
desirability of the product. third party to repeat the evidence for the measured and
system.
tests? predicted values.
Engineering models
Models
characteristics of the commercial software with Not approved directly; used

product. Statistical run results. Excel with tests.
analysis of product spreadsheets. MathCAD
weaknesses (defects, worksheets. Hand solutions.
low rate, high cost, etc.)
Prototypes used to
explore possible Do the prototypes
Prototypes
improvements. Production runs with demonstrate both the Not approved directly; used
Prototypes used to statistical analysis. problem and the with tests.
measure producibility of solutions?
revised design.
purchased parts.
the necessary
drawings and instructions The design is sufficiently
for all subsystems and the transferable to support
system. Schematic production by a third party.
Design

compliance with
control?
part of the design.
materials information? Is it clear appropriate.
components
and unambiguous?
ure modes and effects analysis, fault tree analysis, plan-do-check-act, sensitivity analysis,
Useful tools:
six sigma, theory of inventive problem solving, troubleshooting, uncertainty analysis value
engineering.
Ignoring the market; creating new problems; inadequate sample sizes; failure to fully docu-
Common pitfalls:
ment everything.
7.3. POST-RELEASE REFINEMENT 135
Design Outcomes we often have access to an adequate

quantity of the product. As such, we
Post-release refinement often leads to should choose adequate sample sizes
updated market and product requirements. for testing and experimentation so that
As the product matures, the desires of the their results are statistically
market become more clear. This provides representative of the body of products
the opportunity to refine the requirements being produced.
and to refine the product to better meet the
requirements. As always, the requirements • Failure to fully document everything: It
should be subject to revision control. can be tempting to just do the
refinement, and get it into production,
As needed, all other elements of the design
without doing all the documentation.
are revised during post-release refinement.
Failure to document changes leads to
The revisions are captured in product
ambiguity in the product design.
development artifacts that are placed under
revision control.
Top-Level Activity Map for Post-release
Useful Tools Refinement
Figure 7.5 shows a top-level activity map
Tools for continuous improvement: Design for the post-release refinement stage.
of experiments, experimentation, There are three important things to note
failure modes and effects analysis, about this map. First, note that the stage is
fault tree analysis, plan-do-check-act started when weaknesses in the product
(PDCA), sensitivity analysis, six sigma, appear after the product has been in the
troubleshooting, uncertainty analysis, market. Second, note that there may or
value engineering. may not be significant market validation
during post-release refinement, depending
Tools for the design process: CAD on whether the functionality from the user
modeling, design for assembly, design point of view has changed. In many cases,
for manufacturing, engineering the objective of post-release refinement is
change orders (ECOs), finite element to assure that the product continues to
modeling, prototyping, theory of provide the performance identified during
inventive problem solving. system refinement. Third, note that this
map both begins and ends with
Common Pitfalls post-release refinement; the map may be
executed multiple times during the life of
• Ignoring the market: During this stage the product.
of development the team should
consider happenings in the market to As in system refinement, iteration may be
help drive decisions about product necessary as shown by the interdependent
changes. outcomes.
• Creating new problems: By this stage Example

of development, many products have
been fine-tuned so that all subsystems The human-powered water well drill is
and components are working well currently in the post-release refinement
together. Even minor changes to one stage of product development. This means
subsystem can negatively affect the the drill is in production and being used,
whole product. When making changes and that from time to time improvements
at this stage of development, carefully are made that evolve the design. The drill
examine each change’s impact on as it currently exists in this stage of
every subsystem. development is shown in Figure 7.6.
• Inadequate sample sizes: At this stage As an example of the types of changes that
of the product development process, typically occur at this stage of development,
From
Producibility
Reassess and
modify system
Post-release 6 product
design To Post-release
(components,
13
subsystems)
Evaluate 2 5
performance Reassess and
modify Seek approval
and
producibility requirements Make revised
product on
Identify system production system 12
1 weaknesses tests as 14
necessary 10
4
9 11
Assess system
3 Run performance
performance
7 tests
8 Run validation tests
OUTCOMES (if needed)
1 Product evaluation data 6 11 System performance assessment
2 List of weaknesses 7 Testing prototype 12 System approval
3 Improved test procedures 8 Testing essentials Approved system

13
14 Market response (if needed)
Figure 7.5: Top-level activity map for post-release refinement.
consider the lazy susan bearing that is the 7.4 How to Release a Design
interface between the wheel and the wheel
support. Figure 7.7 shows the bearing (has Approved designs must be released to
a silver color). The selected bearing can other parts of the organization that will use
withstand sizable axial compressive loads, the design. The design release process is
but it cannot withstand large tensile loads. straightforward, as shown in Figure 7.8.
While in use, it was observed that to get
underneath the wheel to access the drill When a design has been approved, the
string, workers would hang on the wheel for approved revisions are then conveyed to all
support. Such movements created a tensile those who have need of it. This is done by
condition in the bearing on the opposite ensuring that the revision numbers for all
side of the wheel, often tearing the bearing design artifacts are updated to reflect the
apart. After considering a variety of release and that the change history that
solutions, the team chose to remove the tracks the revision status of each
bearing from the design and simply let the component is also updated. Specific
wheel spin directly on top of the wheel methods for updating and conveying the
support. After evaluating the impact of this design will vary between organizations.
decision by considering how the market However, some process should be followed
requirements were affected, the decision to ensure that the latest approved revision
was approved. For existing drills, the is used throughout the organization. If
bearings were removed when they failed in needed, the Engineering Change Order
the field. New drills were produced without (ECO) (11.24) and Revision Control (11.56)
bearings. entries in the development reference can
help you get started with revision control.
7.6. EXERCISES 137
7.5 Summary
At the conclusion of subsystem
engineering, the design is basically
complete. However, it must be refined
based on weaknesses that are observed (i)
when the system is integrated and tested
as a whole, (ii) when the system is
produced in large quantities that expose
previously unseen weaknesses, and (iii)
after the product has been released to the
market and the actual market response has
been observed.
An essential part of refining a design is the
release of a revised version of the design.
When a design is released, its version and
revision history are updated. Maintaining a
complete revision history allows proper
support for the design throughout the
product lifecycle.
Figure 7.6: The human-powered water well drill,
marketed as the Village Drill. This figure shows 7.6 Exercises
the drill as it exists during the post-release refine-
ment stage of development. Test Your Knowledge
T7-1 List the three main refinement stages.

T7-2 List two elements of design artifacts
that are updated when a design is
released.
T7-3 What is added to the requirements
during the system refinement stage?
T7-4 What kinds of information are added
(as opposed to updated) to the
product development artifacts during
producibility refinement and
post-release refinement?
Figure 7.7: The lazy susan bearing interface be-
tween the wheel and the wheel support for the Apply Your Understanding
human-powered water well drill.
A7-1 In your own words, describe the
differences between the three main
Requirement and test artifacts may not refinement stages. Why do you think
have new revisions when a design is they are listed as three different
released. For example, test procedures stages, rather than being combined
may be standardized and may be used for into a single stage?
a number of different products. Test results
that were obtained on previous prototypes A7-2 Why do you believe there are likely to
will not be revised. However, new tests may be problems that show up in
be performed on the released design which integrating the subsystems, even
would result in new test reports and though each subsystem has been
potentially revised requirements artifacts. individually tested and approved?
Figure 7.8: A Obtain revision number and Convey design

generic activity place on design artifacts artifacts
map for releas- 1 2
ing an approved 3
design.
OUTCOMES
1 Approved design 3 Released design
2 Design with revision number
A7-3 Share an example with which you are A7-8 Write a brief stage report for
familiar where changes to a design Producibility Refinement that can be
were found to be necessary during used during the stage approval
producibility refinement. process for a project you’re working
on. Structure your report so that it
A7-4 Share an example of when answers these fundamental
post-release refinement is necessary questions: What is the refined
(Hint: you may wish to consider definition of the system? And, how
product recalls). have you demonstrated that the
A7-5 Find a design artifact (such as an refined system solves the
engineering drawing) for a product producibility problems and still meets
with which you are familiar. market requirements? As a way of
supporting the reports claims attach
a) Identify the revision and the and refer to product development
revision history for the artifact. artifacts that the team has produced.
b) If these items are found in the
artifact, what do you learn by A7-9 Write a brief stage report for
reviewing the revision history? Post-Release Refinement that can be
used during the stage approval
c) If these items are not found in process for a project you’re working
the artifact, what is lost by their on. Structure your report so that it
absence? answers these fundamental
A7-6 List some reasons you believe having questions: What is the refined
an appropriate revision history is definition of the system? And, how
helpful in providing long-term have you demonstrated that the
support for a product on the market. refined system solves the
post-release problems and still meets
A7-7 Write a brief stage report for System market requirements? As a way of
Refinement that can be used during supporting the reports claims attach
the stage approval process for a and refer to product development
project you’re working on. Structure artifacts that the team has produced.
your report so that it answers these
fundamental questions: What is the
complete system design? How well
does the system meet the
requirements? And how have you
validated system desirability to the
market? As a way of supporting the
reports claims attach and refer to
product development artifacts that
the team has produced.
CHAPTER 8
Customizing the Product
Development Process
Ultimately, every product development During development, plans evolve. It is

team needs a specific, often custom, unrealistic to believe that a plan will first be
product development process that is set, then followed without adjustment.
catered to the needs of the client and skills Interestingly, having an initial plan in place
of the team. Unfortunately, we cannot tell when unexpected problems or delays occur
you in this book what specific product allows the team to know how the plan can
development process is needed for your change with minimal impact on the highest
specific project. This is simply because level project objectives.
every project is unique and requires its own
product development process and its own
project plan. 8.1 Creating a Customized
We can, however, show you how to create,
Project Plan
evaluate, and manage your own custom A customized project plan is (i) specific to
product development process and project the project at hand, (ii) aligned with the
plan. This chapter focuses on this. capabilities of the development team, and
To be clear, we’ll define the custom product (iii) established according to the client’s
development process as the set of specific budgetary and time constraints.
activities that need to be taken to achieve a
The customized plan includes an activity
specific set of design outcomes. Further we
map (set of design activities, outcomes,
define the custom project plan as the
and their relationships) that will transition a
custom product development process with
design from its initial state of evolution to
resources (human, financial, and temporal)
the client-specified final state of evolution.
added to activities.
Ultimately, as the plan evolves over time,
Every project should have at least some each of these activities and outcomes will
plan — even if that plan is not very be defined to such a degree that they can
detailed. Whatever level of detail is chosen be assigned to an individual or subteam to
for the project plan, the following sections complete. The activities will be defined with
will guide the team or team leader in sufficient clarity that the assignee can
establishing a good plan that is likely to complete it according to the budget and
lead to success. schedule for that specific activity.

https://doi.org/10.1007/978-3-030-14899-7_8
142 CHAPTER 8. CUSTOMIZING THE PRODUCT DEVELOPMENT PROCESS
The following steps can be used to create a Step 2: Articulate Specific End-of-Stage
customized product development process Outcomes
(steps 1–4) and transition that process into
a custom plan (steps 5–6). Each one of the Implied in bracketing the development is
steps is described in more detail in the the completion of intermediate stages of
subsequent subsections. development, each of which has a generic
purpose associated with high-level design
Process for customizing the project plan: outcomes. For manufactured products that
are expected to evolve through the six
stages of development, Tables 4.1, 5.1,
1. Establish the project scope
6.1, 7.1, 7.4, and 7.5 provide the generic
2. Articulate specific end-of-stage high-level purpose.
outcomes For each of the stages of development in
3. Identify specific intermediate design the team’s scope, the team should
outcomes articulate the specific requirements that will
be needed for approval, the specific tests
4. Choose design activities that lead to that should be carried out, and the required
the outcomes state of the design at the time of approval.
Articulating these items clarifies the specific
5. Allocate resources to each design design outcomes that should appear in the
activity activity map for this specific project. This
6. Add time estimates and extract the part of the customization process caters to
project schedule. the detailed and specific needs of the
particular product being designed.
Step 1: Establish the Project Scope For teams working on products they’re
familiar with — such as the team that
As a first step, the project scope should be
annually develops a new mobile phone — it
established and stated succinctly and
will be relatively easy to articulate specific
accurately. This must be done early in the
end-of-stage outcomes. This is because of
project. The scope will not only guide the
their familiarity with the unique design
development of the customized project
patterns that exist for mobile phone
plan, and it will also guide the product
development, and because they’re likely to
development team throughout the entire
have a general idea for what the product
project. The project scope can be captured
will become, well before it is developed.
in a project objective statement, which is a
short statement about a project’s top-level On the other hand, for teams working on
scope, schedule, and resources. A products they’re unfamiliar with, or on
description of this and a method for products that have never existed before, it
creating one is found in the Development may not be possible to be highly specific at
Reference, under Project Objective the onset of the product development
Statement (11.49). process. This is because there is still so
much that is unknown about what the
An important part of this step is to bracket product will become that it’s simply not
the development, which means to possible to be specific. In such cases, it’s
determine which portion of the product’s acceptable for the team to start with
evolution your team will be working on. This generic end-of-stage outcomes, then
is done by (i) understanding the current update them when specific information
state of the design, and (ii) understanding becomes available.
the required final state of the design. The
current state and the required final state of When establishing the needed approvals, it
the design exist somewhere on the is useful to evaluate the risks of failing to
evolutionary continuum defined by the successfully meet the end-of-stage
stages of product development. Figure 8.1 outcomes (such as failing to select a
illustrates this for the human-powered drill. product architecture that can be
8.1. CREATING A CUSTOMIZED PROJECT PLAN 143
Figure 8.1:
OPPORTUNITY CONCEPT SUBSYSTEM SYSTEM PRODUCIBILITY POST-RELEASE Scoped De-
DEVELOPMENT DEVELOPMENT ENGINEERING REFINEMENT REFINEMENT REFINEMENT velopment
for Human-
Powered Water
Scope of Development for Well Drill.
Human Powered Drill
manufactured using the production team. Part II of this book (the Development
resources of the client or its suppliers). For Reference) provides a collection of
each of the risks, the team should establish potentially useful design activities.
an approval that will lessen or eliminate the
risk (such as early stage manufacturing
Step 5: Allocate Resources to Each
process approval).
Design Activity
Step 3: Identify Specific Intermediate For each of the selected design activities,
Design Outcomes the team allocates human and financial
resources to execute the activity. One or
The high-level information emerging from more members of the product development
Steps 1 and 2 are useful for uniting the team or its contractors are assigned the
team, but it provides only minimal direction responsibility of carrying out the activity
on how to proceed through the project. and accomplishing the outcome. Also, a
Step 3 solves this by establishing portion of the overall project budget is
intermediate design outcomes (or subgoals) thoughtfully allocated to the activity.
that if met would result in accomplishing
the specific end-of-stage outcomes. To do In the context of an activity map, these
this, the team breaks down each high-level resources can be specified in a variety of
outcome into smaller more manageable ways. For simplicity, we have placed a
lower-level outcomes. Decomposition is a name, and dollar amount next to each
design tool that can help the team through arrow in the activity map. For example,
this step; it is described in the Development Figure 8.2 shows an activity map for one
Reference, under Decomposition (11.14). high-level activity for a consumer
In the context of project goals, the team will electronics project.
use decomposition to ask what lower-level
things need to be accomplished in order to
meet the higher level goals? Step 6: Add Time Estimates and Extract
the Project Schedule
Step 4: Choose Design Activities That A realistic estimate of the time it will take to
Lead to the Outcomes complete each activity is made according
For each of the design outcomes resulting to the human and financial resources
from Step 3, the development team allocated to it. Any unit of time can be
chooses one or more design activities that allocated, but it is important that the same
alone or together are likely to result in the unit of time is used consistently. Generally,
outcome. Many different activities or sets of days and weeks work well for small-scale
activities can potentially result in a desirable projects, and months or quarters work well
outcome, so the selected activities are not for large-scale projects. Once estimates are
unique. These activities, together with the made for each activity, the critical path can
design outcomes resulting from Step 2, can be found and the project schedule can be
be arranged into an activity map that established. A method for determining the
captures their dependency relationships. critical path is found in the Development
Reference, under Critical Path Analysis
For the most part, this portion of the (11.13).
customization process caters to the specific
skills and preferences of the development *****
B4
B2
B1
1 T: 7 Wks T: 4 Wks
$: 3,000 $: 2,000
B7 P: Jason T: 6 Wks
T: 6 Wks P: Nichole C.
$: 12,000
T: 2 Wks $: 3,400 P: Helaman
$: 2,000 P: Carl S.
P: Alex C.
B6 B3 B5
B9
T: 4 Wks T: 24 Wks ARCHITECTURE
6
$: 3,700 $: 12,000 DEVELOPMENT
2
T: 4 Wks P: Brian S. P: Chris M.
$: 2,000 4 F
P: Elena C.
3
D 1
E
T: 2 Wks B14
5
$: 4,500 B
5
P: Enan G. C
B8 B11 B12 E B13 2 F
T: 4 Wks T: 5 Wks T: 6 Wks 6

T: 4 Wks B10
T: 5 Wks 3 D
$: 4,000 $: 3,900 $: 7,600 4
$: 3,400 $: 3,600
OPPO P: William
C G. P:2 James J. P: Carl S.
P: Derrick P: Daniel
G
SUBSYSTEM
B1 Snap Fit Requirements B6 Circuit Requirements B11 Breadboard Performance Test ENGINEERING
B2 Snap Fit Model B7 FCC Compliance Test Methods B12 Circuit Board Design k-1
n-2
k-2
7
B3 Plastics Design PRODUCIBILITY

B8 Schematic Design B13 Prototype Circuit n-1 D
REFINEMENT
B4 Mold Design B9 SPICE Circuit Simulation B14 Circuit Performance Test 4 A
k
F
E
B5 Prototype Plastics A
B10 Breadboard Design
4 n 1
3 F 5
1
6
B
C
D G
B 2
1
7 C
B 8
A
H
2 3
2
SYSTEM
REFINEMENT 9
1 B
A
2
3 4
POST RELEASE C
D 6
REFINEMENT E
3 F
Figure 8.2: Activity map with financial, human, and temporal resources added to each activity.
8.2. EVALUATING THE QUALITY OF THE PROJECT PLAN 145
For the most part, Steps 4–6 activities are affected by any proposed map
can be performed in any order. This means change before making the update.
that after the specific intermediate design
outcomes are identified (Step 3), the team
could begin by allocating a portion of the 8.2 Evaluating the Quality of the
overall resources and schedule to accom- Project Plan
plishing the outcome. Within this limitation
of allocated resources and schedule, To evaluate the quality of a custom
the team can then choose activities and development plan, we recommend that
human resources that would be suitable. each of the following questions be
deliberately asked and thoughtfully
Refinements and Adjustments to the Plan answered about the project plan.
If needed, the team can continue to
decompose each subgoal into lower-level Does It Have an Appropriate Level of
subgoals and repeat the Steps 2 through 6 Detail?
where each subgoal is the subject of This is a difficult — yet critical — question
decomposition. It is important to decide to answer. For more experienced product
how detailed to make the project plan. The development teams, it is likely that fairly
plan should be (i) detailed enough to guide high-level plans are sufficient for the team
the product to the desired state of evolution to proceed. For less experienced teams,
with minimal waste, yet (ii) not so detailed more detail will be needed simply because
that it removes the assigned individual’s team members lack the experience to
freedom to operate in the most efficient intuitively know what set of activities
and effective way. The next section offers effectively lead to accomplishing the
some suggestions that may help in desired outcomes. The plan should contain
deciding how much detail is needed. just enough detail to result in efficient team
Creating a customized project plan is an work relatively free from wasted work due
iterative process – meaning it is very to misunderstanding the scope of the
unlikely that the first plan created will desired outcomes, the available resources,
match the needs and constraints of the or the time constraints.
project. Planning can be effectively
performed in a design iteration cycle Does It Have Realistic Times Allocated?
(Section 2.2). The created plan needs to be
evaluated and adjusted until it appropriately It can be very difficult to estimate the time it
matches the needs and constraints. To will take to carry out an activity —
adjust the plan, any one or more of the especially interdependent activities.
steps above are reconsidered and the Generally activities take two to three times
impact of an adjustment carried throughout longer than most people estimate them to
subsequent steps. The next section, on take. This can be very difficult for designers
plan evaluation, offers some suggestions to deal with as there is always pressure to
that help decide what adjustments might complete activities quicker than is
be needed. Generally, the team should be estimated. When deadlines are fixed, the
confident in higher level plans before resources (human or financial) allocated to
creating more detailed plans. an activity, the scope of the activity, or both
need to be adjusted (see Project Objective
Once established and in use, the project Statement (11.49) of the Development
plan should be updated as necessary. We Reference).
note that this will likely be frequently. By
definition, because the plan is a detailed Does It Have Realistic Costs Allocated?
activity map, a change in one part of the
map can affect another part. To avoid Like time estimates, cost estimates are also
unanticipated problems, consider how difficult to establish. For many product
subsequent dependent and interdependent development activities, these costs have to
do with things such as material costs for the team know what needs to be done, by
prototypes, computing time with super what time, and with what resources. One
computers, test lab fees, and payments indication of this is if the team uses and
made to interviewees or focus groups. In updates the plan regularly. Generally the
each of these cases, estimates can be creation of the plan will be largely driven by
made using experience, or speaking about one individual on the team, such as the
the estimates with suppliers involved. team leader. It’s our belief that if the one
These costs generally don’t include the cost creating the plan is thoughtful about its
of human resources, but there would be creation and diligent in updating and
nothing wrong with including it if desired. emphasizing of the plan, the plan will
indeed be of great use to the team.
Does It Have Appropriate Approvals to
Minimize Risk?
8.3 Using the Customized
Thinking about what might not go well Project Plan
during the process of evolving the product
from its initial state of evolution to the final The custom project plan represents what
desired state is a valuable activity. The the product development team will do to
custom plan will be most successful when advance the design through the stages of
it is focused on creating approved designs development, but it does not represent how
as opposed to just any design. To that end, they will do it. For example, imagine two
establishing the appropriate approvals is product development teams with identical
essential. For any industry there is project plans for evolving two products for
generally a set of required approvals or the same market. How the team progresses
standards that must be met, such as the through the map — with what level of care
UL 94 flame retardancy standard that and with how much enthusiasm — has a
exists for most consumer electronics. Be large impact on the cost and quality of the
sure to understand the required approvals product development effort.
and standards that must be met for your
specific project. These are sometimes In order to ensure that the resulting
unspoken because they are so commonly product is both desirable and transferable,
understood and therefore assumed. the project should be both well planned
and well managed.
Does It Capitalize on the Strengths of the
People Assigned? In this section, we describe project
planning and management as the two
Remember that there are often various halves to the common maxim “Plan your
ways to accomplish the intermediate work, then work your plan.” The first half is
outcomes of a project. The plan should accomplished through project planning;
reflect activities the team is good at, or the second, through project management.
enjoys doing. If the plan requires an
outcome the team is not capable of Without project planning, the approach for
achieving alone, the plan should be transitioning the design through the stages
coordinated with entities outside of the of development is not clearly defined. This
team such as a supplier. Also, within the makes it difficult, if not impossible, for all
team, the activities should be distributed team members to pull together to
such that the burden is appropriately accomplish the project goals. Without
shared and that individuals and teams are project management, there is no guarantee
asked to carry out activities that align with that the team activities will be coordinated
their skills and interests. to achieve the plan. Instead, the project
may end up at an entirely different place or
take significantly longer than planned for.
Is It Useful?
The most important part of evaluating any We now discuss both Project Planning and
plan is to ask if the plan is useful in helping Project Management in more detail.
8.3. USING THE CUSTOMIZED PROJECT PLAN 147
Project Planning Project Management

The goal of project planning is to The goal of project management is to
completely define the whole activity map in ensure that the project plan is followed, or
the context of the product and project that any necessary deviations from the plan
needs, development resources, and are carefully and thoughtfully executed. A
schedule implications of the project. This secondary goal of project management is to
typically includes defining the following: be able to give an accurate status update at
any time. Status should include project
state, resources used and remaining, and
• Scope
time state (ahead of schedule, on
– Starting state schedule, or behind schedule).
– Ending state In general, there is no formal test or
– Breadth of development project validation of project management. On a
regular basis however, the current
• Schedule performance of the team should be
compared with the planned performance.
– Calendar time available to
complete the project In many cases, there is no formal
– Milestones between the start and deliverable associated with project
end management. But an accounting of the
project status should be tracked by the
• Resources team for self-evaluation, and reported to
the client on a regular basis.
– Available money
– Available equipment, tools, Useful Tools for Project Planning and
software, etc. Management
– Available people Gantt charts, activity maps, critical path
– Stakeholders identification, PERT charts, work
– Team members breakdown structure, project planning
software.
– Approvers
• Trade-off criteria Things to Watch Out for

– Some understanding of what will
most likely be adjusted in the Avoiding planning
event of unforeseen difficulties. At the beginning of the project, it feels
Do we adjust the ending state of like not enough is known to produce a
the project (scope), the amount good plan. It can be tempting to wait
of resources allocated until more is known. This can lead to a
(resources), or the amount of state of perpetual working, but with no
calendar time allocated plan. It is far better to begin with a
(schedule)? tentative plan and then refine it as
more information is obtained.
The top-level project plan should be Perpetual planning

approved by the client. Once it is approved, It is possible to get so involved in the
the team can move ahead more confidently, planning process that the team never
knowing the client has some ownership in moves to a whole-hearted execution of
the plan. Any changes to the plan should it. It is vital to move to execution at the
be openly discussed and validated by the appropriate time. Deciding the
client. The project plan will generally appropriate time is a matter of
include a project contract and schedule. judgment.
Ignoring the plan information, which they crafted into the

For some teams, the plan can following project objective statement:
unfortunately be viewed as a hurdle to
get over, or a hoop to jump through. In Design, build, and test a human-powered
this case, once the plan is created, the drill that reaches underground potable
team (sometimes unconsciously) water at depths of 250 ft in all soil types by
March 25, 2011 with a prototyping budget
moves ahead as if they had never of $2,800 USD and for less than 1,700 man
made the plan! hours of development.
Making the planning documents the goal

The objective of the project is to Because the team needed to produce a
change the state of the design. The complete system for field testing, and
plan is a means to this end. In error, recognizing that some work had already
the team can make project been done, the team bracketed the
management the goal, instead of the development to be from the middle of
means to the end. opportunity development to the end of the
system refinement stage of product
Pretend plans and statuses development. The scope of development
Unfortunately, some will feel the for the drill is illustrated in Figure 8.1 and a
pressure to tell the stakeholders what set of high-level development milestones is
they want to hear, instead of sharing provided in Table 8.1.
reality with them. To be effective, the
plan and the status of its execution
Step 2 (Example): Articulate Specific
must reflect the reality of the project.
End-of-Stage Outcomes for the
Human-Powered Drill
We believe that one of the greatest From Step 1, the team knew that it would
variables at our disposal in developing a transition the design through the first four
product is the product development stages of development. Using
process itself. To that end, we have Tables 4.1, 5.1, 6.1, 7.1, the team
presented a 6-step method for creating a articulated — as specifically as it could be
customized product development process given the novelty of the product — the
and have shown how it can be more fully specific end-of-stage outcomes for the
detailed into a unique project plan. human-powered drill. Table 8.2 shows the
team’s result for Step 2.
8.4 Human-Powered Drill
Example Step 3 (Example): Identify Specific
Intermediate Design Outcomes for the
Let us now examine how the customization Human-Powered Drill
process unfolded — at the onset of the As the project started, the team identified a
product development process — for the few intermediate design outcomes that
human-powered drill. We note that as would help it achieve the end-of-stage
development continued for this project, the outcomes. Later, as more become known
plan presented here became more and about the drill, additional specific
more detailed as more and more became intermediate design outcomes were
known about the selected architecture and identified and added to the plan.
the unique subsystem engineering
challenges. For the opportunity development stage, to
be able to acquire a deep understanding of
Step 1 (Example): Establish the Project the product expectations, the team
Scope for the Human-Powered Drill identified a few specific outcomes to
pursue: (i) understanding WHOlives.org’s
Through thoughtful discussion with the wishes for the project, (ii) a summary of
client, the team gathered essential scope information gained from well driller
8.4. HUMAN-POWERED DRILL EXAMPLE 149
Table 8.1:
Development Milestone Target Date Development
Opportunity development stage complete 30 Sep 2010 milestones for
Concept development stage complete 30 Nov 2010 the human-
Subsystem engineering stage complete 31 Jan 2011 powered water
System refinement stage complete 25 Mar 2011 well drill project.
Final, pre Tanzania, design review 15 Apr 2011
Field testing in Tanzania 15 May 2011
interviews, (iii) a summary of information Step 4 (Example): Choose Design

gained from internet research, and (iv) a Activities That Lead to the Outcomes for
summary of information gained from the Human-Powered Drill
benchmarking other competitive drills.
For each outcome, one or more design
For the concept development stage, the activities are chosen to lead to the
team decided that they needed an outcome. For the outcomes listed in Step
understanding of operator fatigue 3, the team decides to do the following.
(Outcome 2 in the concept development For the opportunity development stage: (i)
stage of Figure 8.3), labor ergonomics interview the client (WHOlives.org), (ii) craft
(Outcome 3), rate of cuttings removal (4), and revise the project objective statement,
chip settling in a slurry pond (5), pump (iii) interview well drillers, (iv) do internet
pressure (6), mechanical advantage (7), research, (v) benchmark competitive
and manufacturing cost (8). Low-cost products, and (vi)
evaluations of many prototypes were discuss/brainstorm/establish product
chosen to achieve Outcomes 2 through 5. expectations based on interviews, internet,
Low-cost analytical models were chosen to and benchmarking data.
achieve Outcomes 6 and 7, and simple
cost-estimating models were chosen to For the concept development stage: (i)
achieve Outcome 8. create and test a low-fidelity prototype to
predict user fatigue, (ii) create and test a
For the subsystem engineering stage, the low-fidelity ergonomics prototype, (iii)
team chose to have each subsystem tested create a simple test to measure rate of dirt
thoroughly and under harsh conditions — removal and run the test, (iv) create and
even though the team did not know what test a chip settling prototype, (v) create a
those subsystems would be when they predictive measure of mechanical
identified this intermediate outcome. The advantage, (vi) develop a predictive model
team hoped that it could use the results of required pump horse power, and (vii)
from each test as a way to identify create a preliminary cost model. These
problems and push to correct them before activities are shown a B–H, respectively, in
the next drilling test. The subsystem tests Figure 8.3.
are represented by compound Outcomes For the subsystem engineering stage: (i)
14 and 15 in subsystem engineering in test each subsystem under harsh
Figure 8.3. conditions to expose weakness, (ii) refine
each subsystem to strengthen weaknesses
For system refinement, the team planned
identified during tests, and (iii) retest each
to have the entire drill system tested in
subsystem to prove it has been
Utah. They also planned to have the entire
strengthened.
drill system tested in Tanzania. These tests
are compound Outcomes 5 and 10 in For the system refinement stage: (i) test the
system refinement in Figure 8.3. entire integrated system in Utah, and (ii)
Table 8.2: Specific end-of-stage outcomes for human-powered drill.
Opportunity Development:
Requirements (required content at the end of stage):
Market requirements, performance measures, requirement measure relationships, and ideal values
(sections A-D) of the human-powered drill requirements matrix
Tests (required content):
None
Design (required content):
None
Validation for approval:
Do the ideal values seem reasonable to WHOlives.org (for better or for worse, WHOlives.org was chosen as
the market representative for the human-powered drill project)? Does WHOlives.org know of any missing
performance measures or market requirements that are not captured in the requirements matrix? Does
WHOlives.org believe the importance values are correct?
Concept Development:
Target values for the drill performance in the system-level requirements matrix. Sections A-D and target values
for subsystem requirements matrices.
Modeling methods used to predict performance of the drill concept and test methods for prototypes used to
measure performance of the drill concept.
Overall concept for the drill. Decomposition of drill into subsystems. Interfaces between subsystems.
Predicted and measured performance of the drill concept is consistent with the established target values.
WHOlives.org is happy with the concept as expressed in the prototypes and sketches.
Subsystem Engineering:
Predicted and measured performance values in the drill’s subsystems requirements matrices. Predicted
performance values of the drill in the system-level requirements matrix.
Updated methods used to predict and measure the drill and subsystem performance.
Design for each of the drill’s subsystems. This will include a bill of materials, engineering drawings of custom
parts, purchasing specifications for off the shelf parts, system assembly instructions, piping diagram for cutting
fluid.
Does the measured performance meet or exceed the target performance? Is it within the acceptable limits?
Where possible WHOlives.org will critique prototypes and performance data resulting from this stage.
System Refinement:
Measured drill performance values in the requirements matrix. Refinements to predicted and measured
performance values for the drill’s subsystems in the subsystem matrices.
Updated methods used to predict and measure the drill and subsystem performance.
Refined design for the entire drill.
Does the measured performance meet or exceed the target performance? Does WHOlives.org and other
market representatives in Tanzania find the product desirable?
8.4. HUMAN-POWERED DRILL EXAMPLE 151
CONCEPT
II
III
IV
Figure 8.3: Customized activity map for human-powered drill, reflecting specific intermediate design outcomes for the
drill.
test the entire integrated system in the fact that the human-powered drill
Tanzania. project only covered the first four
Once chosen, each of these activities can
be represented in the design activity map. • The plan evolves as more information
For readability (based on the constraints of is gained. In this example, we chose to
a layout), we show this for only the describe the custom plan as it existed
opportunity development stage. The activity very early on for the team — at the
map is shown in Figure 8.4, along with the onset of the product development
resource allocation from Step 5. process. As a result, the plan is
somewhat specific but still very
Step 5 (Example): Allocate Resources to generic. The plan will evolve as the
Each Design Activity for the requirements, tests, and the design
Human-Powered Drill evolve. As a result, it’s OK that the
For each chosen activity in the activity plan be a detailed plan in the near
map, resources are allocated to its future, and a less detailed plan in the
completion. This includes human, distant future.
financial, and temporal resources. • There are various acceptable plans.
Figure 8.4 shows the result of this step for Numerous plans could have been
the opportunity development stage. Notice created to achieve the outcomes. Any
that stage completion date from Table 8.1 alternative choice for the intermediate
has been included in the figure. This is to design outcomes, the activity, the
facilitate Step 6. estimated duration, the finances
allocated, or the person assigned to
Step 6 (Example): Add Time Estimates lead the activity would constitute a
and Extract the Project Schedule for the different plan. Various acceptable
Human-Powered Drill plans can result from the flexibility
available.
A project schedule for the entire project
can be extracted once resources have been • There are many unacceptable plans.
allocated to all the activities in the activity While there are various acceptable
map. Critical path analysis (see the plans, we must also recognize that
Development Reference) can be used to do there are many unacceptable plans
this. For the activity map shown in that will not lead to meeting the design
Figure 8.4, the critical path analysis outcomes. For example, choosing to
indicates that all activities except interview interview the client for the first time
well drillers are on the critical path. This only after the performance
means that (based on the allocated time expectations have been
resources) no activity, except interview well discussed/brainstormed/established
drillers, can be delayed without by the team would be a mistake since
consequently delaying the 30 September the performance expectations need to
2010 milestone. The extracted schedule is reflect the expectations of the client
shown in Table 8.3. and other stakeholders.
Discussion • The best plan will have the following

characteristics. It will:
Various observations can be made about
– Produce the desired outcomes
this example that may help you as you
while simultaneously meeting the
create a custom project plan for the first
desired budget and milestone
time.
goals.
• The resulting plan is unique to the – Make the best use of product
project. Figure 8.3 reflects specific development resources (human,
outcomes and activities that apply only financial, and temporal).
to the drill. Also Figure 8.3 conveys
8.5. SUMMARY 153
3
Interview well drillers
T: 3 days
$: 80
P: XiaoWei
Craft and revise Search internet

project for drilling
objective technology Discuss/brainstorm/establish
statement 2 information requirements based on
Team and Interview client interviews, internet, and
project 1 T: 5 days benchmarking data
T: 3 days T: 5 days
assignment $: 0 $: 0
$: 0 Benchmark P: Sabin 4 7
P: Ken P: Elizabeth T: 7 days
Start as early as competitive
$: 0 Complete by
01 Sept 2010 products P: Ken
end of
T: 5 days 6
$: 200 5 29 Sept 2010
P: John (21 working
days after
earliest possible
start date)
OUTCOMES
1 Understanding of client wishes 4 Internet research summary 6 Market research summary
2 Project objective statement 5 Benchmarking summary 7 Initial requirements for drill
3 Well driller interview summary
Figure 8.4: Resource allocation to the human-powered drill project (opportunity development stage only).
Table 8.3:
Activity Scheduled Required Development
Start Date Completion Date schedule for the
A. Interview WHOlives.org 01 Sep 2010 03 Sep 2010 human-powered
B. Craft and revise project objective statement 07 Sep 2010 13 Sep 2010 drill (opportunity
C. Interview well drillers 14 Sep 2010 20 Sep 2010 development
D. Do internet research 14 Sep 2010 20 Sep 2010 stage only).
E. Benchmark competitive products 14 Sep 2010 20 Sep 2010
F. Discuss/brainstorm/establish product expectations 21 Sep 2010 29 Sep 2010
– Facilitate a common means that the product development

understanding (among team process itself is one of the greatest
members) of specific design variables at their disposal.
activities, their outcomes and
relationships. Six steps can be followed to develop a
custom plan for any specific project. Those
– Be detailed enough to guide the steps are (1) establish the project scope,
product development process, (2) articulate specific end-of-stage
yet flexible enough to allow outcomes, (3) identify specific intermediate
individuals to apply their design outcomes, (4) choose design
individual strengths to the activities that lead to the outcomes, (5)
project. allocate resources to the each design
activity, and (6) add time estimates and
extract the project schedule.
8.5 Summary
Project plans need to be made and
Every project needs its own custom product managed. Project plans must have an
development plan. The team’s opportunity appropriate level of detail, have realistic
to construct that plan in such a way that timeframes, have realistic costs, have
maximizes efficiency and effectiveness appropriate approvals to minimize risk,
capitalize on the strengths of the team, and b) What stage of development is it

be useful for managing the work on the currently in?
project. c) What is the next development
Key risks of project planning include milestone?
avoiding planning, perpetual planning, d) How much time and money do
ignoring the plan, making planning (rather you expect it will take to
than evolving the product) the goal, and advance the design to the next
making pretend plans and statuses. milestone? Do you have enough
time and money available to
reach the milestone?
8.6 Exercises
A8-3 Describe the difference between a
Test Your Knowledge customized product development
process and a customized product
T8-1 List the steps in the process for development plan.
customizing the project plan. A8-4 The order of steps 4-6 of the process
T8-2 List six questions that can be asked for customizing a product
to evaluate the quality of a development plan is interchangeable.
customized project plan. How would your thinking differ if you
completed these steps in the order
T8-3 List five potential pitfalls in project 6-5-4 instead of 4-5-6?
planning and management.
A8-5 Using the critical path method, find
T8-4 List the three major elements of a the critical path for the activity map
project plan that may need to be shown in Figure 8.2.
adjusted when unforeseen difficulties
arise.
Apply Your Understanding
A8-1 Give an example of a project where

you underestimated the time
required for completion. What is the
approximate ratio of the actual time
to the estimated time.
a) What criteria would you expect
to use when assigning human
resources to particular design
activities?
b) What criteria would you expect
to use when assigning financial
resources to particular design
activities?
c) In general, how do you expect
to know when a design activity
is complete?
A8-2 Consider a development project you
are working on now.
a) What stages of development
does your project cover?
CHAPTER 9
Seven Ways to Become a Better
Designer
This book has been mostly about the 9.1 Expect Challenges
mechanics of product development; the
concept of product evolution, its stages of Simply stated, product development is
development, and a process for planning difficult — very difficult. Great designers
design activities that promote that understand this and work to minimize
evolution. All of these things are meant to difficulties — but they are not overly
help you become better designers. At some surprised or frustrated by the challenges of
point, however, the mechanics of product product development.
development fade into the background and
our natural design instincts and experience What makes product development so
take over. That’s not to say the mechanics difficult?
are ignored, it simply means that our One of the greatest challenges of product
design intuition becomes well-aligned with development is uncertainty. What is known
the fundamental mechanics of the process. about the design, or even the opportunity,
is uncertain and incomplete especially at
The goal of this chapter is to share some the beginning of the product development
non-mechanical things that will help you process. Great designers seem to embrace
become better designers. this uncertainty and learn to work with the
information that is available, filling in with
Over the years we have observed many appropriate assumptions and updating
new designers become great designers as their thinking and approaches as new
they have done the things described in this information is discovered.
chapter. We believe that these seven things
(Sections 9.1–9.7) will help all of us If you’re expecting the problem to be neatly
become better designers and find greater prescribed, or to develop a solution without
fulfillment and success in our product bumps along the way, you’ll be
development. disappointed and frustrated. Embrace the

https://doi.org/10.1007/978-3-030-14899-7_9
158 CHAPTER 9. SEVEN WAYS TO BECOME A BETTER DESIGNER
uncertainty and ambiguity and consider it 9.2 Be Mindful of the Design

your job to thrive in that environment.
Great designers understand that the final
Another challenge is that there are almost design will emerge little-by-little in an
always competing design objectives. It’s evolutionary way. Ideally, everything the
just not possible to give the client the least designer does advances the design to a
expensive and the most reliable vehicle on higher state of desirability or to a more
the road at the same time. Therefore the ready state of transferability. The greatest
designer has to strike a balance between designers are always aware of (i) the
competing objectives — keeping in mind current state of the design (in its evolution),
the interests of everyone involved. This (ii) the final desired state of the design, and
means choices have to be made — tough (iii) how their current actions are leading to
choices that require you to give up some the final state. Great designers use this
good performance in one area to gain better information to take control of the design
performance in another. Great designers and facilitate its evolution. This is so
know this will happen and are ready to different than the designer who passively
tackle those competing objectives without lets the design become what it becomes
being surprised or frustrated by them. with only minimal coaxing.
Great designers seem to deal really well
with the challenges of time. They are As an example of minimal coaxing, we’ve
acutely aware of the time remaining to seen some designers build analytical
complete a project. They don’t ignore this models solely for the sake of analysis,
universal constraint. At the same time, they without a deep understanding of how those
realize that there is never enough time and models will impact the design. But great
that the design can always be improved designers don’t do this. They are quite
further with more time. But they never use aware of what they’re working on and
this as an excuse to do a poor job; they precisely how the design might advance if
develop the best possible product in the their work is successful.
time available. They learn to negotiate with
the client to refine the scope of the project
as time goes on. 9.3 Be on the Team
Working on a team is a challenging part of
In any project, there are team objectives
product development. Almost all teams go
and personal motives — and for some
through a phase of conflict where they are
people these two motives can be at odds.
learning to work with one another. Great
But not for great designers. They align their
designers are flexible when working with
personal motives with the team objectives
others, yet firm in their dedication to
so that their efforts support not only their
developing the best product. To minimize
personal interests but also the objectives of
conflict, the greatest designers seem to
the team. This is not to say they become
fight for the needed design outcomes while
submissive and robotic. Great designers
conceding that a number of different
have and share their opinions, but they are
activities could lead to that outcome.
not opinionated.
Knowing that there are many right ways to
do something reduces many team conflicts. When good designers consider the full set
When there are conflicts, great designers of product development stages, they see
try to minimize the time lost by seeking to that it is very unlikely that a single person
resolve them quickly and effectively. will possess all the skills alone to evolve the
Product development can also be difficult design through all of the stages. Great
when we lack a particular skill that is designers are aware of their own limitations
needed to carry out the project. Great and recognize the strengths that others
designers are aware of their own skills and bring to the team. They truly believe that
know when and where to quickly learn the best solution is the team solution — not
something new or how to find help from the solution from any one individual.
someone with greater expertise.
9.5. EMBRACE MULTIFIDELITY MODELS AND PROTOTYPES 159
Figure 9.1:
DIVERGE CONVERGE The pattern of
diverging by
creating alterna-
tives from which
to choose and
CREATE CHOOSE
converging by
OPTIONS OPTIONS making choices
from among
these alterna-
tives is one of
the hallmarks of
a great designer.
Figure after
Brown (2009).
Great designers also know how to give and 9.5 Embrace Multifidelity
receive feedback in a team setting. The Models and Prototypes
feedback they give seems to be based only
on getting a better design, not on criticizing Many novice designers believe that
fellow team members. They are willing to predictive models and physical prototypes
see other people’s views and are slow to be need to be quasi-perfect to be valuable.
defensive to critiques. The best designers don’t believe this at all.
You can take a shoebox and drop it in front
9.4 Diverge Then Converge of a great designer and call it a defibrillator
and the designer will understand and
Great designers know that before appreciate that it is a low-fidelity prototype.
converging on a design there must exist a She’ll immediately begin thinking about if
period of divergent exploration (see this is the right size for a defibrillator, how
Figure 9.1). During this period, many heavy it might be, how it would be used,
diverse (and potentially wild) options are and what additional design information
briefly considered. By considering these would need to be defined before a
options, the designer forms a sort of design higher-fidelity prototype could be built.
space in the mind that allows him or her to Great designers value these low-fidelity
envision where the best spots of the design prototypes because the amount of learning
space are. Those best spots are then and thought provoking imagination is very
further explored. high compared to the cost of making it.
Great designers don’t believe that the best At the same time, great designers value
design is the first design that pops into high fidelity prototypes, knowing that the
one’s mind; and in the rare case where it is, cardboard box is inappropriately crude for
it is only considered the best once many seeking feedback at a trade show. For that,
other diverse designs have been great designers prepare a different
considered. prototype. Importantly, great designers do
At the same time, great designers not value only low-fidelity prototypes or only
understand when the time for divergence high fidelity prototypes, they value both
has past and the time for convergence depending on the goal of the prototype.
takes over. Even though divergent thinking The same is true with predictive models. A
is fun and exhilarating, and there are so low-fidelity prediction that points the
many uncertainties that make it difficult to designer to the main variables that can be
converge on a single design, great changed to get a desirable outcome is very
designers are not afraid to tackle this head valuable. The best designers know when
on. They understand the importance of best to use both low and high fidelity
making decisions that eliminate options models.
and have the discipline to do it.
160 CHAPTER 9. SEVEN WAYS TO BECOME A BETTER DESIGNER
9.6 Validate Assumptions would. There are just too many unknowns
until we try it. In anticipation of this, great
Many assumptions will be made during the designers always have a back-up solution
product development process — mostly as brewing in the back of their mind. When
a way of avoiding stagnation. Great things don’t work out as planned those
designers know, however, that every back-up solutions have already been
assumption left unvalidated is a seed that thought about to some degree and can
can potentially lead to failure. quickly come to the rescue of a previous
failed attempt. Most often, these back-up
Assumptions come in every flavor during solutions are small changes to the design
product development. It may be an that improve the chances of desirable
assumption about friction or inertia. Or it functionality, not radical changes that are
might be an assumption about the cost of also unlikely to work on the first try.
components purchased in bulk. Or the
assumptions about manufacturing labor
rates. But the assumptions most likely to 9.8 Beyond These Seven
lead to failure are assumptions about what
the client and market want. Novice Suggestions
designers often use their own preferences
and paradigms as a substitute for those of Becoming a better designer is a lifelong
the client and market. This is a mistake pursuit. This doesn’t mean you can’t
great designers don’t make. Almost always become a great designer now — in fact you
this mistake leads to products that are can. But in this broad field of design —
loved by the designer, but not so loved by one that requires skills in creativity,
the client or market. analysis, craftsmanship, ethnography,
manufacturing, statistics, and on and on
One of the realities of product development and on — there is room for each of us to
is that the designer is a sort of facilitator, become better.
facilitating the process of evolution. He or
she is the connection between the client While we have listed seven ways we have
and the product that he or she wants. seen many new designers become better,
Great designers listen to the client and the you may already be great at these seven
market. They ask thoughtful questions things. If that is the case now, or when that
without leading the client to a hoped-for becomes the case, we encourage you to
answer. They follow up with more questions find a few new areas to develop
— seeking a deeper understanding — competence in while maintaining your
knowing that the questions are also helping deeper competency in the area that people
the client discover what he or she really have come to rely on you for. We believe
wants. that doing this will not only bring you
greater fulfillment in your product
Great designers consider data to be a development pursuits, but it will put you in
valuable part of validation and are doubtful a better position to serve the client and help
when key decisions are made without him or her deliver a product that the market
sufficient data. They appreciate data that truly loves.
comes from both quantitative and
qualitative tests because he or she knows
that both kinds of tests may be needed to Apply Your Understanding
successfully develop the product.
A9-1 Write a short paragraph articulating
your competencies others have come
9.7 Always Have a Back-Up to rely on.
Solution
A9-2 Develop a specific plan to increase
Many of the things we design are not going your competence in one of the seven
to work at first the way we thought they ways to become a better designer.
9.8. BEYOND THESE SEVEN SUGGESTIONS 161
A9-3 List a few back-up solutions you have

for a particular project you are
currently working on.
A9-4 List some unanticipated problems
that have appeared in a product
development project you are familiar
with, and how those problems were
overcome.
A9-5 Describe a time when you
abandoned a product development
activity because you realized it was
not contributing to the evolution of
the design.
A9-6 Tell how a clear focus on evolution
caused a product development effort
to move forward rapidly and
efficiently.
A9-7 What suggestions would you give to a
novice designer about receiving
feedback on product development
work?
A9-8 What actions can be taken to align
personal motives with team
objectives?
A9-9 How does the diverge-converge
process in this chapter relate to the
Controlled Convergence method
described in Controlled Convergence
(11.10) of the Development
Reference?
CHAPTER 10
Conclusion
Looking back now at my1 first trip to Taiwan the development team’s job is to
— the one where I worked on the docking create a design, rather than to create a
station — I can see that it changed me. I product.
can even pin-point where it happened and
how I changed. I was on the flight, in a • Successful designs are desirable and
comfortable seat on the upper deck of the transferable. Transferable means that
Boeing 747. As I sat there reading a the production system can use the
product development textbook trying to get design to manufacture the product as
ready for the wave of product development the development team intended with
activities that would happen when we no outside communication. Desirable
touched down, I remember thinking I can means that the product manufactured
do this! I gained confidence that product in accordance with the design will be
development was not only for the elite, but desired by the market.
that I could do it too and do it well. Even
• The design evolves throughout the
though I was in my last year as a university
product development process. From
student, I transitioned — at that moment
its initial state, the design evolves until
— from being student of product
it has a fully detailed, transferable
development to being a product developer.
design that can be released to a
The goal of this book has been to help you production system. After being
transition into an effective product introduced to the market, the product
developer, whether you’re designing is periodically refined throughout its
docking stations or landing gear for the lifetime.
747. To that end this book has introduced
• Effective product development evolves
exactly what I needed to know — when I
the design in stages. Each stage has a
was on that plane — about how products
unique focus in the product evolution.
are created. To summarize, these are the
Later stages are not begun until the
key points we’ve raised in this book:
results of earlier stages have been
approved as meeting the requirements
• Products are manufactured by a for desirability and transferability.
production system, not the
development team. This means that • Three things evolve during the product
development process: requirements,
1
This is Chris’s personal experience. tests, and the design. All three are

https://doi.org/10.1007/978-3-030-14899-7_10
164 CHAPTER 10. CONCLUSION
necessary to achieve a desirable and We believe that the points articulated above
transferable design. will help anyone, novice or expert, improve
the effectiveness of their product
• Models and prototypes are an
development work. But mechanically
essential part of developing
following these points and other principles
engineered products. Rather than
taught in this book will not produce the
evolving, models and prototypes are
desired outcomes. Product development is
created based on the design at the
a creative endeavor, and requires emotional
time the model or prototype is created.
and intellectual investment from the
Models and prototypes are used to
development team.
predict and test performance, and to
obtain market validation of the As you are learning, product development
desirability of the design. is fun, challenging, difficult, exciting,
• Design evolution happens in small stressful, and exhilarating. Developing
increments, where proposed changes successful products requires the best
are implemented and evaluated. If the efforts you have to give. We encourage you
changes are desirable, they are to rise to the challenge, and find the joy of
adopted as part of the transferable creating products that meet human needs
design. and make the world a better place.
• There are crucial design skills for Happy product development!
effective product development. These
skills include planning, discovering,
creating, representing, modeling,
prototyping, experimenting, evaluating,
deciding, and conveying.
• Product development is carried out by
teams, and coordination among team
members is essential for efficient
product development. An activity map
provides a visual representation of the
coordination plan. Effective project
management coordinates the activities
of individual members to follow the
coordination plan.
• The best product development
process must be customized for an
individual development project and
team. Only by customizing the process
to the specific development situation
can the efficiency and effectiveness be
maximized.
• At its core, design is a human activity.
The best designs are likely to be
created by the best designers. Seven
suggestions for becoming a better
designer are (1) expect a challenge,
(2) be mindful of the design, (3) be on
the team, (4) diverge then converge,
(5) embrace multifidelity models and
prototypes, (6) validate assumptions,
and (7) always have a back-up
solution.
Part II
Product Development Reference
165
CHAPTER 11
Product Development Tools and
Techniques
The product development reference in this chapter provides a brief introduction to various
tools and techniques that are useful in product development.
Each entry in the development reference has a title (name of tool or technique) and short
statement about why that tool is useful, followed by basic information and how-to guides.
Many entries provide sources for further reading.
To facilitate finding information in the development reference, the tools are ordered
alphabetically. Further, the colored tabs on each entry indicate the stages of development
for which the tool is often helpful. Related entries can be found by referring to the See
Also section of each entry.

https://doi.org/10.1007/978-3-030-14899-7_11
168
OD
CD
11.1 Basic Design Process
SSE Develop a refined solution that meets real needs
The basic design process is a five-step process used to help designers be effective.
SR
Nearly all types of design can be generalized by the basic process shown in the
figure. When carried out thoughtfully, the process leads to good designs.
PR
How to do it
1. Understand the need: Start by trying to understand the problem that needs to
PRR be solved. Learn about who has the problem and what their needs and wishes
are for the design. Engage in research and discussion to learn. Try observing
users to learn about the problem.
2. Explore concepts: Once you understand the main problem, you can start
exploring concepts to solve that problem. It’s helpful to explore the possibilities
by considering lots of diverse concepts. With many options on the table, you
can confidently converge on the concept you believe has the most potential to
solve the problem.
3. Define the design: Add details to the selected concept, giving it a more precise
Basic Design Process
definition. Add enough detail so that you can develop a model of the design
and predict its behavior. Experimenting with those models will help you define
a good design and show others how well it will work. Experimenting with
prototypes can also be useful as it will help you understand phenomena not
captured by your predictive models.
4. Test the design: Test your design to explicitly see if it meets the identified
needs. Try making and testing prototypes to better learn how well your design
works in a real life setting. Evaluate the results of your testing and the quality of
the design. Share your prototypes with potential customers to obtain their
evaluation of the design.
5. Refine the design: If the tests reveal that improvements should be made, refine
the design by returning to one or more of the previous steps. Expect the design
to need refinement; it is unlikely for anyone to create the best design with just
one pass. Eventually, after refinement, the tests will reveal that the design
sufficiently meets the needs.
Common design approaches

In addition to the steps listed above, the basic design process includes common
design approaches. These approaches can be applied to a variety of specific
activities, which should be chosen to meet the needs of an individual project.
Engage: It is important for designers to see other perspectives, different from their
own. To do this, designers will need to engage with the outside world. They will
talk to people, listen to their story, and get to know their needs and wishes for a
solution. They can also become familiar with similar needs and how they’re
solved in a different setting. This can help establish the constraints/limits of a
new solution.
Observe: What people say is often different from what they do. Designers who work
based solely on what their customers say often miss important customer needs
that make the difference between a product customers truly love and one that
merely satisfies them. To observe, pay attention to body language, non-verbal
audible cues, and to responsiveness. Also pay attention to the physical
surroundings, including wear patterns and work-arounds.
169
OD
CD
Engage Diverge Model Prototype
SSE
Understand Explore Deﬁne Test Reﬁne
the need concepts the design the design the design
SR
Observe Converge Experiment Evaluate
Graphical representation of
the Basic Design Process PR
Diverge: When designers diverge, they explore many different concepts. Designers
do this to search for concepts that are better than the initial ones that come to
mind. To diverge, think about concepts that are noticeably different than the PRR
ones already considered. Try combining two concepts together into a new
concept. Or try creating the inexpensive one, or the rugged one, or the
eco-friendly one. Don’t worry too much about feasibility at this point; infeasible
concepts can be useful stepping stones that can/should often lead to feasible
ones.
Converge: When designers converge, they narrow their concept set down to just one
that will be further developed. To converge, eliminate concepts that are
infeasible. Identify the few concepts that are most likely to meet the needs
Basic Design Process

identified earlier in the process. Intuition plays a large role in convergence.
Develop your intuition, and your confidence in following it. The more complex
the problem is, the more valuable the systematic convergence activities
become; they can lead to non-intuitive desirable concept or in some complex
cases may be the only way to find a feasible concept.
Model: When adding detail to the selected concept, designers will choose specific
details such as a specific material or specific geometric dimensions. Predictive
models are often invaluable when doing this. With relatively little cost, many
variations of a concept can be considered and experimented with before
defining which specific values to choose.
Experiment: With predictive models, it is easy to experiment with the design and
improve it before it is built. Simple experiments can be really useful, especially
when you have experience that improves your intuition. More complex
experimentation methods using designed experiments and/or numerical
optimization techniques can also be useful for defining some designs.
Prototype: Whenever possible, designs should be physically built and tested. The
reality is that predictive models are only approximations of the physical world.
Prototypes expose designs to real conditions, which often help designers
recognize weakness in the design. Both rough and refined prototypes have a
role in design. Designers generally choose the least expensive prototype that
will sufficiently indicate how well the design meets the needs.
Evaluate: A thoughtful analysis of the design is needed to determine if the design is
good enough or if it needs to be refined by repeating one or more of the
previous parts of the basic design process. Quantitative and qualitative
evaluations will most likely be needed to evaluate the performance of the
design, its potential for improvement, and the cost (time and money) to
improve it.
See also
Development Reference: Brainstorming (11.5); Catalog Search (11.7); Delphi
Method (11.15); Design of Experiments (11.18); Experimentation (11.26); Focus
Groups (11.31); Internet Research (11.33); Interviews (11.34); Method 635 (11.35);
Observational Studies (11.40); Prototyping (11.50); SCAMPER (11.58); Scoring
Matrix (11.59); Screening Matrix (11.60); Surveys (11.65);
170
OD
CD
11.2 Benchmarking
SSE Understand and use the best available ideas
Further Reading
Benchmarking is a process of developing a thorough understanding of competitive The American Society for
products. These products are evaluated to determine how well the market likes the Quality describes the use of
product, key strengths and weaknesses, the performance of the product on the benchmarking in developing
performance measures, the concepts used in the product, and the estimated requirements matrices: http:
manufacturing cost of the product. //asq.org/learn-about-quality/
benchmarking/overview/
tutorial-building-house-of-quality.
html
Market benchmarking
Market benchmarking is the process of obtaining ratings from the market or market
representatives about how well competitive product meets the market requirements.
Market benchmarking involves obtaining information from the market or from
market representatives. The highest quality information is directly obtained from the
market. Information about purchase decisions is the most accurate information
available, but it does not generally include reasons for the purchase decision that
was made. Market representatives can supply reasons for purchase decisions.
Interviews, focus groups, and surveys of customers of competing products can
provide important information. The techniques for eliciting customer information
Benchmarking
that are described by Ulrich and Eppinger (2012, Chapter 5) are useful in the
benchmarking process.
Magazines and trade reports can provide market benchmarking information.
A relatively new source of market benchmarking information is online reviews. Many
products have reviews that indicate likes and dislikes for products that have been
purchased. Coupled with market share data, this can provide insight into the market
approval of products.
Technical benchmarking
Technical benchmarking is the process of determining the level of performance of
competitive products in each of the performance measures defined in the
opportunity.
Technical benchmarking involves measuring the performance of competitive
products relative to the performance measures. This provides an excellent
opportunity to evaluate your testing procedures for the performance measures. Each
key competitive product should be evaluated.
Using market and technical benchmarking

The combined results of market and technical benchmarking are used to determine
ideal and marginal values for the performance measures. Because technical
benchmarking has been completed, the team understands how each benchmarked
product performs on each of the performance measures. When correlated with the
market rating data obtained from market benchmarking, the value the market places
on various levels of performance can be inferred.
When using benchmarking to help identify ideal and marginal values for
performance measures, it is important to understand that the competitive products
are generally improving over time. This means that if your development timeline is
more than a few months, you should allow for the continued increase in competitive
product performance, and you should aim for performance that is better than the
current competitors.
171
OD
CD
Design benchmarking
Design benchmarking is the process of understanding how competitive products are
designed to meet the market requirements and the performance measures. SSE
Design benchmarking involves obtaining competitive products, disassembling them,

and developing an understanding of what each feature in the product does. During
design benchmarking, it is also common to estimate the cost of each of the
components in the design.
Design benchmarking is often used to establish a minimum baseline for the design
team. If the team cannot find a design that is better than the best competitive
design, the team is required to use the competitive design. Because designers
generally dislike using other designs, this serves as a strong motivation for coming
up with an improved design.
Applicability
Every product development process should include competitive benchmarking.
Market benchmarking will be used most heavily during the opportunity development
stage.
Technical benchmarking is used during the opportunity development stage to
develop marginal and ideal values. It is also used during the concept development
stage to provide reference concepts and help establish technical and performance
Benchmarking
models.
Design benchmarking is used most heavily in the subsystem engineering stage.
See also
Development Reference: Six Sigma (11.62), Quality Function Deployment (11.51),
Value Engineering (11.69).
Competing products are thoroughly analyzed in design benchmarking.

172
CD
11.3 Bill of Materials
SSE Track and manage each component in your design
Manufactured products are made up of various specific (not vague) components.

SR
The bill of materials is a table that lists each of those components.
The bill of materials, which is often called a BOM, generally includes information
beyond the name of the part; for example, it can include the material of each part,
PR
the cost of each part, the part number, approved vendors, and more. It is organized
in such a way that it makes it clear which components comprise each subassembly.
It is a revision-controlled document that — when complete — is an extremely
PRR valuable part of a product’s design information.
How to do it
1. Create a hierarchical table listing the system, subsystems, and components
2. Give each component a BOM item number for easy reference during
discussion (typically the numbered rows of the table)
3. Give each subsystem and component a name and a description
4. List the approved manufacture for components purchased off-the-shelf
5. Give each component a part number; consider using a manufacture’s part
Bill of Materials
number for off-the-shelf components

6. Put the BOM under revision control
7. Update the BOM when new information becomes available
How to use it as a product development tool

1. Start a bill of materials as soon as your product concept has been selected
2. Include as much pertinent information as you can in the bill of materials when
it is first created. Accept the fact that not all information will be known at first.
3. As the design evolves and more information becomes available, add it to the
bill of materials and change the revision.
4. Add product development information, such as person responsible for the
design of the component, whether or not a finite element analysis (FEA) is
needed for the component, and so on.
5. Revise the BOM so that it always reflects the current state of the design.
6. Use the BOM in team meetings and design reviews to show progress and
indicate where further development is needed.
7. Work to achieve a complete BOM, one that includes every specific component
needed to manufacture the design. This will even include more obscure items
such as labels, and paint as bill of material items.
Part lists in CAD assembly drawings

Engineering assembly drawings often include a table that lists the parts in that CAD
assembly. In most cases, however, CAD models don’t include every component in
the product such as adhesive, components on a circuit board, labels, paint, wires,
solder, and more. Because of this, these parts lists are not nearly as valuable as
complete BOMs.
See also
Decomposition (11.14) and Drawings (11.23).
173
CD
Bill of Materials shown is

for this assembly SSE
SR
PR
PRR
Bill of Materials
Bill of Materials for an upper assembly prototype of the Human-Powered Well Drilling Machine.
174
CD
11.4 Bio-Inspired Design
SSE Apply solutions found in nature to your problem
Bio-inspired design (sometimes called biomimicry or nature inspired design) is a

solution exploration strategy that investigates nature’s solution to problems. The
purpose of the strategy is to identify new solution principles from nature to inspire
the development of analogous technical systems.
As an example, an innovative design for the leading edge of a wind turbine airfoil
was inspired by a humpback whale. Humpback whales have protuberances or
tubercles on the front edge of their fins. Studies show that these tubercles delay the
stall angle of the fin by about 40%, increase lift, and decrease drag (Miklosovic
et al., 2004). This allows the 40-50 foot whales to maneuver quickly to catch their
prey (small fish).
This idea was applied to wind turbine airfoils. Instead of the traditional smooth
blade, the humpback whale fin tubercles were imitated on the leading edge of the
turbine blade and wind-tunnel tests have shown that these tubercles allow the
blades to perform significantly better.
How to do it
Bio-Inspired Design
When trying to solve an existing problem:
1. Search for similar problems in nature.

2. Evaluate nature’s method for solving the problem.
3. Discover the underlying principle that makes nature’s solution possible.
4. Determine if the same or a similar principle can be embodied in a product
solution.
When trying to be inspired to create new products or technology:
1. Do an observational study, where the subject is nature.

2. Observe differences between the natural and man-made worlds.
3. Ask questions that promote thought: what makes a plant stand up? How does
a tree pump water to its highest branches? How does a bee manage to fly?
4. Discover the underlying principle that makes nature’s solution possible.
5. Determine if the same or a similar principle can be embodied in a product
solution.
See also
Observational Studies (11.40); Janine Benyus’ TED talks “Biomimicry in Action” and
“12 Sustainable Design Ideas from Nature”; Delft University of Technology’s
“Bio-Inspired Designs” OpenCourseWare with lectures and readings.
175
CD
SSE
Bio-Inspired Design
Bio-inspired design of wind turbines. (a) Protuberances or tubercles on the leading edge of
humpback whales. (b) Innovative turbine blade leading edge inspired by the humpback whale.
176
OD
CD
11.5 Brainstorming
SSE Unlock the creativity of a group to find design solutions
Further Reading
Brainstorming is a group-based solution exploration method that builds on collective Stanford d.school’s “Rules
group knowledge and synergy to generate numerous candidate solutions to for Brainstorming,” available
problems. at dschool.stanford.edu/blog/
2009/10/12/
Brainstorming is a useful tool during any stage of product development. It can be rules-for-brainstorming
used to generate ideas regarding requirements, ideas regarding solutions, ideas
regarding potential failure modes, and any other thing that would benefit from group “Brainstorm Rules,”
available at dschool.stanford.
exploration. edu/wp-content/themes/
dschool/method-cards/
brainstorm-rules.pdf
How to do it
The Mind Tools website,
A successful brainstorming session is most likely to be achieved when it has been www.mindtools.com/
prepared for. To prepare for a brainstorming session, the person leading the effort brainstm.html
should articulate the problem some amount of time (minimum 1 hour) before the
session begins. This allows (i) the participants to familiarize themselves with the
problem and the issues at hand, and (ii) it allows the person leading the effort to
think clearly about who (meaning what expertise and background) should join the
session.
Brainstorming
The person leading the effort should prepare materials that will help the team use the
session time effectively. This may mean that the leader has supplied paper, pens,
and other props. It may mean that the leader has arranged inspirational solutions to
be brought to the session. For example, the leader may bring industry leading
competitive products, or other technological solutions that might inspire the session.
The leader should lead the session, meaning he or she should make sure there is a
clear goal and that it is being met as much as possible. The leader should try to
complete the session in less than one hour.
General brainstorming guidelines

Osborn’s rules for brainstorming (Osborn, 1963):
1. Focus on quantity: The quality of ideas is not as important as generating as

many ideas as possible for discussion. Having a larger group of ideas to talk
about and choose from will lead to a higher occurrence of good ideas, which
leads to a better final product.
2. Withhold criticism: Remember that concept generation and concept selection
are two separate activities. Resist the impulse to criticize the infeasibility of
suggested design candidates during the brainstorming session. Following this
rule creates a comfortable atmosphere so team members share more ideas.
3. Welcome unusual ideas: Sharing wild ideas can help the group think in a new
direction and generate ideas they otherwise could not. This will ensure that a
broad range of solutions are explored. Even if the initial solution is not a good
idea, it may lead to something that is.
4. Combine and improve ideas: Building on the ideas of others and combining
different ideas allow the team to explore a larger design space so they can
converge on a better solution.
See also
Development Reference: Bio-Inspired Design (11.4), Method 635 (11.35).
177
OD
CD
SSE
Brainstorming
Brainstorming.
178
11.6 CAD Modeling

SSE Create virtual 3-D representations of your product
Further Reading
CAD modeling is used to create geometric representations of the product. Veisz D, Namouz EZ, Joshi S,
SR
Engineering drawings are typically created from CAD models, but CAD models can Summers JD, CAD vs.
be effectively used far beyond the creation of engineering drawings. Effective use of Sketching: An Exploratory
CAD modeling can facilitate a wide range of activities and results in product and Case Study,
PR process development. http://www.clemson.edu/ces/
cedar/images/5/59/
2013-veisz-sketching.pdf
Key methods
PRR
3-D CAD solid modeling is generally recognized as preferable to 2-D drawing.
For high-quality surfaces, surface modeling is generally integrated with solid
modeling systems.
Systems that support parametric modeling are preferred to those that do not.
Models should be defined in parametric form for at least two reasons. First, defining
models parametrically identifies important design parameters. Second, models that
have been defined parametrically are more robust and easier to change.
Systems that support parametric assembly of parts are preferred. In such systems,
CAD Modeling
design based on a skeleton assembly can identify important assembly parameters

and facilitate assigning modeling work to different team members.
CAD modeling can drive the design forward by forcing the designer to pick values for
unknown parameters. This can be both good and bad. It is good, because it moves
the design forward. It can be bad, because values can be chosen without
appropriate consideration. As CAD models progress, be sure to identify Vital and
Mundane parameters and ensure that Vital parameters are appropriately handled.
Engineering drawings that are automatically created from CAD systems are unlikely
to be complete and high quality. Be sure to allow time for creating excellent
drawings from the CAD models.
Drawings should always be checked by someone other than the creator of the
drawing. When checking drawings, do not give the creator of the drawing the benefit
of the doubt. Assume that there are mistakes, and work hard to find them.
Applicability
CAD modeling is generally used in the subsystem engineering and system
refinement stages of development. However, CAD models can be very helpful in
concept development, particularly as the concepts get more refined.
Most studies that have been made indicate that too heavy a reliance on CAD
modeling early in the concept development stage can have a negative effect on the
quantity and variety of concepts developed.
See also
Development Reference: Finite Element Modeling (11.30).
179
SSE
SR
PR
PRR
CAD Modeling
Renderings from CAD models can be used to (a,b) visualize things that would be difficult with physical prototypes,
(c) show photo-realistic esthetics, (d-e) show motion, and (f) show relationship between parts in a product.
180
CD
11.7 Catalog Search
SSE Take advantage of existing components
Catalogs and manufacturers’ technical information are sources of existing

information that can be invaluable to a product development project. Catalogs are
available both online and in paper copies. Paper catalogs are often easier to browse
through than electronic catalogs, while electronic catalogs are often easier to search
for specific items.
Manufacturer catalogs
Catalogs from specific manufacturers, such as Timken for bearings or Suspa for gas
springs, generally contain the most specific information and are very helpful for
details when a concept has been chosen.
It is very common that catalogs or design guides that are available from
manufacturers will provide specific information about how to design your product to
make effective use of the manufacturer’s product. For example, the Timken
Engineering Manual1 provides a bearing selection procedure, installation methods,
shaft and housing fit guidelines, and several pages for determining the loads on the
bearings. This information is an invaluable resource that enables you to properly
select bearings for your application and properly design your product to take
Catalog Search
advantage of the bearings.

Design guides from manufacturers help ensure high-quality designs using their
components.
Distributor catalogs
Catalogs from distributors, such as MSC or McMaster Carr, contain a wide range of
products and may be useful for browsing just to see what is available. Distributor
catalogs tend to have much less technical information than manufacturers catalogs.
However, they have a much broader range of available components.
When using distributor catalogs, it can be tempting to exclusively use a favorite
distributor. When you know exactly what you want, and the distributor has it, using
the favorite distributor is wise. However, if you are looking for ideas, it is generally
best to look at multiple distributor catalogs, because each will have a different range
of available components.
Catalogs for consumer, rather than industrial, products are often very helpful in
finding ideas that can be used as the basis for a design solution, even though the
product itself is unlikely to be used.
See also
Development Reference: Observational Studies (11.40).
1
Available at http://www.timken.com/
en-US/products/Pages/Catalogs.
aspx
181
CD
SSE
The Timken Engineering

Manual is a design guide
for the selection and ap-
plication of various rolling
element bearings.
Catalog Search
The MSC catalog
contains thousands of
components that can
be useful in product
development.
182
OD
11.8 Codes and Standards

SSE Apply the combined experience of the profession
Many products will be governed by relevant codes and standards. In such cases,
the standards describe performance measures that must be met in order to sell the
product. The standards also often prescribe test methods for measuring the
required performance. Using codes and standards helps ensure your product will
be successful, and allows you to build on the expertise of the standard writers,
rather than having to create all of that knowledge yourself.
Codes
Codes are generally regulatory in nature. Codes describe characteristics a product
must have if it is permitted to be sold. Code compliance serves as a constraint for a
product. If a product does not meet the relevant codes, it doesn’t matter how well it
performs in other areas. It will be unacceptable.
Codes can be developed by professional societies, by trade organizations, or by
government bodies. Regardless of how they are created, codes become applicable
when they are accepted as mandatory by a government or other regulatory body.
Codes and Standards
Standards
Standards are developed by governments or trade associations to ensure
compatibility and interoperability of parts between different manufacturers. When
parts meet standards, they will work with other parts that meet the same standards.
Unlike codes, in many cases standard compliance is voluntary. A team can develop
a product that uses non-standard threads, for example. However, the market will
generally require that products comply with most existing commercial standards.
Thus, understanding and complying with standards is generally good design
practice.
Obtaining codes and standards

Codes and standards are generally available for purchase from the body that creates
the code or standard. These fees provide the resources necessary to update and
maintain the standards.
Determining which standards apply

Companies who have experience in developing specific products generally have a
good understanding of the relevant codes and standards. For designers who are
new to the development of a specific kind of product, codes and standards can
often be identified by reviewing technical literature of related products and by the
Delphi method.
See also
Development Reference: Delphi Method (11.15).
183
OD
SSE
The ASME Boiler and Pressure Vessel Code is a standard developed by ASME that Codes and Standards
has been adopted as a code in multiple nations.
184
CD
11.9 Concept Classification Tree
SSE Organize your ideas to better cover the design space
A concept classification tree graphically presents the different branches explored

when generating alternative solutions or concepts. In addition to providing a
measure of variety, the classification tree may provide additional ideas by
highlighting branches that are not sufficiently explored.
How to do it
The concept classification tree is constructed after generating a variety of concepts.
The first step is to group similar generated concepts together. The second step is to
simply capture the structure of the set of generated concepts in branching tree
format as shown in the figure.
This can be done for all decomposed parts of the problem together, or for just one
branch of the decomposition, as shown.
Benefits
Concept Classification Tree
Ulrich and Eppinger (2012) suggest four benefits of concept classification trees:
1. Pruning of less-promising branches.

2. Identifying different approaches to solving the problem (each branch is an
independent approach).
3. Exposing insufficiently explored branches.
4. Refining the decomposition of particular branches.
See also
Development Reference: Decomposition (11.14), Recombination Table (11.53).
185
CD
SSE
Obtain Energy
For Drilling
Harness Solar
Human Power Power
Concept Classification Tree

Body Stays Body
Pendulum
In Place Moves
Stationary Rowing Railroad Pull on Hand Walk in

Falling Jumping Climbing
Pedaling Machine Pump Rope Crank Circle
A concept classification tree used by the human-powered drill team (see Appendix B) to explore the “harness
energy” subfunction. Note that although the team had as their primary focus the creation of a human-powered
drill, during concept generation they expanded their thinking to consider solar power as a potential energy source.
Perhaps their solution set would have been even better had they considered wind and rain as potential energy
sources as well. By placing the concepts in a tree that shows logical relationships, we can see areas that could
profitably be explored more fully.
186
CD
11.10 Controlled Convergence
SSE Develop a concept that is demonstrably superior
Further Reading
Controlled Convergence is a formal method for creating a strong concept, using Controlled Convergence is
matrix methods to drive a significant understanding of market requirements and the thoroughly explained in
development of concepts that are demonstrably superior at meeting those Pugh, S (1991) Total Design:
requirements. integrated methods for
successful product
engineering. Addison
How to do it Wesley, Reading
Massachusetts.
Create a convergence matrix with market requirements listed on the left, and
Frey D, Herderi P, Wijnia Y,
potential solution concepts listed on the top, with a reference or datum concept on
Subrahmanian E,
the left-hand side. Katsikopoulos K, Clausing D
Next, rate the performance of each concept relative to the market requirements, (2009) The Pugh Controlled
Convergence method:
working one requirement at a time (row by row). Concepts are given a “+” if they are model-based evaluation and
better than the datum for that requirement, a “-” if they are worse than the datum, implications for design
and an “S” if they are the same as the datum or the team cannot agree on a rating. theory. Res Eng Des
20(March):41-58. Available
During the rating stage, each team member seeks to understand the reasons for the online at http://hdl.handle.
Controlled Convergence
ratings. This is not a time for members to agree with one another to avoid conflict. It net/1721.1/49448. This
is a time to think critically about each of the concepts and requirements, and paper uses simulation to
develop rationally based ratings. The understanding that comes from thorough demonstrate that controlled
convergence achieves
evaluation is even more important than the actual rating. consistent outcomes.
When the ratings are complete, try to eliminate dominated concepts and combine
complementary concepts. Concept B is said to dominate concept C if concept B is
better than concept C in at least one rating, and has no ratings worse than concept
B. Thus, there is nothing about concept C that is better than concept B. Dominated
concepts can be removed from the matrix.
New concepts are created based on combinations of complementary concepts.
Concepts D and E are complementary if concept E is strong in areas where concept
D is weak and concept D is strong in areas where concept E is weak. Find ways to
combine complementary concepts to maximize the strengths and minimize the
weaknesses. Combined concepts are added to the matrix and rated relative to the
datum. Dominated concepts are removed again. This completes Phase I.
Phase II has the same activities as Phase I, but with two important differences. First,
the datum for Phase II is chosen from among the strongest concepts identified in
Phase I. Second, the concepts in Phase II are described at a higher level of detail,
which permits finer resolution in the evaluations.
If no clear dominant concept has emerged after the completion of Phase II, a third
phase is undertaken. Again, the datum is changed, and more detail is added to the
remaining concepts. By the end of Phase III, a dominant concept will almost
certainly be identified.
Applicability
Controlled convergence method should be used when a concept needs to be
developed for one of the Vital Few decisions. It should not be used for mundane
decisions, because it takes too much time.
See also
Development Reference: Scoring Matrix (11.59), Screening Matrix (11.60).
187
Rota-
Sludge People CD
Tugging Stationay Rowing Railroad Climbing Hand Solar
(Bench- Walking Pendulum
with Rope Pedaling Machine Pump or Falling Crank Power
mark in in Circle
Market Requirements (Whats) Tanzania)
The energy harnessing device provides enough

S + + + + + + + + S SSE
torque to the drill bit.
The energy harnessing device drills the

S + + + + + + S + +
boreholes quickly.
The energy harnessing device requires few

S – – – – + – + + +
people to operate.
The energy harnessing device is a simple device.

S + + – – – – – – –
The energy harnessing device is simple

S + + + + + + + + +
to operate.
The energy harnessing device is manufacturable

in Tanzania.
S + + – – – – – – –
The energy harnessing device allows a person to

be stationary during operation.
S – – + + S – S S +
The energy harnessing device minimizees the

S – – – – – – + – +
strass on the body.
The energy harnessing device is small.

S + + S S S – – S S
Sum + 0 6 6 4 4 4 3 4 4 5
Controlled Convergence
Sum – 0 3 3 4 4 3 6 3 3 2
Sum S 9 0 0 1 1 2 0 2 2 2
Total Entries 9 9 9 9 9 9 9 9 9 9
Combine Keep Combine

Disposition Keep Keep Discard Discard Discard Discard
Research
A first-phase Controlled Convergence Matrix. Market requirements are listed on the left. Potential
solutions are listed on the top, with the datum concept listed at the left side. Each concept is rated
the same, better, or worse than the datum concept. Although the number of ratings in each category
is totaled for each concept, no overall score is assigned to a concept.
Convergence of concepts in controlled convergence. Three rating stages

are demonstrated. In each stage, concepts that are dominated are elim-
inated. Between stages, new concepts are developed. After Frey et al.
188
CD
11.11 Cost Estimation
SSE Estimate the cost of mass producing your design
Further Reading
One factor that is often essential to product development is the cost associated with Ulrich KT, Eppinger, SD
mass producing a design. In order to judge the profitability of an evolving design, it (2012) Product Design and
is helpful to estimate its cost during various stages of its development. To estimate Development, 5th ed.
the bill of material cost and other costs of a design, try one of the following. McGraw-Hill, New York. pp.
256-267.
van Boeijen A, Dallhuizen J,

How to estimate costs using prior knowledge about a similar Zijlstra J, van der Schoor R
product’s costs (2014) Delft Design Guide
BIS Publishers. pp.
1. Make a deliberate choice about the level of accuracy (fidelity) needed for the 152-153.
cost estimate. Do the following steps consistently according to the chosen level For international and national
of accuracy for all evaluations. labor rates visit the Bureau of
2. Select a sufficiently similar product or products for which you have cost data. Labor Statistics at
http://www.bls.gov/
This is easily done when developing a next generation product, where you can
start with the previous generation’s costs. Adjust the data according to inflation For raw materials, search the
or other market dynamics to best reflect current costs. internet for commodity
material costs. For example,
3. Make intelligent estimates for as many of the costs shown in the opposing search “cost of 6061
figure needed to match the chosen level of accuracy. Use the existing data as aluminum per kg”, then use
Cost Estimation
reference. For example, if the similar product uses 4 inches of 22 gage typical/average costs.
stranded core wire for $0.07, and the candidate concept requires 2 inches of
the same wire, estimate $0.035 for the wire cost. Do this for each known part
or subassembly of the concept.
4. Sum all of the costs to get a total cost estimate.
5. Consider multiplying the sum cost by a safety factor (e.g., 1.2, 1.5) to capture
costs you choose not to model.
6. Update the cost estimates as new information becomes available.
How to estimate costs without prior knowledge about costs

1. Make a deliberate choice about the level of accuracy needed for the cost
estimate. Higher fidelity is not always worth the time required. Do the following
steps consistently according to the chosen level of accuracy for all evaluations
2. Collect pertinent general data for as many of the costs shown in the opposing
figure needed to match the chosen level of accuracy. The general data
collected would be cost per mass for raw materials, labor rates, and machine
rates, for example.
3. Make intelligent estimates of cost by making the general data of the previous
step specific to the candidate concept. For example, an estimate can be made
for the raw material cost of a machined 6061 aluminum cylinder by multiplying
the preprocessed mass of the cylinder by the cost per mass of 6061
aluminum. Likewise an estimate of the processing cost can be made by
multiplying the processing time by the labor rate and machine rate. Do this for
each part that will be processed from raw materials.
4. Estimate or acquire price quotes for purchased parts and subassemblies. Do
this for appropriate quantities to reflect mass production quantities planned for.
5. Sum all of the costs to get a total cost estimate.
6. Consider multiplying the sum cost by a safety factor (e.g., 1.2, 1.5) to capture
costs you choose not to model.
7. Update the cost estimates as new information becomes available.
189
CD
How to use cost estimates
During the product development process, the current cost of producing the design
(by a production system) should be periodically estimated and compared to the cost SSE
targets described in Cost Targets (11.12) of the Development Reference. To be most
useful the same level of accuracy should be used for both the cost targets and the
cost estimates.
See also
Development Reference: Bill of Materials (11.3), Benchmarking (11.2), Cost
Targets (11.12), and Financial Analysis (11.29).
Product Cost D = cost distributed over

multiple produced units
Part Cost Assembly Cost Packaging Cost Shipping Cost Overhead Cost
Cost Estimation
D
Packaging Transport Administrative
Raw Material Assembly
Material Cost Costs
Part Packaging Labor &

Labor Dock Fees
Processing Processing
Machine Labor Export Tax Utilities

Labor
Usage
Machine Machine Real estate

Fixture/Tooling Import Tax
Usage Usage
D
Development
Tooling Fixture/Tooling Costs
D Product D
Maintenance Labor &
Prototyping
Cost Early in Product
Development
Lab Fees/
Direct Costs Indirect

Costs
List of costs to be considered when estimating the cost of a product concept. Note that labor
and machine usage are calculated by multiplying processing time by labor rate and machine
rate, respectively. Product maintenance refers to the ongoing maintenance required to keep
the product working desirably.
190
OD
CD
11.12 Cost Targets
Establish target bill of material cost based on product
selling price Further Reading
van Boeijen A, Dallhuizen J,
Product cost, selling price, and other financial characteristics of a design often drive Zijlstra J, van der Schoor R
(2014) Delft Design Guide
decisions during the product development process. To that end it is valuable to BIS Publishers. pp.
establish a target bill of material (BOM) cost early in the development process. 152-153.
Having a target cost helps the team better understand how their design decisions
affect the profitability of the product. Pahl G, Beitz W (2007)
Engineering Design, 3rd ed.
Springer-Verlag, London. pp.
Basic concepts 560-561.
When the consumer purchases the product in a store, the price they pay covers a lot For price theory, see Varian
H (1992) Microeconomic
more than just the cost of the parts. It also covers overhead and profits for each Analysis, 3rd ed. WW Norton
entity in the supply chain. For example, assume there are four entities at play: the & Company, New York.
manufacturer, the developer, the retailer, and the consumer. Assume you’re the
developer and have an interest in being financially profitable. To do so you’ll need to
consider the following:
BOM cost: This is the amount of money required to make the product including the
sum cost of all the parts. Some companies also include labor/assembly costs in
Cost Targets
this amount (as a BOM line item).

Manufacturer’s selling price: Assuming you will purchase the assembled product
from a manufacturer, you’ll need to pay the manufacturer more than the BOM
cost. The added amount paid is known as the manufacturer’s margin. The
BOM cost plus the manufacturer’s margin is the manufacturer’s selling price to
you.
Your selling price to retailer: Assuming you will distribute your product through a
retailer, you will need to sell your product to the retailer for more than the
manufacturer’s price. The added amount charged to the retailer is known as
your margin. The manufacturer’s price plus your margin is the selling price to
the retailer.
Selling price to consumer (end user): The selling price of a product is the amount of
money the consumer pays to acquire the product from the retailer. The
difference between the selling price to the customer and the selling price to the
retailer is the retailer’s margin.
Overhead: All of the entities at play have a certain amount of operating costs that
are indirectly related to the product. For example, the developer will need to
have an office with lights, computers, restrooms, and a staff of people to run
the business. These costs can generally be grouped into one category called
overhead. Each company’s overhead is different. Nevertheless product
development teams can use rough estimates to get a feel for the financial
viability of a product by estimating overhead to be 50%. For example, if a
manufacturer’s selling price to you is $20, your overhead for that unit will be
$10, or the overhead rate times the manufacturer’s selling price.
Revenue: The revenue is income from the sale of goods. For example, if your selling
price to a retailer is $40 and 10,000 units are sold, your revenue is $400,000.
Profit: The profit is the revenue (income) minus all of the costs (expenses).
Generally the costs include the cost of goods sold (COGS), which is the
manufacturer’s price if you are the developer, plus overhead. For example, if
you paid $20 per unit to the manufacturer and sold that same unit for $40 to a
retailer, and your overhead was 50%, you would make $10 profit for every unit
sold. If you sold 10,000 units, your profit would be $100,000.
191
OD
CD
How to estimate a target BOM cost based on product selling price
• Determine a required (or estimated) selling price for the product you’re
designing. Price theory – not discussed here – is a complex topic ultimately
used to determine selling prices. In the early stages of product development,
however, price estimates can and should be made to guide the team. This is
often done by a simple market assessment of similar products or of products
having similar parts and complexity (see Benchmarking (11.2)).
• Divide the required (or estimated) selling price by approximately 8 to calculate
a target BOM cost.
As a rule of thumb, 8 times the BOM cost is roughly what consumers pay when
buying a product at a store. This is illustrated in the image provided here, and
typically applies to small consumer goods. For larger purchases such as a car, the
ratio is typically lower. When different ratios are known, the known ratios should be
used.
How to estimate selling price starting with BOM cost

• Assemble a bill of materials (BOM), and calculate total BOM cost.
• Double the BOM cost to get an estimate of the manufacturer’s selling price to
you.
Cost Targets
• Double the manufacturer’s selling price to you to estimate your selling price to
a retailer.
• Double your price to a retailer to estimate what the consumer will pay when
buying the product off the shelves of a store.
If you’ve received a quote from a manufacturer for an assembled product, recognize

that this quote has the BOM cost plus the manufacturing/assembly costs plus the
manufacturing margin in it. In such cases an estimated selling price to a consumer
is made by multiplying the manufacturer’s quote by approximately 4.
See also
Development Reference: Bill of Materials (11.3), Benchmarking (11.2), Cost
Estimation (11.11), and Financial Analysis (11.29).
$ Product Price at Retail Store
Your Selling Price to Retailer
Your Overhead
Manufacturer’s Selling Price
Bill of Material (BOM) Cost
$0
An illustration of the bill of material costs (dark gray) versus the product price at a retail store.
This is a safe estimation for consumer products.
192
OD
CD
11.13 Critical Path Analysis
Identify the most critical parts of your project plan
Further Reading
In any design activity map, there is a critical path that limits the minimum time Ulrich KT, Eppinger SD
required to complete the map. An important characteristic of the critical path is that (2012) Product design and
if any activity on it is delayed, it delays the completion of the entire map. Activities development, 5th ed.
not on the critical path have a window within which they can be completed; any McGraw Hill, New York. pp.
delay within that window does not delay the completion of the entire map. To that 384-385.
end, understanding, tracking, and managing the critical path are essential to
completing the map on time.
Critical path analysis is often used when establishing a project schedule. As shown
below, it can be used to establish (i) the necessary start times for each critical path
activity, and (ii) the earliest and latest possible start times for non-critical path
activities.
Multiple commercially available software packages can be used to identify the
critical path. The backbone of these packages is simple to understand; for many
small-scale projects critical path analysis can be carried out manually as fast as it
might take to learn a new software package.
Critical Path Analysis
How to do it
1. Create an activity map (see Section 2.3).
2. Establish a duration for each activity in the activity map.
3. Using activity map logic1 determine the earliest possible start time for each
activity (do this by following the map in a forward direction).
4. Using activity map logic, determine the latest possible start time for each
activity (do this by following the map in a backward direction).
5. Subtract the earliest possible start time from the latest possible start time to
determine the size of the starting window (this window is often called the float
time, in other literature).
6. Identify the critical path as the set of activities with starting windows of zero
duration.
Simple example
Consider the activity map shown in the figure. Notice that steps 1 and 2 above are
complete, meaning that each design activity (alpha designated arrows) in the
network has a duration associated with it (number appearing next to it, e.g., T = 3
wks).
To determine the earliest possible start time we begin with the first activity (A).
Clearly the earliest possible time to start activity A is beginning the network or time =
0. We then go on to the next activity (B), where based on the activity map logic that
activity A must precede activity B, it can be seen that the earliest possible start time
for activity B is time = 3. This process is continued for each activity.
Notice that because of the interdependency between Outcomes 3 and 4, the earliest
possible time to start activity G is time = 20. This is because G cannot begin until
activity F and activity C and D are complete. Of those three activities, activity C has
the longest duration at 15 weeks; adding those 15 weeks to the three weeks of
activity A and two weeks of activity B tells us the earliest possible start time for
activity G.
1
See Figures 2.7 and 2.8
193
OD
CD
To determine the latest possible start time, we begin with the fact that the network is
expected to be completed in 32 weeks. We then start at the end of the network and
work backwards; activity I has a duration of 4 weeks and must be completed by the
end of week 32. Therefore the latest possible time to start activity I is week 32 minus
4 weeks, or at week 28. Further, the network shows that activity H must precede
activity I, and that activity H has a duration of 8 weeks. Therefore the latest possible
time to start activity H is the latest possible time to start activity I minus the duration
of activity H, or at week 20.
A table showing the earliest possible start times and the latest possible start times is
a convenient way to manage the data. With these times in hand, the starting window
size can be calculated as shown.
The activities with a starting window size of zero are on the critical path.
See also
Development Reference: Concept Classification Tree (11.9), Recombination
Table (11.53). E
T: 4 Wks
Critical Path Analysis

C I
T: 15 Wks T: 4 Wks
1 B
H
A T: 2 Wks 2 3 5
T: 8 Wks G
Time: 3 Wks
T: 11 Wks
T: 10 Wks
D
F
T: 3 Wks
Earliest Start Latest Start Starting Window

Activity Time (ES) Time (LS) Size = (LS-ES)
A 0 0 0
B 3 3 0
C 5 5 0
D 5 10 5
E 5 28 23
F 5 18 13
G 20 21 1
H 20 20 0
I 28 28 0
Activity map for critical path analysis. The critical path consists of activities A, B, C, H, and I.
194
CD
11.14 Decomposition
Solve difficult problems one piece at a time
Further Reading
Decomposition – or the act of breaking something down into simpler constituents – Ulrich KT, Eppinger SD
is a universal design tool, used in nearly every design project. We can use (2012) Product design and
decomposition to break down a complex project, a complex product, and complex development, 5th ed.
functions. Such breakdowns make it possible for the product development team to McGraw Hill, New York. pp.
attack smaller more manageable design sub-problems. 121-123.
The need for decomposition varies but includes the fact that different expertise may Herrmann JW (2004)
Decomposition in product
be required to develop each subsystem, or that the project schedule is tight and development, TSR 2004-6.
requires parallel development in order to complete the project on time. Institue for Systems
Research, University of
Maryland.
How to do it
Structural decomposition
The easiest strategy to understand is Structural Decomposition. Structural
decomposition is the act of breaking down a product into its structural or physical
parts. For example, consider a bicycle. It can be structurally broken down into (i) a
welded frame, (ii) wheels, (iii) seat, (iv) handlebars, (v) fork, and (vi) drive train.
Structural decomposition is a valuable activity when a basic structure/concept
Decomposition
already exists. If developing a new bicycle for a traditional bicycle market, structural
decomposition is a good place to start because the traditional market will expect
wheels, seats, handlebars, and so on in a new bicycle. With such a decomposition it
is easier for the development team to decide which parts it will purchase
off-the-shelf (drive train, for example) and which part it will develop a new design for
(welded frame, for example).
Structural decomposition also facilitates project management, as part numbering,
document control, development assignments, and so on are often made according
to the basic physical parts of the product.
Functional decomposition
A more abstract (less tied to a specific structure or concept) decomposition strategy
is functional decomposition. Functional decomposition is the act of dividing the
top-level function into simpler subfunctions.
Again considering the bicycle, the top-level function is human transportation. To
achieve such function, subfunctions include: (i) structural (hold everything
together), (ii) contact ground, (iii) support rider, (iv) rider control, (v) power vehicle,
and (vi) esthetics.
Functional decomposition is a valuable activity when there is no established concept
or preconceived structure. It’s a powerful way to abstract to the essence the problem
being solved. When this decomposition is made explicit, it can greatly facilitate the
development process as it provides significant design freedom because it is not tied
to a specific structure. Notice, for example, that any human-controlled ground
vehicle could result from a development project based on this functional
decomposition – not merely a bicycle.
See also
Development Reference: Concept Classification Tree (11.9), Recombination
Table (11.53).
195
CD
Structural Decomposition Functional Decomposition
Decomposition
Welded Frame Structure
Wheels (hub, spokes, rim, tube, tire) Contact Ground
Seat Support Rider
Handle Bars Rider Control
Drive Train Power Vehicle
Fork Aesthetics
Structural and functional decomposition for bicycle.
196
OD
CD
11.15 Delphi Method
SSE Obtain the help of experts on your product development
challenges Further Reading
Hsu, CC, Sandford BA
The Delphi method or Delphi technique is a method for obtaining information (2007), The Delphi
Technique: Making Sense Of
relevant to the design from experts in related fields. Consensus, Practical
There is an informal Delphi method and a formal Delphi method. Assessment, Research &
Evaluation 12(10). Available
online at http://pareonline.
Informal Delphi method net/pdf/v12n10.pdf.
The informal Delphi method is based on interpersonal networking. The person

looking for existing information finds a few people who might have ideas about
where such information might be found. Each of these people is contacted, and
asked to provide guidance about finding the desired information. At the end of the
interview, the person is also asked for the contact information of other people who
might be able to contribute to the search.
The informal Delphi method is helpful because you are drawing on the expertise of
others without making large demands on their time. Using only a few minutes from
any one person, the team is able to get access to a broad collection of expertise. The
results from the informal Delphi technique are often used as a starting point for
Delphi Method
internet or catalog searches.
Formal Delphi method

The formal Delphi method uses a panel of 15 to 50 experts, with from 3 to 5 rounds
of responses. The initial round consists of an open-ended question asking the
experts to express their judgment about where information might be found or what
might be a good concept for achieving a desired design outcome. The responses
are then summarized, and the summary sent to the experts for a second round,
where the experts are asked to rate and/or rank the responses. In the third round,
the rated responses are returned to the experts, who are then asked to explain any
disagreements they may have with the composite rating. The process potentially
continues for a fourth and fifth round.
Hopefully, as the rounds continue, a consensus develops among the experts, thus
providing stronger evidence of the goodness of the ratings.
An advantage to the formal Delphi method is that significant expert input is obtained
with a relatively small amount of effort from any one expert. A disadvantage to the
formal Delphi method is that several days or weeks may elapse between rounds, so
that it takes a relatively long time to complete.
See also
Development Reference: Brainstorming (11.5), Observational Studies (11.40).
197
OD
CD
SSE
Delphi Method
The Delphi method uses experts to obtain information helpful to the development of the product.
198
11.16 Design for Assembly

SSE Make your product easier, less expensive, and better to
assemble Further Reading
Boothroyd G, (1994) Product
Design for assembly is the process of considering and improving the design so that it design for manufacture and
assembly. Comp Aided Des
can be used to assemble the finished product more efficiently while still meeting the 26(7):505-520.
non-assembly related design requirements. Generally, the earlier design for
PR Boothroyd G, Dewhurst P,
assembly influences the design, the smoother and more compliant to the
development budget and milestones, the production ramp-up1 will be. Knight WA (2010) Design for
Manufacture and Assembly
3rd. ed. CRC Press
PRR
Principles of design for assembly
The following principles2 guide the design for assembly activities:
• Minimize the total number of parts: Essential parts are those that (i) have
motion relative to other essential parts, (ii) are necessarily made from a
different material than its surroundings, and (iii) would not be possible to
assemble unless it’s separate. All other parts are candidates for elimination.
• Minimize assembly surfaces: These surfaces are costly to prepare. For
Design for Assembly
example, it is expensive to machine parts on a cast engine block to prepare the

locations where it mates with other engine components. The design should be
improved to minimize assembly surfaces or their need for preparation.
• Avoid separate fasteners: Using integral fasteners (such as snap fits and heat
stakes) reduces the total number of parts. If separate fasteners must be used,
use a minimal number of unique fastener types.
• Minimize assembly directions: The product should be developed so that it can
be assembled completely from one assembly direction. For example, a main
component (case) can be placed on the assembly table and all parts
assembled to it from a downward direction perpendicular to the table.
• Maximize lead-in assembly: The generous use of tapers, chamfers, radii allows
parts that are not perfectly aligned to assemble together.
• Minimize handling in assembly: The basic handling operations during
assembly are: picking up, orienting, and joining parts. The design should be
refined so that the number of times and length of time required for these
operations are minimized.
It’s worth noting that to facilitate assembly, some design features will be added that
are not needed for the product function. Because the products we design will not
last forever, we must also consider these principles as they relate to disassembly.
See also
Development Reference: Design for Manufacturing (11.17).
1
This concept is discussed in Sec-
tion 7.2.
2
Derived from (Boothroyd et al.,
2010) and (Dieter, 2000)
199
SSE
1 Screw Type
2 Screw Types
Lead-In PR
On Screws
PRR
Chamfer
For
Asymmetry Lead-In
Alignment
Design for Assembly

Feature
Original Improved for Assembly
Example of improvements that result from the design for assembly guidelines.
200
11.17 Design for Manufacturing

SSE Make a product better and less expensive at the same time
Further Reading
Design for manufacturing is the process of considering and improving the design so Boothroyd G, (1994) Product
that it can be manufactured efficiently while still meeting the non-manufacturing design for manufacture and
related design requirements. assembly. Comp Aided Des
26(7):505-520.
Seasoned designers start thinking about the manufacturing process very early in the
PR Boothroyd G, Dewhurst P,
development process, often in the concept development stage, and sometimes in
the opportunity development stage. Generally, the product is more likely to be Knight WA (2010) Design for
Manufacture and Assembly
developed within budget and according to schedule when design for manufacturing 3rd. ed. CRC Press
PRR activities is carried out early in the development process.
Principles for design for manufacturing

The following principles1 guide the design for manufacturing activities:
General guidelines
Design for Manufacturing
• Become familiar with and plan for specific manufacturing processes: There are
specific guidelines for specific manufacturing processes, such as injection
molding, machining, or casting. The development team should choose an
appropriate process and become familiar with the associated guidelines. A
good place to start is (Boothroyd et al., 2010).
• Minimize total number of parts.
• Standardize components: Do this within the product itself and across product
lines. Product family design (Jiao et al., 2007) is highly related to this guideline.
• Avoid secondary operations: Deburring, heat-treating, polishing, plating, and
other secondary operations should be eliminated if not necessary.
• Avoid tolerances that are too tight: Tolerances set tighter than needed inflate
the manufacturing cost. Tolerance analysis techniques (Chase and Parkinson,
1991) are designed to help designers specify tolerances with care.
Specific rules
• Specify component sources: The team should specify each component to be

(i) off-the-shelf and from whom it should be purchased, or (ii) built in-house
and from which revision of the design it should be built. Sufficient information
should be provided to remove all ambiguity.
• Specify manufacturing process: The team should avoid ambiguous
specification of process, such as “polished surface.” Instead it should
unambiguously specify a surface and say “This surface to be polished to
0.4 µm using an electrolytic grinding process.”
• Establish appropriate dimensions: The team should dimension the part
according to a minimal number of datums to avoid tolerance stack-up, and
should dimension to physical locations on the part and not to points in space.
• Develop parts for minimal reorientation: Ideally the part would not have to be
reoriented, or refixtured during the manufacturing process.
• Define suitable fits: The team should specify proper clearances to result in the
desired fit. This should not be left to interpretation by the manufacturing entity.
See also
1
Development Reference: Design for Assembly (11.16). Derived from (Boothroyd et al.,
2010), (Pahl et al., 2007), and
(Dieter, 2000)
201
SSE
PR
PRR
Design for Manufacturing

Effects of DFM on design of a smartphone holder. (a) The design before serious
DFM activities. (b) Design after DFM activities. The part was specifically designed to
be machined. Consider the changes made to the slide arm. The original design is
one piece, yet very difficult to machine. It was simplified by dividing it up into more
machinable parts.
202
11.18 Design of Experiments

SSE Get better information from your experiments by careful
planning Further Reading
SR An excellent online resource
Design of Experiments is used to develop statistical models that approximate the for DOE techniques has been
developed by the National
performance of a product based on the results of experiments or analysis. Institute for Science and
PR Technology, and is available
at http://www.itl.nist.gov/
How to do it div898/handbook/pmd/
section3/pmd31.htm
1. Define the purpose: Clearly identify the models you hope to obtain.
PRR
2. Design the experiment: Choose responses, factors, experiment type, and factor
levels.
a) Choose responses: The responses are the system behaviors that we hope
to model by completing and analyzing the experiment. We can have one
or more responses for each experiment. Formally specifying the
responses before beginning the experiment focuses our thinking.
b) Choose factors: The factors are the variables that will be the inputs to the
Design of Experiments
model we wish to develop. The more factors we choose, the more

experiments we will need to run. But if we ignore a critical factor that
affects the response, the model will have significant errors.
c) Choose the experiment type: There are at least three types of
experiments that are commonly run: screening experiments, two-level
factorial experiments, and multi-level factorial experiments. As we move
from screening experiments to multi-level experiments, the cost and the
information gained increase significantly.
d) Choose the levels: At its core, experimental design consists of running
experiments with factor levels chosen to maximize the availability of
statistical information. The choice of levels for each of the factors
determines the space over which the resulting model applies.
3. Run the experiment: The experiment should be run according to the plan. This
will usually involve randomized run order and a significant number of
experimental runs. Running the experiment as planned keeps the statistical
information valid.
4. Analyze the results: Statistical analysis of the results produces the model that
should achieve the purpose for the experiment. If the model is insufficient for
its intended purpose, an improved experimental design is often created with
fewer factors but more levels, and the process is repeated.
Applicability
DOE is often applied during the subsystem engineering stage to determine the best
values for design parameters. It can also be used during any verification stage to
determine the performance of the system or subsystem over a range of conditions.
While DOE requires numerous experimental runs, it has been developed to
maximize the information obtained per run.
See also
Development Reference: Six Sigma (11.62), Quality Function Deployment (11.51),
Uncertainty Analysis (11.68), Robust Design (11.57).
203
A Capstone team was asked to develop a power-

generating zipline for students in rural African villages.
The zipline would drive a generator that would charge SSE
a deep-cycle lead-acid battery. This battery would then
be used to charge LED lanterns that the students could
take home to illuminate their homework. The goal was SR
to make the zipline fun, while at the same time extract-
ing enough power to charge the lanterns.
PR
An analytical model of the zipline speed and

generated power was developed. This model,
which included 6 simultaneous nonlinear dif- PRR
ferential equations, was only solvable numer-
ically. It was necessary to choose the zipline
height, length, pulley diameter, and generator
gear ratio.
Run Number Friction Height Radius Stretch Gear Ratio
1 0.1 1 0.1 0.4 1.75
2 0.3 1 0.1 0.4 1.25
Design of Experiments
3 0.1 3 0.1 0.4 1.25
4 0.3 3 0.1 0.4 1.75
5 0.1 1 0.3 0.4 1.25
6 0.3 1 0.3 0.4 1.75
7 0.1 3 0.3 0.4 1.75
8 0.3 3 0.3 0.4 1.25
9 0.1 1 0.1 0.6 1.25 A 27-run, 5-factor central composite experiment was developed. This
10 0.3 1 0.1 0.6 1.75
experiment varied the friction, height difference, pulley diameter, rope
11 0.1 3 0.1 0.6 1.75
stretch, and gear ratio. Each factor was evaluated at five different lev-
12 0.3 3 0.1 0.6 1.25
13 0.1 1 0.3 0.6 1.75

els. The outputs for the experiment were maximum speed and average
14 0.3 1 0.3 0.6 1.25 power output.
15 0.1 3 0.3 0.6 1.25
16 0.3 3 0.3 0.6 1.75
17 0.3414 2 0.2 0.5 1.5
18 0.0586 2 0.2 0.5 1.5
19 0.2 3.414 0.2 0.5 1.5

80
20 0.2 0.586 0.2 0.5 1.5
21 0.2 2 0.3414 0.5 1.5

Average Power
22 0.2 2 0.0586 0.5 1.5 60

23 0.2 2 0.2 0.6414 1.5
24 0.2 2 0.2 0.3586 1.5 40

25 0.2 2 0.2 0.5 1.8535
26 0.2 2 0.2 0.5 1.1465

20
27 0.2 2 0.2 0.5 1.5
1.8
After analyzing the 27 experimental runs, a quadratic
1.6
model was developed for both of the responses as a func-
Ge
ar.
tion of each of the factors. This figure shows a surface 1.4 0.30
Ra
0.25
tio
plot of the effects of pulley diameter and gear ratio as a 0.20

0.15 s
function of pulley diameter and gear ratio, at a height of 1.2
0.10 Radiu
2 meters, rope stretch of 0.5 meters, and a friction factor

of 0.2.
Slice at Friction = 0.2, Height = 2, Stretch = 0.5
204
OD
CD
11.19 Design Review
SSE Assess your progress and get feedback and help from others
Design reviews are valuable events that take place multiple times during product
SR
development. They are typically held in the form of a short meeting. The purpose of
a design review is to allow a reviewer to assess the desirability and transferability of
the design, and to allow the product development team to receive feedback and
PR help from others outside of the immediate team.
People who are not yet accustomed to design reviews often find the design review
experience to be frustrating. To minimize frustrations, it is valuable to understand
PRR that a design review is a critique. Effective design reviews are centered on critiquing
the design not the designer.
Design reviews exist in many forms, and different organizations have different
traditions that define them, but they all exist to satisfy the principles listed here.
Principles that justify design reviews

• Small course corrections are easier and less costly to fix early than large course
corrections later.
• People who are one step removed from the detailed work can see things those
Design Review
who are doing the detailed work cannot see.

• It’s better for the team and the reviewers to find the problems than it is for the
market to find the problems after the product is released.
Principles for success

• Seek to understand the objectives and goals of the design review before
planning, leading, or participating in a design review.
• Develop a culture where design reviews are an open, two-way dialogue, with all
participants trying to understand each other.
• Structure design reviews so that they identify errors or weaknesses in design.
This is noticeably different than structuring the review to find only the strengths
of the design.
• Focus the design review on advancing the design and facilitating development,
more than trying to impress people or defend points of view.
• Make design reviews flexible so that they can be modified as needed for the
benefit of design.
• Schedule regular, frequent, design reviews to facilitate many small course
corrections.
• Plan for different kinds of design reviews, meaning reviews with supervisors,
reviews with clients, reviews with end users, etc.
• Assign a member of the team to keep sharable notes during the review so the
team can focus on the design and on understanding each other.
A starter outline
A basic design review outline is shown on the facing page.
See also
Development Reference: Basic Design Process (11.1), Project Objective
Statement (11.49).
205
OD
CD
SSE
SR
PR
PRR
Quickly introduce and
give context for the
project. Keep in mind Design Review Outline
that the reviewers
potentially have many 1. Project Objective Statement
projects/teams in their
Plan for a brief
mind. Simply remind
celebration of success.
them about the project. 2. Sharing of a recent great success Even though celebrating
success is not the
purpose of a design
These are the core of the
Design Review
3. Review of key success measures and review, most team
design review. They
evidence on how well the team is doing members will
should occupy the largest
understandably want to
amount of time and effort on them
do this. Planning a
in the review. In 3, the
short amount of time for
desirability of the design
this can boost morale.
is evaluated, with 4. Discuss of the greatest challenges
(in order of the most to least troubling)
design decisions were
made. In 4, the
roadblocks to greater
desirability are discussed 5. Review of assignments resulting from A brief moment at the
and possibly removed. design review end of the review should
be spent clarifying any
assignments and
actions
A basic outline for a design review. When preparing for or leading a design review,
modify the outline as necessary to achieve your review objectives.
206
OD
CD
11.20 Design Structure Matrix
SSE Order your design activities for high quality and efficiency
Further Reading
The design structure matrix (DSM) is a matrix used to track the relationships An excellent review article on
between key parameters for a product. The DSM identifies sets of parameters that 30 years of DSM practice,
are independent, dependent, and coupled. It establishes an order in which with good insight into broad
parameters should be determined for a minimum amount of iteration, and thereby application of the DSM
provides guidance for organizing activity maps. method, is Browning TR
(2001) Applying the design
structure matrix to system
decomposition and
Key methods integration problems: a
The traditional DSM is a matrix that lists all of the major activities used in a review and new directions.
development project as labels for both the rows and columns of the matrix. The IEEE T Eng Manage
48(3):292-306.
diagonal of the matrix is shaded. Marks are then placed at the intersection of a row
and column when the activity in the row needs a result of the activity in the column. An example of how DSM can
Thus, looking along a given row of the matrix, one can see all of the activities that be applied to develop
must be completed in order to complete the activity in that row. Similarly, looking effective activity maps is
reported in Yassine AA,
down a given column, one can see all the activities that need inputs from the activity Whitney DE, Lavine J,
in that column. Zambito T (2000)
Design Structure Matrix
Do-it-right-first-time (DRFT)
Interactions that are above the diagonal of the matrix indicate tasks that cannot be approach to design structure
done in sequence, because an earlier task requires the output of a later task. This matrix (DSM) restructuring.
indicates places where a restructuring of activities may be beneficial. Proc DETC ’00,
DETC2000/DTM-14547.
Note that examples can be found in the literature where the meaning of rows and
columns in the design structure matrix is reversed. If this is the case, interactions A current book on DSM is
below the diagonal indicate feedback relationships. Eppinger SD, Browning TR
(2016) Design structure
Marks in cells of the matrix can be binary (simply the presence or absence of a matrix methods and
mark), or they can be scaled, where different numbers are used to represent the applications. MIT Press,
Cambridge, MA.
strength of the interaction.
Once the matrix has been created, the tasks can be rearranged to minimize the
number of above-diagonal interactions. This rearrangement will streamline the
process and provide information in the order that it is needed.
Analysis of design structure matrices can be used to define subsystems, organize
development teams, and optimize development processes. See Browning and
Yassine et al. for more information on these uses.
Applicability
DSM is usually created during the opportunity development stage, as part of the
project planning process.
See also
Sections 2.3 and 2.4 of this book.
207
OD
CD
SSE
10
11
12
13
14
15
16
17
18
19
21
22
24
20
23
25
26
27
2
4
5
6
7
8
9
Select Material for All System Components 2 6 6 6 4
Freeze Proportions and Selected Hardpoints 4 6 4 6
Verify Hardpoints and Structural Joints 5 4 4 6
Approve Master Sections 6 6 6 4
Generate Structural Requirements (Analytically) 7 3 4
Develop Conceptual Design Strategy 8 3
Develop Structural CAD Model 9 6 4 4 4
Verify Functional Performance (Analytically) 10 6 4
Develop Preliminary Design Intent CAD model 11 6 3 6 6 4 4 6
Estimate Blank Size 12 4 4 4 4 3
Estimate Efforts 13 6
Develop Initial Attachement Scheme 14 6 4 6 4 3
Estimate Latch Loads 15 6 6
Design Structure Matrix

Cheat Out Panel Surface 16 6 4 3 4
Define Hinge Concept 17 4 3
Get Preliminary MFG & Assembly Feasibility 18 4 4 6 6 4 3
Perform Cost Analysis 19 6 6 4 4 3 4 4 4 4 3
Theme Approval for Appearance 21 4 4 3
Marketing Commits to Net Revenue 22 4
Approved Theme Refined for Craftsmanship Exec. 24 4 4
Perform Swing Study 20 4 4 6
Program DVPs and FMEAs complete 23 4 4 3 4
PDN0 - Class 1A Surfaces To Engineering 25 4 6 6 3 6 4
Conduct Cube Review and Get Surface Buyoff 26 4 4 3 6 4
Verify MFG & Assembly Feasibility 27 6 6 4 6 4 6 6 3 4 3
Design structure matrix for design of automotive hood. After Yassine et al.
208
CD
11.21 Dimensional Analysis
SSE Understand how design parameters affect performance
Further Reading
Dimensional analysis is a method of determining a minimal set of parameters that Sonin AA (2001) The
will affect the performance of a design. It provides scaling factors that help compare physical basis of dimensional
different designs using the same principles. A result of dimensional analysis is a set analysis 2nd ed. Handout for
of dimensionless groups that can be correlated with product performance across a 2.25. Available at
wide range of conditions. http://web.mit.edu/2.25/
www/pdf/DA_unified.pdf
Wikipedia has an excellent

How to do it article on dimensional
analysis:
The first step in dimensional analysis is to determine a complete set of n
http://en.wikipedia.org/wiki/
independent quantities that can affect the performance you are trying to model. The Dimensional_analysis
model is a model of n parameters:
P = f(Q1 , Q2 , . . . Qn ) (11.1)
The quantities Q1 . . . Qn form a complete set if no other quantities determine the

performance, and they are independent quantities if they can be independently
adjusted.
Dimensional Analysis
Having obtained a complete set of independent quantities, we express the units of

each quantity as a product of base units raised to powers. For example, mechanical
problems have three base units: length, time, and mass.
[Qi ] = Lli M mi tti (11.2)
We next identify a complete, dimensionally independent subset of the parameters

Q1 . . . Qk , where k ≤ n. A complete, dimensionally independent subset is one for
which the dimensions of every quantity not in the subset can be expressed as a
product of the dimensions of the quantities in the subset, and for which no quantity
in the subset can have its dimensions expressed as a product of the dimensions of
the other elements of the subset.
Once we have obtained the subset, we can express the dimensions of each element
not in the subset as a product of dimensions of subset elements. We can then
define a dimensionless form of the element as the ratio of the element and the
product of the subset elements.
Qk+i
Πi = N N
(11.3)
1i
Q1 . . . Qk ki
We also express the dimension of the performance as a product of the dimensions of

the subset, and then define a dimensionless value of the performance as the ratio of
the performance and the product.
P
Π0 = N N
(11.4)
Q1 01 . . . Qk 0k
Having done so, we have then reduced the problem to a dimensionless problem.
Π0 = f(Π1 , Π2 , . . . Πn k) (11.5)
We have now reduced the problem from an n-dimensional problem to an n − k

dimensional problem. We have also established a number of dimensionless ratios
Πi that can be used in our experimentation or analysis of the problem.
See also
Section 3.5 of this book.
209
CD
We shall apply dimensional analysis to understand the de-

P flection δ of a cantilever beam of uniform section length l
l
when a point load of P is applied. The beam material is SSE
assumed to be linear, isotropic, and homogeneous.
Based on the principles of mechanics, we expect the de-
flection to depend upon P , l, the modulus of elasticity of
the beam E and the area moment of inerta of the beam
cross section I.
Quantity Unit
The four independent quantities P MLT 2
that may affect the deflection of l L For a complete, dimensionally independent set
the beam are composed of the E ML 1 T 2 of quantities we define l and E, since we can
three mechanical base units. I L4 define all the remaining quantities by products
of l and E, but we cannot define l and E by
Quantity Unit Product Πi Ratio products of each other.
2
P MLT l2 E Π1 P /l2 E The products of l and E that are used to non-
I L4 l4 Π2 I/l4 dimensionalize P , I, and δ are shown in the
δ L l Π0 δ/l table.
Dimensional Analysis
End Deflection, m
End Deflection, m
Moment of Inertia, m4 Applied Load, N

Deflection varies with both moment of inertia and applied load, but there is scatter in
the data that indicates neither moment of inertia nor load totally predicts the deflec-
tion.
When the dimensionless quantities are plotted, the data all falls onto straight lines
for each value of Π1 , indicating that the dimensionless parameters Π1 and Π2 are
sufficient to predict the dimensionless displacement Π0 . The model has gone from
four independent parameters to only two scaled parameters.
Dimensionless Load
Dimensionless Deflection
Dimensionless Moment of Inertia

210
11.22 Drawing Checking

SSE Make sure your design is clear, correct, and unambiguous
Further Reading
Before being approved for release, every engineering drawing must be thoroughly Hill engineering provides a
SR
checked by an experienced designer or drawing checker. The purpose of checking recommended process for
the drawing is to make sure that there are no obvious mistakes on the drawing. performing drawing checks:
http://www.hillengineering.
It is important to have the drawing check carried out by someone other than the com/papers/How%20to%
PR
person who created the drawing. The drawing creator is so familiar with the drawing 20Check%20a%20Drawing.
that they are less likely to catch mistakes. pdf
The drawing check will generally have at least two levels: Format Check and Design Another procedure for
PRR checking drawings is
Check.
available here: http://tinyurl.
com/drawing-checking
Format check
The format check is performed to ensure that all relevant standards related to the
presentation of the drawing have been performed appropriately. Sample questions
that might be asked during the format check include the following: Is the title block
filled out completely? Has the appropriate drawing format been used? Are the
proper number of views listed? Are the dimensions complete? Are the appropriate
Drawing Checking
types of lines used in the drawing? Are the text heights correct?
The format check can be completed without knowing any details of the design intent
or the function of the part. It simply evaluates whether the presentation meets the
relevant standards.
The format check can be considered as roughly equivalent to spell checking a
written document. It makes sure the elements are correct, but does not ensure that
the document as a whole makes sense.
Design check
The design check is performed to ensure that the design as represented in the
drawing is feasible and meets the design intent of the team. Therefore, the checker
must understand the design requirements and the function of the part. Items such
as surface finishes and tolerances are vital parts of the design check.
In general, the fundamental concept of the design should not be part of the design
check. Fundamental concepts will have been previously evaluated in a design
review. However, if the checker has concerns about the concept, it is better to raise
them at this point rather than later.
The design check is similar to proofreading a written document. It makes sure that
the content makes sense and meets the desired outcomes.
When both the format check and design check have been completed, the checker
signs and dates the drawing in the appropriate location, indicating that the drawing
has been checked.
See also
Development Reference: Drawings (11.23).
211
SSE
SR
PR
The following should be considered when checking drawings for completeness and appropriateness.
PRR
Format Check
Description of Format Item to Check
Title block Is it completely filled out?
Views Do we have the proper number and kind to clearly illustrate the nature of the part
or assembly?
Dimensioning Are standard practices followed?
Dimensioning Do we have tolerances and surface finishes specified?
Dimensioning If the part is plated, does the drawing specify dimensions are pre or post
Drawing Checking
plating?
Dimensioning Are any parts overdimensioned?
Units Are the units clearly described as METRIC or INCH on the drawings?
Symbols Have industry-standard symbols been used in the drawings and diagrams?
Materials Is the material sufficiently specified so that it can be purchased from a general
materials distributor? Or if necessary, from a specific distributor?
Notes Do they apply specifically to the drawing being checked?
Notes Are they complete?
Reference Is the drawing precise when referencing other documents?
Approvals Are the approver names and approval dates provided?
Revisions Is the current drawing revision accurately recorded with approvals?
General Can the drawing be misinterpreted?
Design Check
Description of Design Item to Check
Dimensioning Do the dimensions accurately reflect the current product intent?
Dimensioning Do the dimensions make sense for the intended function?
Dimensioning Are the surface finishes appropriate for the part?
Dimensioning Are the tolerances appropriate for the part?
Dimensioning Is the precision of drawing dimensions appropriate?
Dimensioning Are the tolerances as loose as possible where they can be?
Dimensioning Are the datums appropriate for part function?
Dimensioning Are the dimensions relative to meaningful datums?
Dimensioning Do the critical dimensions and their tolerance result in a satisfactory
tolerance stack up?
Materials For critical parts, are the chosen materials optimal for that part?
Materials For mundane parts, are the chosen materials sufficient for that part?
General Can the design be simplified?
A sample checklist for drawing checking.
212
11.23 Drawings
SSE Create transferable design representations
Engineering or technical drawings are used to fully and clearly define the design of
SR
an engineered product. Drawings communicate all needed information from the
designer of the product to the production system to ensure that the product will
match the design intent in all important ways.
PR
Types of drawings
Most drawings are pictorial drawings, meaning that they show the geometry of the
PRR
part contained in the drawing. In addition to the geometry, drawings show the
dimensions of the part, tolerances for the dimensions, material, and surface finish.
Assembly drawings are used to pictorially show an assembly and the components
that make up the assembly. Components that make up an assembly may be either
parts or subassemblies. Assembly drawings generally show only limited details
about the components; the details are contained in part drawings. Assembly
drawings have hidden lines removed.
Part drawings are used to convey the details of an individual part. Part drawings are
required for every custom-designed part in a product. Pictorial drawings are not
generally needed for purchased parts, but a specification sufficient to purchase the
Drawings
part is required.
Another common drawing is a schematic diagram. Schematic diagrams show logical
relationships between components, rather than showing the geometry of the
component. Schematic diagrams are common in electrical, pneumatic, and
hydraulic systems.
Details of subsystem interfaces are often captured in interface control drawings.
Interface control drawings describe geometrical, information, signal, and power
interfaces between subsystems. They provide the standard which all subsystems
must meet.
Some complex systems will also include block diagrams. Block diagrams show
overall functionality of the system, with logical relationships between subsystems.
Block diagrams are generally used when a schematic diagram of the whole system
would be too complex to readily understand.
Non-graphical content
In addition to the graphical content of the drawing, there are important elements of
technical drawings that are included by convention. These include the following:
• A title block, containing a drawing title, a drawing number, a part number, a

revision number or letter, identifying information for the entity creating the
drawing, measurement units for the drawing, default tolerances, general notes
and specifications, and creator and approver information.
• A revision block, which lists all of the revisions made in the drawing from its
initial release, including dates and a summary of the changes.
• A bill of materials, which lists all of the materials necessary to create the
component in the drawing. The bill of materials is sometimes omitted from a
part drawing.
• A list of notes, which provides textual information not included in the graphical
drawing but necessary to properly create the component.
213
• A drawing frame, which labels horizontal and vertical regions of the drawing
with numbers and letters, thus facilitating discussion about the drawing.
SSE
Approval and revision control
In most cases, before a drawing can be released it must be approved by a number
of different individuals. The title block should contain a place to record this SR
approval. In most cases the title block lists the engineer, the drawing creator, the
drawing checker, and approvals for various functions of the company such as
production and testing. PR
The drawing should always be checked by someone other than the creator of the
drawing.
When revisions to a drawing are required, an engineering change order should be PRR
prepared that describes the change. The change order should be approved by the
entities who approved the original drawing. The drawing should be changed to be
consistent with the change order. The revised drawing gets a new revision code and
an updated revision history. The revised drawing should also be approved by the
entities who approved the original drawing.
See also
Development Reference: Drawing Checking (11.22)
Drawings
An engineering drawing of the kelly bar assembly for the human-powered water well drill de-
scribed in the design case study.
214
11.24 Engineering Change Order

SSE (ECO)
Make design revisions in a calm and considered way
SR
There comes a point in the evolution of a design where design changes need to be
carefully coordinated between multiple people or groups. The engineering change
PR order — or ECO — is a tool aimed at facilitating this. Specifically, an ECO is used to
control the revision of documents and parts. It does this by making sure that the
necessary stakeholders agree with how the change will be handled. It also serves as
PRR an official record of the change.
Parts of the ECO template

• The ECO is given a number for tracking/archival purposes, and a date when
the ECO will take effect.
Engineering Change Order (ECO)
• The owner (creator) of the ECO and the product under consideration are listed,
as well a brief description and the date the ECO was created.
• A revise from number to a revise to number is requested for specific
documents and parts (as identified by their document and part number).
• A description of the change, the reason for it, and impact is also provided when
the ECO is created.
• Disposition codes, as recommended by the ECO owner, indicate how the
change will be handled once it goes into effect.
• Signatures of key stakeholders are obtained, indicating their approval of the
change.
When to use an ECO

ECOs are generally used whenever a revised design has to be officially released by
the core product development team to other entities. These other entities have a
stake in the product, such as a manufacturer, a supplier, or an internal sales,
purchasing, or management team. ECOs are also used in the subsystem
engineering stage of development when large teams are involved and
communication is not as fluid as it might be in a small team. In these cases, the
ECO helps others on the team to know about key changes that may affect their work.
This is particularly important when working on the interfaces between subsystems.
A revision history in an engineering drawing can legitimately refer to an engineering
change order (by its ECO number) as a way of capturing critical revision information
in the drawing package. ECOs often include revised engineering drawings or
component specification sheet as attachments that are referred to in the ECO.
See also
Bill of Materials (11.3), Drawings (11.23), Drawing Checking (11.22).
215
SSE
ENGINEERING CHANGE ORDER

SR
ECO #: _____ EFFECTIVE DATE: ___________
ECO OWNER: DATE:

PR
PRODUCT: DESC:
ENG CHANGE NOTICE (ECN) REQUIRED? YES NO

IS CUSTOMER APPROVAL REQUIRED? YES NO Pre-Production ECO: YES
PRR
IS REGULATORY APPROVAL REQUIRED? YES NO Release ECO: YES
DOCUMENT # FROM REV TO REV PART # FROM REV TO REV
Engineering Change Order (ECO)

REASON FOR CHANGE AND IMPACT:
DISPOSITION CODES
CLASS OF CHANGE EXISTING PARTS EFFECTIVITY
A RECORD 1 USE E NEXT BUILD
B 2 WAY INTERCHANGEABLE 2 REWORK F NEXT PURCHASE
C 1 WAY INTERCHANGEABLE 3 RETURN TO VENDOR G PER SALES ORDER
D NON-INTERCHANGEABLE 4 SCRAP H MANDATORY
I MANDATORY W/RETURN
CODE: DESCRIPTION OF CHANGE:

C1F Implement when existing stock has been consumed Example Code
ECO APPROVAL:
ECO Board Rep.: Engineering Rep.

Manufacturing Rep.: Quality Rep.
Procurement Rep.: Purchasing Rep
Sales Manager: Sustaining Manager
Supplier:
Basic engineering change order template.

216
CD
11.25 Ergonomics
SSE Create person-friendly designs
Further Reading
The interface between humans and technical products is called product North Carolina Department
ergonomics. When establishing product ergonomics, designers consider the of Labor (2009) A guide to
characteristics, abilities, and needs of humans (Pahl et al., 2007) as well as the ergonomics. Available online
needs of the product. at https://blueridge.edu/sites/
default/files/pdf/continuing_
A significant amount of research has been done in the area of workplace ergonomics ed/Aguidetoergonomics.pdf
and user interface (UI) design for software. Whether it be for workplace, software, or
Openshaw S, Taylor E (2006)
hardware, the human is the starting point. Specifically, three human issues should Ergonomics and design: a
be considered (Cushman and Rosenberg, 1991). They are briefly discussed below. reference guide. Allsteel.
Available online at
https://www.allsteeloffice.com/
Biomechanical issues SynergyDocuments/
ErgonomicsAndDesign
These issues relate to the human’s body size and movement relative to the loads ReferenceGuideWhitePaper.
associated with using the product. pdf.
Henry Dreyfuss collected and cataloged anthropomorphic data for numerous
subjects including the data shown on the opposite page. His full presentation of the
data (Tilley and Associates, 2002) includes measurements of people of all ages,
residential space considerations, vehicular accommodations, maintenance
accessibility, and many other things. The data, which is for a US population,
Ergonomics
represents 98% of the population (the population between the 99th percentile and
the 1st percentile). The 50th percentile means that half the population (assuming a
normal distribution) is at or below this value, while the other half is at or above this
value.
There are numerous examples of how this information can be used to influence a
design. For example, it can influence control panel placement, grip size on power
tools, size of office chairs, and much more.
Physiological issues
These issues relate to the human body’s reaction to loads over time. All loads lead to
some level of physical stress and fatigue. Clearly a load that can be exerted once
may not be exertable continuously during a work day. Physiological measures that
are often considered are, cardiovascular (heart rate or blood pressure), respiratory
(respiration rate or oxygen consumption), and sensory (visual and hearing acuity or
blink rate) (Sanders and McCormick, 1993).
Psychological issues
These issues relate to the mental and emotional stress and fatigue associated with
learning to use, or using, the product. A product refined for good ergonomics will
require very little effort to learn to use. It will also feel intuitive to use, thus causing
very little emotional stress or fatigue.
See also
Development Reference: Design for Manufacturing (11.17), Design for
Assembly (11.16).
217
CD
I (SITTING SSE
HEIGHT)
198° POTENTIAL J (SHOULDER

MOTION UPWARD HEIGHT
SITTING)
188° UP, 61° BACK
POTENTIAL MOTION
K (OPTIMAL
F CONTROL
HEIGHT)
H 81° UP, 90° DOWN

POTENTIAL MOTION
35° UP, 38°

DOWN
POTENTIAL
45° OUT, 40° IN MOTION
POTENTIAL MOTION
Ergonomics
D
Dimensions and movement of the body. After (Tilley and Associates, 2002).
WOMAN MAN
99 Percentile 50 Percentile 1 Percentile 99 Percentile 50 Percentile 1 Percentile
A 69.8 64.0 58.1 75.6 71.3 62.6

B 55.4 50.4 45.4 60.6 54.6 49.1
C 36.6 33.4 29.6 40.1 36.5 32.5
D 19.7 18.0 15.8 21.7 19.8 17.3
E 3.3 2.9 2.5 3.7 3.2 2.6
F 11.0 10.4 9.2 12.3 11.0 9.7
G 20.7 18.6 17.5 23.1 21.1 18.9
H 28.5 26.5 23.5 31.5 28.6 25.5
I 37.1 33.8 30.8 39.3 36.0 32.7
J 25.2 22.0 20.8 26.6 23.6 20.8
K 14.8 13.2 12.5 16.2 14.4 12.5
*All Units In Inches
Body dimensions for the US population.

218
CD
11.26 Experimentation
SSE Measure the performance of your design
Experimentation can provide high-quality information about a design. It can also be

SR
expensive in both time and money. To make the best use of these resources, it is
desirable to do the following when experimenting:
PR Plan experiments before you do them

Carefully consider the experiments you intend to run. By thinking about all aspects
of the experimental program, you can maximize the amount of information you will
PRR obtain. You should plan the number of test conditions, the number of repetitions at
each condition, the kind of measurements to be taken, and the expected analysis of
the data. When you do this before the experiment, you can make appropriate
trade-offs to ensure you get the needed information within the time and resource
limits. More information on experimental plans is found in Design of
Experiments (11.18) in the Product Development Reference.
Test at multiple conditions

While it is tempting to test only at the optimal conditions, it is certain that the end
user for a product will use it in less than ideal circumstances. In fact, you can
Experimentation
probably count on somebody misusing the product in ways you haven’t even
imagined. Effective experimentation seeks to know how well the product performs
under a wide variety of conditions. More information can be found in Robust
Design (11.57) of the Product Development Reference.
Complete all non-destructive tests before potentially destructive tests

Prototypes are expensive, and sometimes not as robust as we would like them to be.
It’s tempting to avoid any tests that might harm the prototype. But as described
above, it’s important to test in non-ideal conditions. To allow completion of all
possible tests, it’s important to put off any tests that might damage or destroy a
prototype until all other testing has been completed. Then, if the prototype is lost, all
the rest of the information is still available.
For example, a team was developing a piece of carpet cleaning equipment that
needed to survive a drop down a staircase. After completing the basic performance
testing, the team held their collective breath and tossed the equipment down the
stairs. Fortunately, it survived. In another case, a team developed variable output DC
voltage supply. In their excitement to test the product after they got it working, they
tested a high voltage to a low-impedance load. The resulting high current rush
destroyed some of the components in the supply and required a time-consuming
rebuild before testing could be completed.
Record all data and setup information necessary to perform the

experiment
In the excitement to get testing, it can be easy to jump into testing without recording
the test setup or the means of data collection. Sometimes only the output data is
recorded. Environmental data (such as the temperature of the room) can easily be
overlooked. In general, it is best practice to record anything you can think of that
might affect the test.
It can also be helpful to photograph the test setup and the test in progress.
Sometimes things that were not recorded can be determined by referring to
appropriate photographs.
219
CD
When mistakes are made in the setup or recording data, do not delete the mistake.
Instead, indicate the error clearly, but keep the original record. This may help to
avoid mistakes in the future.
SSE
Calculate preliminary results during experimentation

During the experimentation, while the data is being collected, a preliminary SR
processing of the results (perhaps a calculation) should be performed. Preliminary
processing can identify mistakes in experimental setup and prevent hours of wasted
data. By processing as you go, you will know if you are achieving reasonable results.
PR
It can be helpful to create a data calculation worksheet or template as part of the
experimental plan. Then when the experiment is carried out, the output data can be
entered into the template, the calculations carried out, and the results obtained
almost immediately. These results are then evaluated to see if they make sense. PRR
Analyze the data statistically

Every experiment has a degree of uncertainty or randomness associated with it. As
experimental conditions change, the results of the experiment change. It is
important to determine whether these changes reflect real differences in
performance, or are simply due to chance or randomness. Statistical methods can
be used to assess the significance of results.
In addition, statistical methods can be used to create approximations of the behavior
Experimentation
of the product over a range of operating conditions.
The power of statistical analysis is greatest when the experiment has been planned
from the beginning with statistical analysis in mind.
Prepare a written summary with at least one summary data plot

Careful thought about the test, results, and inferences should be captured in writing
for transferability. If the results are only in the head of one team member, they
cannot be used for any other purpose. In contrast, if they are thoughtfully written,
they can be referred to again and again.
In many cases, the results of an entire experimental program can be summarized in
one careful data plot. Such a plot makes it easy for one who is unfamiliar with the
work to grasp the results. Often, it is worth thinking about the summary plot that is
desired before the experimental plan is finished.
Following the above principles helps assure the most effective outcomes from
experimentation.
See also
Development Reference: Dimensional Analysis (11.21), Robust Design (11.57).
220
11.27 Failure Modes and Effects

SSE Analysis
Take concrete steps to reduce the risk of product failure
Failure Modes and Effects Analysis (FMEA) is a subjective, yet structured, design
tool aimed at identifying failure risk and reducing it through design changes. FMEA
may be carried out on the product (termed design-FMEA or DFMEA), or it may be
carried out on the process used to manufacture the product (termed process-FMEA
or PFMEA). FMEA produces a Risk Priority Number (RPN), which guides the team
PRR to focus on the high-risk failure modes.
How to do it
1. Identify and list system components. Also list the functional purpose of the
components; there may be multiple purposes for one component.
Failure Modes and Effects Analysis
2. For each component, identify and list possible failure modes.

3. For each failure mode, identify the most severe potential effects of the failure.
4. Rate the severity of each effect, using the severity scale from the rating table.
5. For each failure mode, identify possible causes; there may be multiple causes
for each failure.
6. Rate the likelihood of each potential cause, using the likelihood scale from the
rating table.
7. Identify the controls preventing each cause, and the indicators that the cause
exists before the failure effect occurs.
8. For each cause, given the controls and indicators from the previous step, rate
the probability that the cause will be detected before the failure effect occurs,
using the detectability scale from the rating table.
9. Calculate the Risk Priority Number (RPN) for each cause as the product of the
severity rating, the likelihood rating, and the detectability rating.
10. For items with a high severity (9-10) or a high RPN (over about 125) take
actions to reduce the RPN; after actions are complete recalculate the RPN to
show improvement.
Tips
FMEA is generally carried out late in concept development or early in subsystem
engineering. FMEA can be carried out on individual components, subsystems, or
the system.
FMEA is best when careful justification is given for the subjective ratings. It is best to
have a small team, rather than an individual, work on the FMEA. Where feasible, a
multi-function team is often more effective than a single-function team.
Using a series of FMEAs can be an effective strategy for evolving the product. For
example, a high-level FMEA can be performed to filter out the mundane many in
order to focus a more detailed FMEA on the critical few.
See also
Lean Six Sigma’s steps and templates for FMEA available at
lssacademy.cpm/2007/06/28/10-steps-to-creating-a-fmea.
Development Reference: Fault Tree Analysis (11.28).
221
FMEA Rating Table
Rating Description of Severity rating Description of Likelihood rating Description of Detectability rating
1 The effect is hardly noticeable to the Extremely low; remote chance of Almost certain to detect before
customer occurrence failure SSE
2-3 Slight effect that causes customers Medium low; slight chance of High chance of detection before
some annoyance, but they do not occurrence failure
seek service
4-6 Moderate to significant effect, Medium; occasional occurrence Medium chance of detection before
customer dissatisfaction, service failure
sought and/or required
7-8 Serious effect, system may not be Medium high; frequent occurrence Low chance of detection before
operable; elicits customer complaint failure
9-10 Hazardous effect, complete system High; regular occurrence Very remote to no chance of
shutdown; safety risk; life detecting before failure
threatening
PRR
Grappling Hook
In 2011-2012 the Air Force Research Laboratory spon-
Failure Modes and Effects Analysis

sored a BYU Capstone team and asked them to design,
build, and test a climbing system that would allow troops
Climbing Rope
to scale vertical surfaces 90 feet in height. The device
needed to be compact and carried by troops as standard
equipment. The entire process of preparing to and climb-
Gun To Launch
Hook & Rope
ing the surface should take only five minutes.
The team chose a rifle-mounted device that launched a
hook attached to a rope to the top of the climbing surface.
A battery-powered winch was then attached to the rope,
and the winch lifted the solider to the top of the climbing
surface.
Prepared By: Team Alpha

FAILURE MODE AND EFFECTS ANALYSIS
Shortly after For Product/Subsystem: Climbing Assistance Tool - Grappling Hook Concept, Rev. 2.0
Date: 5 Nov.
Improved Situation: 15 Jan.
selecting this
concept, the team Functional
Purpose of
Current Situation
Assigned
Improved Situation
Component Failure Mode Failure Effect Failure Cause
performed an Component
S L D RPN
Action
S L D RPN
FMEA. The results
Grappling Hold (Attach) Didn’t attach 10 4 6 240 Develop pre-climb pull
7 3 5 105
of the FMEA are Hook Over Top
Attachment
Fails During
well to top edge procedure, Brady by Dec. 10
Climber Falls
provided in the Edge of
Structure
Ascent Edge of
10 3 9 270 Develop pre-climb pull 7 3 5 105
Structure Fails procedure, Brady by Dec. 10
table. Notice Add redundant connector
Poor Connector 10 4
that the current Holds 300
lbs.
Rope
Detaches from Climber Falls Design
8 320 and perform FEA on new
connector, Brady by Nov. 28
5 3 3 45
situation (columns Grappling

Knot Fails 10 3 3 90 Add Redundant Knot, Bryan 5 3 3 45
Hook by Nov. 7
6-9) was evalu-
ated early in the Poor Material
Choice
8 2 6 96 None - - - -
process (5 Nov Hook Poor

Unusable 8 2 4 64 None - - - -
2011), assign- Geometry
Hook Hits Object Add Calibrated Sighting
ments were made, Head-on After 8 4 5 160 Features to Rifle; 8 3 3 72
Rifle Deployment Aaron/Jason by Jan. 14
and the evaluation Battery Ascent Poor Winch
Winch Climb the 5 2 3 30 None - - - -
of the improved Rope
Exhaustion Ceases Choice
situation was com- Climber Using
Wrong Rope
3 5 5 75 None - - - -
Rope Slips Climber Slips
pleted after the in Winch Down The
Poor Pulley
assignments were Rope
Design
3 3 3 27 None - - - -
completed (15 Jan Rope Jam 10 3 2 60 None - - - -

2012). Winch Severs
Rope
Climber Falls
Procedure To Inspect As You
Rope Wear 10 4 8 320 Climb; Dave by Jan. 14 10 4 3 120
Rifle Launch Rifle Does Not Will Not Be Able Hook and Rope
5 2 3 30 None - - - -
Deployment Launch 90 feet to Climb 90 feet Too Heavy
Grappling
Hook 90 feet Rifle Barrel
Trying to Launch Trying to Launch Too
Vertically Explodes Due To User Injury Too Much Weight 9 2 4 72 Much Weight 9 2 3 54
Attachment Weight
222
11.28 Fault Tree Analysis

Understand potential causes of failure
Further Reading
Fault tree analysis (FTA) is a method of identifying possible failures in a product and Wikipedia has an excellent
SR
coupling them with failures in the manufacturing process or in components or article on Fault Tree Analysis:
subsystems of the products. FTA helps provide probability estimates for individual https://en.wikipedia.org/wiki/
failures, and provides failure information that supports FMEA. Fault_tree_analysis
PR NASA has prepared a fault
tree analysis handbook:
Key methods Vesely W et al. (2002). Fault
Fault tree analysis is a tree-based analysis that can be used to perform quantitative tree handbook with
PRR aerospace applications.
probability analysis on particular failures.
Available for download at
FTA starts with identifying a critical failure. All possible causes for the failure are http://www.hq.nasa.gov/
then listed. The logical relationships between each of the causes are identified. office/codeq/doctree/fthb.pdf
The next level of the FTA is then created by looking at all the causes for the top-level
failure to identify the situations that would lead to these second-level conditions.
The process is repeated until it reaches the level of basic event causes, that is, those
events that are the possible triggers for the high-level failure.
Fault Tree Analysis
Quantitative analysis can then be performed on the fault tree. Given estimates of the
likelihood of each of the basic events, the probabilities of each of the higher events
can be calculated based on the structure of the fault tree. This can ultimately lead to
an assessment of the probability of the top-level failure occurring.
Given a fault tree, one can see risk points for failure, which provide guidance for
system redesign to increase reliability.
Applicability
FTA is generally performed during subsystem engineering. It is revisited during later
development stages as problems occur.
A single fault tree thoroughly analyzes a single failure possibility. It does not analyze
all possible failure modes for a product. Each critical failure mode must have a
separate FTA completed.
See also
Development Reference: Failure Modes and Effects Analysis (11.27).
223
SR
Lamp Doesn’t
Illuminate AND Gate
PR
G001 OR Gate
Basic Input
PRR
Undeveloped Input
Lamp Removed
From Socket
No Power
B002 To Socket
G005
Lamp Faulty
G003
Fault Tree Analysis

Circut Breaker
Wiring Bad Switch Bad
Tripped
Burned Out Bad Contacts U012 U013 U014
B006 U007
G015
Socket Faulty
Light on GFCI
GFCI Circut Tripped
G004
B016 U017
Dirty Oxidized Bent Broken

Contacts Contacts Contacts Contacts
U008 U009 U010 U011
A fault tree for the lamp in a room failing to light. There are four direct causes for the failure to light: the lamp
could have been removed from the socket, the lamp could be bad, the socket could be faulty, or there could be
no power to the socket. Any one of these occurrences would cause failure to illuminate, so they are connected
with an OR gate. One cause of no power to the socket would be if the lamp were on a GFCI circuit and the GFCI
were tripped. Both of these events are necessary to create a lack of power to the socket, so they are connected
with an AND gate.
Some inputs, like a burned out lamp, are basic inputs. Others, like the circuit breaker being tripped, have
causes, but the causes are not considered in this analysis, so they are considered undeveloped inputs. A more
complete fault tree analysis could develop the undeveloped inputs.
224
OD
CD
11.29 Financial Analysis
SSE Understand financial implications of design decisions
Financial Analysis is a set of methods used to predict and track the financial
implications of decisions made during product development. It is used to support
decisions about what is to be developed. It is also used to support decisions about
specific activities to be undertaken during product development.
Key methods
There are two commonly used systems of financial analysis for projects, payback
analysis, and net present value. Payback analysis is simpler, and often used for
short-term projects. Net present value is more complex and more correct, and is
typically used for long-term, high-value projects.
Payback analysis
In payback analysis, the total costs of the project are calculated. The periodic (i.e.,
monthly) benefits of the project are also calculated. The total length of time until the
sum of the benefits equals the sum of the costs is the payback period. It is common
for companies to have a standard maximum payback period for funding project. For
Financial Analysis
example, a company may say they will only fund projects with a payback of 18
months or two years.
When calculating benefits in product development, it is important to only calculate
the net benefits. For example, if a product is sold for $10.00, with a manufacturing
cost of $4.00, the benefit for selling 10,000 products per month is $60,000 per
month, not $100,000 per month.
Net present value

Net present value is used to analyze projects with long lifetimes. Net present value
calculations include the time value of money. This means that money in the future is
worth less than money in the present. Therefore, future cash flows are discounted to
reflect this difference in value.
In net present value analysis, the costs and benefits throughout the life of the project
are calculated. Benefits (and costs) that occur in the future are converted to their
present value through the discount equation:
FV
P V (F V, t, r) = (11.6)
(1 + r)t
where P V is the present value, F V is a future value that occurs t time periods in
the future, and r is the discount rate, which is analogous to an interest rate. It is
important the t and r are for equivalent periods, that is, if r is an annual interest
rate, t must be in years. Or if r is a monthly interest rate, t must be in months.
We can also solve equation 11.6 for F V , r, and t:
F V (P V, t, r) = P V (1 + r)t (11.7)
log(F V /P V )
t(F V, P V, r) = (11.8)
log(1 + r)
225
OD
CD
1/t
FV
r(F V, t, P V ) = −1 (11.9)
PV SSE
When all the costs and benefits for the project have been converted to present
values, the total present value costs are subtracted from the total present value
benefits to give the net present value (NPV):
X
NB
X
NC
NP V = P V (Bi , ti , r) − P V (Cj , tj , r) (11.10)
i=1 j=1
where NB is the number of benefit payments in the life of the project, NC is the
number of cost payments in the life of the project, Bi and ti are the benefit amount
and the time for benefit i, and Cj and tj are the cost amount and time for cost j.
If the NPV is positive, the project is considered to be a good investment.
Projects should not be ranked by NPV, with the highest NPV considered the best
project. The internal rate of return is the appropriate method for ranking projects
according to their financial goodness.
NPV is sensitive to the discount rate. Choosing a discount rate should be done
carefully. Most companies will have a specified discount rate. If there is no
Financial Analysis
company-specified rate, the rate should be chosen to be approximately the return
on investment for the company.
The use of discounted cash flows to analyze the financial performance of projects is
a subject often called Engineering Economics.
Applicability
Financial analysis should be performed during the opportunity development stage of
product development to determine broad parameters for success. The financial
analysis should be revisited at each subsequent stage. Projects may be canceled if
it makes no financial sense to continue with them.
See also
Ulrich, K.T. and S.D. Eppinger, Product Design and Development, 5th ed, 2012,
McGraw Hill Irwin, pp. 354-372.
Development Reference: Cost Estimation (11.11), Cost Targets (11.12).
226
11.30 Finite Element Modeling

SSE Obtain high-fidelity performance predictions
Further Reading
Finite element modeling (FEM) is an engineering modeling technique for obtaining Zienkiewicz OC, Taylor RL,
SR
numerical solutions to problems that are too complex for developing analytical Zhu JZ (2005) The finite
solutions. FEM can be used for structural modeling (stress, deflection, vibration), element method: its basis
thermal modeling (temperature, heat flux), fluid modeling (pressure, flow rate), and fundamentals Sixth ed.
electrical modeling (potential, current), and more. Models can also be coupled Butterworth-Heinemann.
between the various domains. Bathe KJ (2006) Finite
element procedures.
Klaus-Jürgen Bathe,
Key methods Cambridge, MA.
Finite element modeling consists of three fundamental steps: pre-processing, Meshfree methods are also
solving, and post-processing. available: http:
//www.compumag.org/jsite/
Pre-processing is the first step in finite element modeling. It consists of creating images/stories/newsletter/
appropriate geometry, applying boundary conditions, and applying loads. ICS-07-14-2-Rodger.pdf
Creating geometry requires the creation of the overall geometry to be modeled, then
crating a mesh that fills the model geometry. Different types of mesh elements can
Finite Element Modeling
be used to give different fidelity models; higher-order elements will require more
solution time, but generally more accurate results.
Solving involves executing a solver to solve the relevant partial differential equations.
The geometry, boundary conditions, and loads are supplied to the solver and the
solver calculates results. There is very little user interaction during the solution
phase. Depending on the fidelity of the model, solution times can be seconds,
minutes, hours, days, or weeks. Parallel computing can often be used to decrease
the solution time.
Post-processing is the step that involves getting the desired numerical solutions out
of the digital solution files and into a form that is usable for the design team.
Post-processing might involve automatically parsing an output file to obtain a
particular number or set of numbers. It also may include plotting contours or
shaded surfaces to indicate stress or temperature levels. Even more complex
post-processing is possible. Post-processing often requires the largest amount of
user interaction time when performing finite element analysis.
Many CAD/CAM/CAE systems either include a finite element modeling package or
support exchange of data with finite element packages. Sometimes the CAD system
can be used for pre- and post-processing; other times it merely exports geometry
data for use with a finite element pre-processing package.
In many cases, the geometry used for FEM needs to be simplified, because small
features that have little or no effect on the behavior being modeled will cause very
fine meshes to be created, with a corresponding increase in solution time.
Applicability
Finite element modeling is most often used during the subsystem engineering stage
of development.
See also
Development Reference: CAD Modeling (11.6).
227
SSE
SR
Finite element model of a vehicle crash. Image from Wikipedia, and placed in the public domain. Finite Element Modeling
228
OD
CD
11.31 Focus Groups
Find out what the market wants in a hurry
Further Reading
A focus group is a group of 6-10 individuals who are asked a series of open-ended One of the most cited books
questions by a moderator in order to understand how they feel about a product or on focus groups is Krueger
service. Properly done, focus groups can be a rich source of qualitative RA, Case MA (2009) Focus
understanding about the desires of the market. groups: a practical guide for
applied research, 5th ed.
Sage, Los Angeles.
How to do it A good checklist for
conducting focus groups can
• Determine the purpose of the focus group. The purpose of the focus group be found online at
should be narrowly defined in order to guide the rest of the planning. Vague https://assessment.trinity.
purposes will lead to vague focus groups that provide little useful information. duke.edu/documents/How_
to_Conduct_a_Focus_Group.
• Identify and invite the participants. The participants in the focus group should pdf
be selected to be appropriate for the purpose identified above. Homogeneous
groups will tend to work together better and explore the subject more deeply. If
heterogeneity is desired, it may be best to have a heterogeneous set of
individually homogeneous focus groups.
• Develop a questioning route. A focus group will generally have from 8 to 10
questions. The questions should be carefully designed and tested before the
Focus Groups
focus group convenes. In general, questions should be open-ended, clear,

short, and one-dimensional. The sequence of questions is ordered so that
general questions come before specific questions, positive questions come
before negative questions, and uncued questions come before cued questions.
The time to be allocated to each question must be determined so all the
questions can be covered in the focus group.
• Conduct the focus group. The focus group involves the participants and the
moderator. The moderator is vital to successful outcomes in focus groups. The
moderator must involve all of the participants, and must seek to draw out the
participants’ ideas, rather than reinforce the moderator’s ideas. In many cases,
it may be desirable to use a professional moderator to conduct focus groups.
The focus group should be recorded (at least audio, preferably video) so that
the participants’ responses can be thoroughly analyzed.
• Analyze the data. The recording of the focus group should be transcribed. The
transcription is then reviewed to identify common themes. This analysis will
necessarily be somewhat subjective, so be very sensitive to biases among the
analyzers. The analysis must seek to identify the participants’ feelings, rather
than seeking to confirm the design team’s opinions.
Limitations of focus groups

• Focus groups are generally poor at determining quantitative data, such as
numerical ratings of products. Surveys are much better for this type of data.
• Focus groups can tend to reflect groupthink, or be dominated by a single
strong personality. Skilled moderators can help minimize this problem.
• Data from focus groups is difficult to analyze statistically, because it is
qualitative rather than quantitative. This lack of statistical analysis causes some
researchers to discount the use of focus groups.
• Focus groups provide little or no information about items that are not part of
the question sequence. Be sure that you don’t interpret the results more
broadly than deserved.
229
OD
CD
See also
Development Reference: Interviews (11.34), Observational Studies (11.40).
Focus Groups
Focus groups provide an interactive way of obtaining qualitative information from market
representatives.
230
OD
CD
11.32 Goal Pyramid
Focus on the most important product development goals
In the early stages of product development the team identifies many requirements
for a successful product. Because requirements differ in importance, it would be
wrong for the team to give equal attention to all of them. The goal pyramid organizes
the performance measures to help the team focus appropriately in order to create
outstanding products.
• A few performance measures are Constraints. Constraints must be met in
order to have a viable product, but there is not much concern about how well
the constraints are met. Constraints can usually be recognized as yes/no
• A handful of Key Success Measures distinguish between ordinary and great
products. Typically there are about five to nine key success measures. If a
product reaches the target or better for the key success measures, it will be
considered a very desirable product. The development team’s best efforts
should be put toward achieving the targets for key success measures.
• There may be one or two Stretch Goals for key success measures. Stretch
goals are values that exceed the target and would constitute exceptional
performance. However, it is not clear that stretch goals can be achieved.
Achieving stretch goals constitutes exceptional performance, but failure to
Goal Pyramid
achieve stretch goals does not constitute poor performance. The number of
stretch goals should be limited to avoid diffusing the team’s focus.
• Performance measures that are neither constraints nor key success measures
are Basic Performance Measures. Basic performance measures must be met
to have an acceptable product, but there is little value in optimizing to have
performance be better than acceptable.
By clearly identifying key success measures and stretch goals, the team can keep
the design focus where it makes the most difference. At any stage of development,
the desirability of the design can be largely determined by evaluating the likelihood
of achieving targets and stretch goals for the key success measures.
How to do it
The following steps can be used to build a goal pyramid:
1. Make a list of performance measures. The performance measures should be
product characteristics that are important to the market.
2. Identify the key success measures. In consultation with market
representatives, find out those things that would really delight the customer
and make a big difference in customer satisfaction. Try to identify a handful of
measures that the market really cares about.
3. Identify stretch goals. As you consider the possibilities for the key success
measures, find a couple of things that would amaze the customer if they were
reached, and aim to reach them.
4. Identify the constraints. In consultation with market representatives, find out
which performance measures need only be met. Once met, the market is
indifferent to (or has no concept of) the degree to which it is met. Resist the
temptation to classify most of your performance measures as constraints; be
sure the market really is indifferent to the level of performance for the
measures.
5. Any performance measures that are neither constraints, key success
measures, nor stretch goals are classified as basic performance measures.
231
OD
CD
Applicability
The goal pyramid is mostly created during Opportunity Development. In most cases,
stretch goals are only identified during Concept Development, after an overall
concept has been selected. The pyramid is revised as necessary throughout the
product development process.
The goal pyramid and the requirements matrix

You can use the goal pyramid to organize the performance measures in a
requirements matrix. Classify the performance measures into constraints, basic
measures, key measures, and key measures with stretch goals.
All performance measures have acceptable limits. Unlike other performance
measures, constraints have no ideal values. Therefore, the target value for a
constraint will be a range that contains the acceptable limits. Only key measures
with stretch goals will have a stretch goal as part of the real values.
Having classified the measures, it is effective to put key measures with stretch goals
at the left of the performance measures list, followed by key measures, basic
measures, and constraints. The real values in the matrix are also adjusted to match
these categories. A new row of stretch goals can be added to the real values. A
matrix with this structure facilitates focusing on the most important performance
measures.
Goal Pyramid
See also
Development Reference: Requirements Hierarchy (11.54), Requirements
Matrix (11.55).
Key Success Constraints

Measures Basic
Measures
1–2
Units
STRETCH Product:
GOALS Subsystem:
Lead to:
Exceptional Products Revision Date:
Performance Measures
5 – 10
Impo
KEY SUCCESS MEASURES

rtanc
e (op
Lead to:
tiona
10
11
12
13
14
15
16
17
18
Market Requirements Market Ratings

1
9
l)
Excellent Products 1
2
3
4
5
6
DOZENS A FEW 7
8
9
BASIC PERFORMANCE MEASURES CONSTRAINTS 10

Importance (optional)
Acceptable
Lower
Lead to: Lead to:

Limit
Ordinary Products Viable Products

Ideal Values
Ideal
Acceptable
Upper
Limit
The goal pyramid graphically represents different

Target
kinds of performance goals for product development. Stretch goal

Stretch
targets
Real Values
The foundation consists of basic performance mea-

Predicted
sures and constraints, which need to be in the ac-

Measured
ceptable region but don’t drive purchase decisions.

A relatively small number of key success measures
distinguish between good and great products. One The requirements matrix can be adapted to work with the
or two stretch goals can inspire the team to aim for goal pyramid by reordering the performance measures ac-
an exceptional product. cording to category and adding a row in the real values for
stretch goals. Further, constraints have no ideal, and only
a few key measures have stretch goals.
232
OD
CD
11.33 Internet Research
SSE Access the world’s knowledge from your desktop
Further Reading
Perhaps the most commonly used method of finding existing knowledge is a search Wikipedia’s entry on data
on the internet. Because internet search engines can return millions of hits for a mining
given topic, it is essential to separate the desired information from the noise.
It goes without saying that the internet is full of useful information. This is true even
in the context of product development. For example, Amazon1 can be used to
access regional sales statistics for competitive products, product reviews, information
regarding what other people also considered or purchased, and so on. This type of
information can be extremely useful in establishing market requirements.
One of the greatest benefits of this type of information is that it is more current than
what can be found in published literature.
Internet data can be accessed manually or by using data mining techniques. We
recently used data mining techniques to search the internet for engineering design
terminology. With relatively simple data mining techniques we searched 96,876
books in the Library of Congress, and 1,917,328 entries in Google Scholar. With the
data mining techniques, the searches were completed in a matter of minutes.
For the Library of Congress data, shown in the figure on the opposite page, the data
Internet Research
mining extracted the number of books published each year, where the search terms
were present in the publication. It also extracted other interesting information such
as the birth place of the author.
Internet searching can also be used to find existing solutions to a design problem.
For example, a project was recently proposed to develop an improved portable
dental chair by modifying an existing chair. A Google search of “portable dental
chair” returned 806,000 results. On the first page of the results there were images
of at least seven different commercially available chairs. There were three different
sellers of multiple chairs. There was an article written by a non-profit world dental
organization that described the strengths and weaknesses of various commercial
chairs. In less than five minutes, the designer obtained a good understanding of the
existing solutions.
One potential problem with internet searching is the assumption that all the good
information is on the first few pages returned. In many cases, later pages have the
best information. Deciding when it’s time to end a search requires good judgment.
See also
1
www.amazon.com
233
OD
140 CD
120 SSE
Number of Entries in Library of Congress
100
80
60
40
20
Internet Research
0
1850
1859
1862
1865
1868
1871
1874
1880
1883
1886
1889
1892
1895
1901
1904
1907
1910
1913
1916
1925
1928
1931
1934
1937
1940
1946
1949
1952
1955
1958
1961
1967
1970
1973
1976
1979
1982
1991
1994
1997
2000
2003
2006
1853
1856
1877
1898
1919
1922
1943
1964
1985
1988
2009
Engineering Design FEA Product Decomposition
CAD/CAE/CAM GD&T Product Development Process
Benchmarking Global Product Development Product Family
Concept Generation and Selection Industrial Design Product Specifications
Customer Needs Intellectual Property Prototyping
Design for “X” Modularity PVT/EVT/DVT
Design for Manufacturing Optimization Quality Function Deployment
Failure Modes and Effects Analysis Product Architecture Rapid Prototyping
Internet research data collected with data mining techniques. Here the number of new entries added to the
Library of Congress each year that include engineering design keywords.
234
OD
CD
11.34 Interviews
Get in-depth understanding of what the market wants
Further Reading
Interviews allow product development team members to have direct contact with Mulwa FW, (2003)
people pertinent to the development project. Direct contact helps the team member Participatory monitoring and
get a firsthand account of needs, product use, opinions, complaints, difficulties, and evaluation of community
so on. Interviews can be done with one, or with a few participants. One-on-one projects. Paulines Pub,
interviews are valuable because a participant’s responses are uninfluenced by other Africa. See Ch. 5 –
People-Friendly Evaluation
participants. Small group interviews can be good because participants often have Methods.
insightful dialogue with other participants.
A primary goal of interviewing should be to elicit an honest response from
participants1 . Don’t be mistaken; this is very hard to do.
How to do it
• Establish what design question the interview will help answer: For example,
how does a specific competitive product meet the market requirements of the
current project?
• Choose who will be interviewed: Is there a certain demographic that needs to
be targeted? Is there a sample population size the team will target? Griffin and
Hauser (Griffin and Hauser, 1993) suggest that 90% of customer needs are
Interviews
identified after 30 interviews.

• Choose an interview location: This choice should be tied to what design
question the interview will help answer. Generally, it should be as close to the
context of the design problem as possible. For example, if we are designing
camping stoves, we should be interviewing people in a campsite.
• Create and test the interview questions: The quality of the interview hinges on
this point. Questions should be established with care. They should be tested
and refined before performing the actual interviews. The questions asked
should lead to the type of data the team needs (e.g., qualitative data,
quantitative data).
• Determine how the interview data will be recorded: Options are notes (least
disruption to the interview process), still photograph, audio recording, video
recording (most disruption to the process).
• Perform the interviews: When performing the interviews, be flexible, look for
hidden needs, and try to observe non-verbal information.
• Process the data and collect additional data as needed.
Starter interview questions

These questions may be useful in getting feedback about existing products on the
market.
• When do you use this type of product?

• Why do you use this type of product?
• Walk us through a typical session using the product. 1
Eliciting an honest response is
• What features do you like in this product? the opposite of: (i) convincing the
• What features do you dislike in this product? participant of what he or she needs,
(ii) teaching the participant how
• What do you consider when buying a product like this? to use a product that is difficult to
• If there were no limitations, what would you do to improve this product? understand, or (iii) making them
think there is an answer you want to
receive.
235
OD
CD
See also
Interviewing a woman in Puno, Peru, about how she would use a small kiln to improve her ceramics business. Interviews
236
CD
11.35 Method 635
SSE Generate more than 100 solution ideas in an hour or less
Further Reading
Method 635 is a group creativity technique that encourages more individual and Video: youtube, by linkmv97
collective thought to develop concepts at a deeper level than brainstorming. It was called “Method 6-3-5
originally developed by Professor Bernd Rohrbach in 1968. (Brainwriting)”.
One of the benefits of Method 635 is that it engages quieter individuals on the
product development team in a way that brainstorming typically does not.
How to do it
To carry out the activity, 6 people familiarize themselves with the problem at hand.
Each creates and writes down 3 candidate solutions. The list of candidate solutions
is then passed to the next participant, who adds 3 more candidates by building on
the ideas from the previous participant. The built-upon-ideas are then passed to the
next participant and eventually through all participants.
Hence the name 635, 6 participants, 3 ideas each, further developed by 5 other
people.
By the end of the method (typically 30 to 60 minutes later), there will be 6 lists of
candidate solutions, each of which contains 18 systematically developed
Method 635
candidates, for a total of 108 solution candidates.

If there are more or less than 6 people in the group, the process can still be
followed, but the number of rounds and the number of ideas will be different.
See also
Development Reference: Brainstorming (11.5), Theory of Inventive Problem Solving
(TRIZ) (11.66), SCAMPER (11.58).
237
CD
SSE
Six people each generate three ideas/concepts/solutions and pass to the remaining five people for refinement. Method 635
238
OD
CD
11.36 Mind Maps
Organize your thoughts to create new connections
Further Reading
Mind maps are visual representations of relationships between ideas. They are used Tony Buzan, who is credited
to clarify thinking and to trigger new ideas. In product development, they are useful as the inventor of mind
when creating concepts because they help increase the variety and novelty of the maps, has a website about
concepts developed. mind mapping:
http://www.tonybuzan.com/
about/mind-mapping/
Key methods
Buzan suggests that mind maps be done on paper, by hand. A number of software
tools have been developed to create mind maps. This reference focuses on
hand-drawn mind maps.
A mind map is created by starting with a blank piece of paper. Buzan suggests that
ledger (11 inch x 17 inch) paper is preferable, because it allows plenty of space. It is
recommended that color pencils or pens be available to make mind maps, because
the colors will provide additional stimuli for the brain.
In the center of the blank piece of paper, a key word that summarizes the goal of the
mind map is written, along with some kind of drawing that captures the essence of
the key word. Words that are related to the key word are then written along lines that
extend radially out from the center. The lines should be curved, rather than straight,
Mind Maps
according to the accepted wisdom of mind mapping. The lines should be different
colors, and can taper, like tree branches.
For each of the related words, additional sub-words are created, fanning out like tree
branches. Images can be added to key words. Words should be placed near related
ideas. Sometimes there will be links between different branches. These can be
indicated with dashed lines.
As the page fills up, you will capture a variety of thoughts related to the key idea.
Some of the thoughts will have little direct value to your development project, but it is
hoped that many will be useful.
The branches you develop on a mind map may prove helpful in developing concept
classification trees and concept combination tables. They may also be helpful in
decomposing the problem.
Applicability
Mind mapping is useful any time you want to create lots of ideas. It will often be
used in the concept development stage.
Mind maps can be used when trying to find a way to solve seemingly intractable
problems at any stage of development.
See also
Development Reference: Brainstorming (11.5), Method 635 (11.35),
SCAMPER (11.58), Theory of Inventive Problem Solving (TRIZ) (11.66).
239
OD
CD
Mind map of guidelines for creating mind maps. After an image by Nicoguaro. Mind Maps
240
OD
CD
11.37 Multivoting
Quickly select a few good alternatives
Further Reading
Multivoting is a technique used by teams to perform a quick, intuitive selection of a A brief handout of a
few promising alternatives from a list of dozens of candidates. Although the formalized multivoting
evaluation is subjective, the use of many individual voters makes the process robust. system has been published
Multivoting does an excellent job of capturing the collective feeling about the by the University of Kentucky
alternatives. at http://psd.ca.uky.edu/files/
multivot.pdf
Multivoting can be used any time, there is a need to select a few items from a much
larger list. It is particularly useful to select a manageable number of concepts for
more detailed evaluation during concept development.
It is reasonable for a multivoting session to take less than an hour to reduce the
concept set from 50 or more to 10 or less.
How to do it
1. Post a representation of all of the candidate ideas where they are visible to all
team members. This is often done on a whiteboard or a wall.
2. Give each team member a fixed number of votes, generally between 5 and 15
votes per person. This can be done with stickers, adhesive notes, or just using
Multivoting
the honor system and having members mark a vote with a pen.
3. Without talking, each team member votes for their preferred ideas by placing
the stickers or marks on the representations, where all members can see them.
Members should vote for concepts they want to carry forward. Members are
not limited to one vote per concept; they may place all their votes on one
concept if they so desire. The voting process is open, so members can watch
the progress as they place their votes and adjust their voting as desired.
4. Count the votes for each of the candidate ideas. Those with few votes are
eliminated. Those with high vote counts are carried forward. Those with low
vote counts are dropped. If in doubt, it’s probably best to carry a borderline
idea forward.
5. If there are still too many concepts to move to the next decision stage, pursue
another round of multivoting with fewer votes for each person.
In most cases, the goal of multivoting is to reduce the concept list to between six and
fifteen concepts.
Applicability
Multivoting is done throughout product development as a means of quickly
converging on a small set of ideas. At a minimum, multivoting is usually applied in
the Concept Development stage.
See also
Development Reference: Scoring Matrix (11.59), Screening Matrix (11.60).
241
OD
CD
Multivoting
The results of multivoting for a set of concepts.
242
OD
11.38 Nucor’s Circles

Find market opportunities that match your skills and
passions Further Reading
Collins JC (2001) Good to
Nucor’s Circles can be used to systematically identify high-potential opportunities to great. Random House, New
York.
pursue. Opportunities that lie at the intersection of (i) things we are passionate
about, (ii) things we can be the best at, and (iii) things the market wants to have
great potential.
How to do it
1. Choose one of the three sets: (i) things we are passionate about, (ii) things we
can be the best at, and (iii) things the market wants. Make a somewhat large list of
items for that set. For example, assume we choose the set things we are passionate
about. The large list we create might include:
• High tech products
• Camping
• Phenomenal product design
• Helping people in need
• Materials
Nucor’s Circles
• Creating things in my shop

• Reading
2. Now choose another of the three sets and make a list while considering the
already completed list. For example, make a list of things we can be the best at
while considering things we are passionate about.
• Phenomenal product design
• Materials
• Hard work and dedication
3. Make a list for the remaining set. For this example, things the market wants. Do
this in the context of the other lists.
• High tech products
4. Identify the items (if there are any) that exist in all three circles. These represent
the opportunities of greatest potential.
Why it’s named after nucor

Nucor Steel is considered to be one of the great Fortune 500 companies in an
impressive study carried out by economist Jim Collins. Nucor significantly
outperformed its competition in the stock market over a sustained period of time.
When attempting to discover what distinguished Nucor from its competitors, Collins
discovered that Nucor made all of its decisions in accordance with the overlapped
section of three circles: passion, expertise, and economic denominators.
For Nucor the circles looked like: “Passion for eliminating class distinctions and
creating an egalitarian meritocracy that aligns management, labor, and financial
interests. Economic Denominator of profit per ton of finished steel. And could
become the best in the world at harnessing culture and technology to produce
low-cost steel.”
243
OD
See also
Development Reference: Project Objective Statement (11.49)
Chapter 4 of this book.
PURSUE
OPPORTUNITIES
IN THIS AREA
What our
PASSIONS are
Nucor’s Circles
What our What the
SKILLS are MARKET wants
Nucor’s Circles
244
OD
CD
11.39 Objective Tree
Determine the importance of multiple design objectives
The objective tree is a visual representation of the project or product objectives. It is

a useful way to systematically establish weights that can be used in a scoring matrix.
How to create an objective tree

Consider the figure on the opposite page in the context of a horn design for a car.
1. Establish the top-level objective: This objective, labeled O1, is to have a good
horn design. This is the top-level objective, so its overall weight (placed in the
bottom right portion of the circle) in the objective tree is 1.00, obviously. Its
weight relative to the objective one level up in the tree (termed relative weight,
and placed in the bottom left part of the circle) is also 1.00 because there is no
level higher than this top-level objective for this example.
2. Decompose the top-level objective into sub-objectives: For the horn example,
we see three sub-objectives: Have good sound quality, have good functional
quality, and have good manufacturability. Each is labeled for convenience
(O11, O12, O13).
3. Assign relative weights to each sub-objective in the level (in this case the
Objective Tree
middle level of the tree): These weights are numbers between 0 and 1, and
they sum to 1. They occupy the bottom left portion of the circles.
4. Calculate the overall weight of each sub-objective by multiplying the respective
weight in this level, by the overall weight in the level above. For this example,
the respective weight for O11 (0.30) is multiplied by the overall weight for O1
(1.00) to produce the overall weight of O11 (0.30).
5. Decompose mid-level objectives into sub-objectives.
6. Repeat previous two steps until decomposing further has no value to the
project.
See also
Development Reference: Decomposition (11.14), Scoring Matrix (11.59).
245
OD
CD
01: A Good Horn Design
01
Relative Weight 1.00 1.00 Overall Weight
011: Sound Quality 012: Functional Quality 013: Manufacturability
011 012 013

0.30 0.30 0.30 0.30 0.40 0.40
0111 0112 0121 0122 0123 0131 0132 0133 0134
Objective Tree
0.60 0.18 0.40 0.12 0.20 0.06 0.70 0.21 0.10 0.21 0.12 0.05 0.15 0.06 0.08 0.03 0.65 0.26
0111: Ease of Achieving Volume 0121: Resistance to Temperature 0131: Weight

0112: Ease of Achieving 0122: Response Time 0132: Size
Frequency 0123: Power Consumption 0133: Number of Parts
0134: Cost to Manufacture
An objective tree for a horn design problem.

246
OD
CD
11.40 Observational Studies
Learn users’ needs by watching their actions
Further Reading
Observational studies are one of the best ways to understand what people actually Lofland J, Snow D, Anderson
do in real contexts and time frames. What people actually do, and what they say L, Lofland LH (2006)
they do are almost always different. For this reason, observational studies can be Analyzing social settings: a
very valuable when trying to establish information that will guide the development guide to qualitative
process. An ethnography is a description of the customs of individual peoples and observation and analysis.
Wadsworth. See especially
cultures; it is a natural artifact that emerges from observational studies. For example, Ch. 3 – Getting In and Ch. 5
having observed engineering students, we could say “Engineering students carry a – Logging Data.
scientific calculator in their backpacks. Most carry an extra set of batteries.”
When designing products or services, we’re interested in the meaning of activities
and artifacts. We look for habits and rituals, and we keep an eye out for
unanticipated issues and behavior.
Observational studies are most important because they help us ask “Why.” Why do
they carry the calculator in their backpack, and not on their wrist, or as a piece of
software in their computer? Understanding why people do what they do helps
designers to create objects that enhance lives without necessarily changing behavior.
Social science and anthropology are the disciplines typically trained in rigorous
observational studies.
Four observational study techniques

IDEO, a leading product development firm, produced a description of useful
observational techniques (Ideo, 2003), a few of which are summarized here.
Rapid ethnography
Develop a relationship of trust with people relevant to the design topic. Do this by
spending time together. Establish a relationship that allows you to visit and/or
participate in the specific activities in the natural environment. This is termed a
rapid ethnography because anthropologists often do non-rapid ethnographies that
take years to complete.
Fly on the wall

Observe and record the behavior of people relevant to the design topic within their
natural environment. Do this observation and recording without interfering with
people’s activities.
Behavioral archeology
Observe wear pattern, the organization and placement of things, and homemade
solutions to problems. These are evidences of daily life, patterns of living, and
patterns of thinking.
A day in the life

Observe users’ behavior throughout an entire day. Record their activities and the
context. Analyze the findings to discover patterns of behavior that only emerge over
a sizable length of time.
247
OD
CD
See also
Development Reference: Interviews (11.34).
Observing users in their native environment is a great way of understanding market needs, including unstated
needs.
248
OD
CD
11.41 One Pager
SSE Convey design decisions or key findings in a brief format
Product development teams create a substantial amount of information during the

SR
development process. It is important to recognize that although valuable, not all of
that information play a key role in the development process. Key information should
be preserved in a carefully prepared document and shared with the development
PR team and others.
An extremely effective practice is to condense the key information into a single-sheet
document that conveys the information in a clear and accurate way. We call these
PRR documents one pagers.
Principles motivating the use of one pagers

• A condensed description of your work and its outcome is more likely to get
noticed and shared than the full description of the work. Simply stated:
supervisors want you to share your message concisely.
• Once a condensed version of your work is noticed and appreciated, others will
be more likely to engage the full description of the work.
• When the condensed version of your work has no substance or detail to back it
One Pager
up, it has no value.
• Selective use of one pagers raises their stature, which ultimately allows you to
share your most important messages effectively. Overuse of one pagers
relegates them to more unread paperwork.
Characteristics of good one pagers

• One pagers are short. If a “one pager” needs a staple, it’s not a one pager.
• One pagers are navigable. Headings make it immediately obvious to the reader
what the core sections in the one pager are.
• One pagers are meaningful. They contain information others want to know.
This is different than simply containing information you want to share.
• One pagers are correct. If one pagers are to be trusted, they need to be
absolutely 100% correct. When they are consistently correct, one pagers
become highly valued.
• One pagers are objective. They represent the facts and your clear
recommendation regarding them. They tell it as it is, without mincing words.
• One pagers are supported. Every element of the one pager could be backed up
by a more comprehensive report of your work.
Memo versus one pager

In a sense, one pagers are like memos; they convey information to others. But the
expectations for a one pager are much higher. Memos are often overused, one
pagers are not. Memos often lack the good characteristics defined above. In fact,
one pagers that do not have the characteristics listed above are simply memos, and
unfortunately get added to the list of undervalued often unread paperwork.
249
OD
CD
SSE
Succinct Text
SR
PR
PRR
Meaningful
Content
One Pager
Pertinent Navigation
Clear Technical Images
An example of a one pager used to quickly convey proposed design changes. Once the basic
message was understood and appreciated, the proposal was approved and a formal change
to the design documents (engineering drawings, bill of materials, etc.) and the tooling was
initiated.
250
11.42 Optimization
SSE Get the most performance out of your product
Further Reading
Numerical optimization is a popular tool for computationally finding the highest Messac A, (2015)
SR
performing designs. Importantly, optimization techniques not only tell you the best Optimization in practice with
performance that can be achieved, but also the design that achieves it. Matlab. Cambridge Press.
Optimization requires a mathematical model of the design’s performance as a For multiobjective

function of the design variables and parameters. Generally these models are not optimization: Balling, RW
available until after the concept development stage. Therefore numerical (1999) Design by shopping:
A new paradigm?.
optimization is typically used during subsystem engineering. By the time models are WCMSO-3.
PRR good enough to be used in an optimization setting, roughly 5-10% performance
improvement can be gained. Messac A, Ismail-Yahay A,
Mattson CA (2003) The
normalized normal constraint
The key to successful optimization: the problem formulation method for generating the
Pareto frontier. Struct
Formulating the problem is by far the most important part of numerical optimization. Multidiscip O 25(2).
The principle behind this is that the computer will search for exactly what you tell it
to search for – even if it looks for unrealistic or physically impossible design features
such as beams with negative lengths or holes that are bigger than the part it is
supposed to be drilled into. A well-developed formulation makes the search
meaningful.
Optimization
Once a correct problem formulation has been made, virtually any solver, using any
algorithm will result in performance improvements. A problem formulation looks like
this:
min µ(x, p)
x
subject to g(x, p) ≤ 0
h(x, p) = 0
xlower ≤ x ≤ xupper
where x represents the design variables, and µ(x, p) represents the design
objectives, which are functions of variables (x, things the optimizer will change) and
fixed parameters (p, things the designer chooses but does not let the optimizer
change). The computational search for the variables that optimize the objectives will
most often be subject to constraints on the search. These are represented by
inequality constraints (g(x, p)), equality constraints (h(x, p)), and side constraints
on the variables (xlower and xupper ), which are simply the limits defining the
acceptable variable values. It is useful to note that x, µ, g, h, xlower , and xupper can
be scalars (when representing only one thing) or vectors (when representing
multiple things).
As with any mathematical representation, it is valuable to understand what it
represents in plain language. The generic formulation above says: find the values of
the variables x that minimize the objective function µ, subject to inequality
constraints, equality constraints, and side constraints on the variables.
How to create and solve the problem formulation

1. Choose design objectives. For example, minimize beam deflection or minimize
stress. It is common to express them all as minimization statements, though
this is not necessary. To maximize the objective function using the form above,
251
simply minimize the negative value of the objective function (i.e., min −µ), or
to reach a target simply minimize the squared difference between the optimal
design and the target design (i.e., min(µtarget − µ)2 ).
SSE
2. Choose design variables (x) that the optimizer will change. For example, the
lengths, widths, and heights of a beam. Also choose the fixed parameters that
the optimizer won’t change. For example, Young’s Modulus.
3. Identify and set the constraints of the problem. For example, the beam SR
bending stress (σbending ) must be less than the yield strength (Sy ). Many
optimizers expect to see constraints in a certain form such as the one shown
above (g ≤ 0). For the beam stress constraint simply move the terms around;
σbending ≤ Sy can be expressed as σbending − Sy ≤ 0. Also establish the
upper and lower acceptable limits for the variables (x).
4. Choose and use one of many search algorithms. Choices include (i)
gradient-based optimization algorithms, (ii) heuristic methods such as genetic PRR
algorithms, or (iii) brute force optimization methods. A simple internet search
for these terms will lead to valuable information.
5. Evaluate the optimization results to see if a meaningful result was achieved.
Adjust the problem formulation as needed to be more meaningful and repeat
these steps.
Single objective versus multiobjective optimization

When there is only one objective (µ1 ) in the problem formulation, a single optimal
design results. On the other hand when there are multiple competing objectives (µ1 ,
Optimization
µ2 , ..., µn ,), a set of optimal designs results. The set defines the optimal trade-off
curve between the competing objectives. This curve is called the Pareto frontier and
it contains designs that can only be improved in one objective by giving up in
another objective.
See also
Development Reference: Robust Design (11.57), Sensitivity Analysis (11.61),
Uncertainty Analysis (11.68).
Objective (µ1 )
Objective 2 (µ2)
6 6
5 5
µ(x)
4 4 Feasible Design Space

Optimal
Design
3 3
(Global)
Optimal
2 2
Design
(Local)
1 1
Set of
0 0
Pareto Solutions
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
Variable (x) Objective 1 (µ1)
Optimal solutions for single objective problems (left side) and multiobjective problems (right
side).
252
OD
CD
11.43 Patent Searches
SSE Find creative solutions others have found for similar
problems Further Reading
Google has a very flexible
Patents provide an excellent source of creative ideas for solving challenging and powerful patent search
capability: http:
problems. They also provide information about designing products to avoid //www.google.com/?tbm=pts
infringement.
Five different uses for patent
Patent searches are used as one way to find out what has been done relating to the searches in product
product being developed. During early stages of development, patents are searched development are identified
to find benchmark concepts and inspire creativity. During later stages of here: http://ip-updates.
development, patents may be searched to avoid infringement of existing patents and blogspot.com/2004/07/
patent-searching-in-product.
to determine whether a new idea is patentable.
html
Key methods
Google Patents is an excellent online tool for searching patents. It allows searching
by patent number, by classification, by issue date, by inventor, and by keywords in
the patent title, abstract, and body. The results of the search are available for
download as .pdf files.
Patent Searches
A general strategy for doing a patent search is to use keywords to find relevant
patents. Once relevant patents have been identified, there are three ways to expand
your search. First, you can find all the patents that are cited as prior art in the patent
you found. Second, you can find all the patents that cite your patent as prior art.
Third, you can search the classifications of your patent.
As you search using these methods, the number of patents obtained will quickly
expand. You will need to develop a skill at quickly examining the abstract, images,
and claims to see which patents are relevant to your development project.
You should recognize that expired patents can provide sources of ideas as readily as
current patents. Furthermore, expired patents can form the basis of prior art that
can help you avoid infringing current patents.
Applicability
Patent searching is useful in the concept development stage, both as a way to see
how others have solved your same problem and as a way to expand your
understanding of related problems.
The presence of a valid patent in your development area does not mean your project
is doomed. You may be able to develop means of avoiding patent infringement.
Alternatively, you may be able to license the patent with which you are concerned.
See also
Development Reference: Internet Research (11.33).
253
OD
CD
SSE
Patent Searches
Image from US Patent 6663117 B2, which resulted from the work of a Capstone team
at BYU.
254
OD
11.44 Performance Measures

Measure how well your product meets the user’S needs
The market requirements represent the things the development team has found out
that the market wants in the product. As the team is not the market, the team
cannot make a direct judgment about the desirability of the product. The team must
develop measurable characteristics of the product that can be predicted and
measured by the team throughout the product development process. These
measurable characteristics are Performance Measures.
Characteristics of performance measures

Effective performance measures share the following characteristics:
1. Concept independent:
2. Unambiguous (even if subjective):
3. Related to market requirements:
4. Dependent, rather than independent:

5. Appropriate units:
6. Minimize use of yes/no:
How to do it
The following activities can be helpful as you develop an appropriate set of
1. Review customer statements.

2. Ask yourself how you could measure each of the market requirements.
3. Imagine how you would measure the performance of two different products to
determine which was best.
4. Search for often-used decision criteria for similar products on the market.
Applicability
Performance measures are developed primarily during opportunity development.
Ideal values for performance measures for the system are identified during
opportunity development. Ideal values for subsystems, and target values for the
system and subsystems are identified during concept development. Measured and
predicted values are obtained during subsystem engineering and the product
refinement stages.
Performance measures may evolve throughout the design process. Changes in the
performance measures should be tracked with the ECO process.
See also
Development Reference: Requirements Hierarchy (11.54), Requirements
Matrix (11.55).
255
OD
OPPORTUNITY CONCEPT SUBSYSTEM SYSTEM

DEVELOPMENT DEVELOPMENT ENGINEERING REFINEMENT
Assess
System System System

Ideal Target Predicted
Assess
Subsystem Subsystem Subsystem

Ideal Target Predicted
Subsystem System
Measured Measured
Assess
Assess
Real values for the performance measures evolve during product development. Target values
for systems and subsystems are identified during concept development. Predicted values for
the system, and measured and predicted values for subsystems, are obtained during subsys-
tem engineering, and are assessed by comparing with the appropriate target values. During
system refinement, measured values for the system are obtained and compared with the tar-
gets. As the design continues to evolve, measured and/or predicted values will likely change
as well. Each time they change, they should be compared with the target.
256
OD
CD
11.45 Personas and Locales
Understand and teach others about who your product serves
Further Reading
Personas are archetypes of the people – often end users – who will be affected by van Boeijen A, Dallhuizen J,
the product you’re developing. They’re thoughtfully developed by the product Zijlstra J, van der Schoor R
development team to better understand who the product serves, and to teach other (2014) Delft Design Guide
decision makers about those people. Effective use of personas helps the team BIS Publishers. pp. 94-95.
abandon the idea that their product will serve 100% of the population, helps them Hanington B, Martin B.
focus on who the product does serve, and when used during the decision-making (2012) Universal methods of
process, helps teams create products that are truly loved by the market. design: 100 ways to research
complex problems, develop
innovative ideas, and design
How to create a persona effective solutions. Rockport
Publishers. pp. 132-133.
1. Establish the objective of your product development effort (see Project
Objective Statement). This is an important first step because personas need to
be developed for your specific project and its objectives.
2. Considering the project objective, decide which general part of the population
is served by your product (e.g., people with difficulty sleeping).
Personas and Locales
3. Discover as much as you can about the general part of the population your
product serves. While doing this, begin noticing and further researching the
characteristics that are pertinent to your product. Various sources are available
such as online databases, social media analytics, web analytics, and more.
4. Look for trends in the data that allow you to start dividing your part of the
population into primary and secondary users and other pertinent stakeholders.
5. Develop 3 to 5 believable personas:
• Give each persona a name

• Choose a photograph to represent the persona
• State the role of the persona (e.g., primary user, maintenance worker)
• Develop a description of the persona including their desires, needs,
expectations, motivations
6. Evaluate the persona and revise as needed.
How to use personas to advance the design

Develop and use believable personas early in the product development process to
help team members be human-centered during the development. Post the persona
description on the wall of the team space. Refer to it often. Use a persona during a
team meeting and see how it changes the discussion from that of product to that of
who the product serves. This can be particularly useful when team decision-making
digresses to a struggle between what one team member wants versus another.
Personas help teams shift back to what the end user would want.
Persona pitfalls to avoid

To be useful, personas need to be accurately developed. They cannot be based on
team member opinions about who the end user might be or based on unvalidated
assumptions. Personas need to be believable before they can become something
the team rallies around.
257
OD
CD
Locales
When the location where the product will be used is crucial to the product design, a
locale can be developed. The locale is a description similar to a persona, but it
focuses on a real or representative location. It has the same product development
objectives as a persona, but with a focus on location and context for product use.
The use and pitfalls of locales are the same as personas.
See also
Development Reference: Project Objective Statement (11.49), Storyboards (11.64).
Persona
representing a
shopkeeper in
Puno, Peru.
Personas and Locales
Locale
describing
Puno, Peru.
258
11.46 Plan Do Check Act (Shewhart

Cycle)
Further Reading
Formalize the improvement of product quality Langley GJ, Moen R, Nolan
KM, Nolan TW, Norman CL,
Plan Do Check Act (PDCA) describes the four parts of the Shewhart Cycle for Provost LP (2009) The
improvement guide: a
statistical quality improvement. PDCA is used to improve the performance of practical approach to
PR repetitive processes, such as product manufacturing. It can also be used to improve enhancing organizational
the design of products. performance, 2nd ed.
Jossey-Bass, San Francisco.
The four steps in the Shewhart cycle are Plan, Do, Check (or Study), and Act. They
PRR describe a series of steps necessary to verify and formalize improvements in A classic guide to
processes. improvement using
Plan-Do-Study-Act.
How to do it
Plan Do Check Act (Shewhart Cycle)
First, identify a focus for the cycle, which is generally aimed at improving a product
or process. The plan step of the cycle requires developing a hypothesis about how
the process could be improved and planning an experiment to prove or disprove the
hypothesis. The hypothesis should be written clearly, and should include
measurable terms that can be evaluated during the check step. The plan for the
experiment can be simple or complex. The experiment can be one that will take a
few minutes or several weeks. The important thing is to plan the experiment before
performing it, so that you can be sure the experiment will address your hypothesis.
The second step, do, requires carrying out the experiment that was planned in the
first step. It seems so obvious that some people wonder why it needs a separate step
all its own. But many times a company or individual will never finish an experiment
they start because of external pressure, or a perception that other things are more
urgent, or because initial results seem so promising that there is no need for further
testing, or even because it’s just “common sense.” However, only through carrying
out the full experiment as planned can the hypothesis be appropriately resolved.
The third step, check (or study), requires analyzing the results of the do step.
Statistical methods should generally be used, in order to assess whether the
changes (if any) observed are likely to be real, or just the result of randomness.
Furthermore, it is desirable to study the results of the experiment deeply, as they can
suggest ideas for future experiments in later PDCA cycles.
The fourth step, act, requires taking action on the system being studied that is
consistent with the results of the study. If the study shows that the suggested
changes make a significant improvement, the system must be adjusted so that the
changes will be consistently implemented in the future. If the study shows that the
suggested changes have no effect or make things worse, the results are
documented so they can be transferred to others.
The cycle is then repeated by moving to the plan step for another potential
improvement. In this way, the system is continuously improved.
Applicability
PDCA is most often used during the sustaining stage of product development.
See also
Development Reference: Design of Experiments (11.18).
259
PR
Plan an experiment to
see if your idea will PRR
improve the situation
PLAN
Plan Do Check Act (Shewhart Cycle)

Either:
Implement and
standardize the
new methods Carry out the
Or: ACT DO experiment following
your plan
Document the
unsuccessful
result and
try again
CHECK
Analyze the results of the

experiment to see if the
situation has improved
The PDCA Cycle.

260
OD
CD
11.47 Planning Canvas
SSE Develop plans that cover all the bases
Planning is a fundamental part of every stage of product development. It’s carried

SR
out at various degrees of formality, from detailed complex planning that involves
many people, to the subconscious planning that occurs naturally in a designer’s
mind. No matter the case, five basic pieces of information are needed to create a
PR good plan. These are shown as bold headings in the example canvas on the next
page. The canvas is designed to help you cover your bases while planning.
A good test is to pause from your design work and fill in each of the areas of canvas.
PRR If you can confidently fill in the areas, you’re right to be doing design work. If you
cannot confidently fill in the areas, you’ve started your design work prematurely.
Your time will be better spent planning so as to make sure your design work will
produce a valuable outcome.
How to do it
First, scope the project, sub-project, or task. To do this:
1. Discover and state the objective of the project, sub-project, or task.
2. Discover and state the starting point for the project and the ending point you
Planning Canvas
hope to get to.

Second, find out what enables and limits success. To do this:
3. Discover and state the resources that are available to you to accomplish the
objective.
4. Discover and state the constraints that limit the project, sub-project, or task.
Third, choose actions that make good use of resources and respect constraints to
meet the objective.
5. Establish and list one or more actions that would be needed to transition from
the starting point to the ending point. When a team member is assigned to do
or lead the action and important dates are added to the list, then a plan has
been created.
Fourth, evaluate the completeness and accuracy of the information in the canvas,
and the quality of the plan. Refine and update as needed.
Why it’s called a canvas (and not a template)

Canvases are popular in business management. They are tools to visualize and
assess a changing plan (such as a business plan or a business model). They are
much more than a template. They are a working board. The name Canvas implies
change and iteration, which is exactly what you’ll need when it comes to planning.
You’ll need an initial plan based on the best information you have at the beginning.
Then as more information is gained, you’ll need to update that plan. Doing those
updates directly on a canvas, or at least in the language and form of a canvas, will
help the team see the plan is becoming more and more refined, as opposed to being
frustrated that there always appears to be a new plan.
See also
Development Reference: Critical Path Analysis (11.13), Plan Do Check Act
(Shewhart Cycle) (11.46), Value Engineering (11.69).
261
OD
CD
Revision: Jan 4, R2 SSE
1 Objective
Prepare for and drill a 4 foot borehole in cobblestone. Simulate real conditions.
SR
2 Starting Point
Jan 4, we have a working system that was used to create a two foot hole in clay soil with PR
no rocks. The slurry pump is inadequate, and we have no way to extract drill pipe yet.
PRR
3 Resources Key Actions,

Dates, and Responsibilties 5
• $500 for prototyping
• By Jan 10, Schedule the dig time with team
• 110 man hours for design and build and sponsor (Nathan)
• 32 man hours for the drilling day • By Jan 15, Secure a place to drill (Elena)
• Relationship with landowner that may • By Jan 20, Get gas company clearance (Elena)
let us dig on his property • By Jan 20, Design a structure to extract pipe
Planning Canvas
• Project sponsor availability (to bring (whole team, led by Colleen)
realistic evaluation to the drilling day) • By Jan 26, Build a structure to extract pipe
• Tools, computing, etc (Colleen, Nathan, and Eric)
• By Jan 26, Build an additional pump that
can be used in series with existing pump
(Jason and Sabin)
• On Day of Dig, Gather the needed equipment
4 Constraints (Elena)
• On Day of Dig, Perform the dig
(Whole team, minus Sabin)
• Must get approval from gas company
• On Day of Dig, Collect data during the dig
• Must dig on a Saturday, because of (Nathan and Chris)
• 3 Days after Dig, Compile & analyze the data

• Need to use human power only
(Nathan)
• 3 Days after Dig, have a team de-brief on
what was learned at the dig (Whole team,
led by Elena)
Ending Point
By Jan 30, we want to have a working system that sucessfully cuts through four feet
of soil with cobble stones. Where we simulated real consditions for slurry pumping
and pipe extraction
Planning Canvas for a small portion of the Human-Powered Well Drilling Machine project.
262
OD
CD
11.48 Product-Focused Requirement
Statements
Obtain high-quality statements of product requirements
Product-focused requirement statements are requirement statements derived from

user statements about the product that have been rewritten to be of most use in the
product development process.
How to do it
To create a product-focused requirement statement, we begin with a statement from
a user about what would be desirable in a product. The user statement is then
rewritten so its expression has the following attributes:
Product-Focused Requirement Statements
Positive, not negative, phrasing: Sometimes the user will say what they want the
product not to be or do. Rather than capturing what would be undesirable in
the product, it is more effective to express positive characteristics of a desirable
product.
As specific as the user statement: It is important to capture the user’s intent as
faithfully as possible. Teams will want to generalize user statements, but the
generalization should happen later, after related requirement statements have
been grouped.
A requirement of the product, not the environment or the user: Some user
statements will be expressed in the form of statements about the environment,
rather than about the product. Since the team is focusing on designing the
product, requirements should be expressed for the product.
A requirement, rather than a performance measure: Users will often make
statements that define performance measures and desired values of the
measure. These performance measures should certainly be captured in the
requirements matrix. However, the user-stated desired value is only one data
point, and should generally be used to help define the ideal values, rather than
being used as the ideal value. Furthermore, the team will learn much more
about the requirements if the user is asked why the performance measure is
important to the user. Often one or more requirements will be discovered by
probing the reasons for stated performance measures.
A requirement, rather than a product feature: Users who have thought carefully
about products will often have specific suggestions about ways to achieve
desired performance. When user statements suggest specific features, it is
more helpful to the design team to identify the requirements behind the
suggested feature. By doing this, the team is free to consider other ways to
meet the requirement, which may be more effective than the user’s suggestion.
Independent of importance: As users express opinions about the product, they
often include statements about the importance of various requirements,
features, and performance measures. These statements of importance are
valuable and should be captured by the team. The requirements matrix has
entries for the importance of both requirements and performance measures.
User statements of importance should be considered as the team determines
relative importance of the requirements, rather than be directly included in the
product-focused requirement statements.
See also
Development Reference: Requirements Hierarchy (11.54).
263
OD
CD
Sample requirement statements created from customer statements about a cord-

less circular saw. These statements illustrate the six guidelines of effective product-
focused requirement statements.
Guideline Customer Statement Good Requirement Statement Inferior Requirement

Statement
Express the requirement with It just doesn’t have the torque The saw resists binding when The saw doesn’t bind when
positive, not negative, of a corded saw and will cutting plywood. cutting plywood.
phrasing choke in a slight bind while
cutting plywood sheets.
Express the requirement as I wish it had a case to protect The saw is resistant to dents The saw is rugged
specifically as the user it from dents and dings and dings
Product-Focused Requirement Statements

statement
Express the requirement as a The trigger safety interlock is The saw can be started easily People can easily reach the
requirement of the product, aggravating! I have incredibly by most people, even with safety interlock.
not the environment or the large hands and still find the safety interlock features
user trigger interlock a stretch to active.
reach.
Express a requirement, rather The battery lasts for three The battery lasts a long time. The battery lasts for three
than a performance measure hours of typical carpentry Or the battery life allows hours.
work. typical carpentry work.
Express a requirement, rather Having the blade on the left The saw provides clear sight The saw has the blade on the
than a product feature side gives a right-handed user to the cut. left side.
a great line of sight.
Express the requirement The saw does not have a light The saw illuminates the cut The saw should illuminate the
independent from its which I miss. area. cut area. Or the saw must
importance illuminate the cut area.
264
OD
11.49 Project Objective Statement

Explain your project objective in 25 words or less
A project objective statement is a clear and concise articulation of the project and its
goals. It is an overarching mission statement and while simple, it is a powerful way
of uniting a team. When the details of the project become overwhelming, the project
objective statement serves as a firm mission the team has agreed to.
Characteristics of a good project objective statement

• Clear: The statement should be unambiguous about what will be done, when it
will be completed, and how much it will cost (in resources) to do it. It should
be written in a language that can be understood by all people interested in the
outcome of the project.
• Concise: The statement should be short, approximately 25 words. As such, it
should describe only the top-level scope, schedule, and resources. The
conciseness of the statement is not easy to achieve, but this requirement forces
Project Objective Statement
the team to articulate the essence of the project with carefully chosen words.
• Informed: The statement is constructed based on information learned from the
client or other stakeholders. It is not formed by the team in isolation.
• Validated: The finished statement is validated by the client or other
stakeholders.
• Unifying: The finished, validated, project objective statement unites the team.
How to make and use a project objective statement

Prepare a project objective statement early. Do this as one of the first actions taken
at the beginning of a project. It will help the team understand what is required, and
it will help the client clarify in his/her own mind what is wanted. One team member,
typically a team leader, drives the effort to create the statement. The driver seeks
feedback as appropriate from the client and other team members until a final project
objective statement is converged upon.
The project objective statement has little lasting impact if it is not frequently referred
to and updated as necessary.
Example project objective statements

For a human-powered water well drill:
Design, build, and test a human-powered drill that reaches underground potable
water at depths of 250 ft in all soil types by March 25, 2011 with a prototyping
budget of $2,800 USD and for less than 1,700 man hours of development.
For a manufacturing process that makes medical devices:
Design and demonstrate a repeatable manufacturing process for a continuous-wire

cannula to reduce variability and increase overall output within existing product
specifications by March 31st, 2010 for under $1,200.
For a machine used to direct the RF beam of a military communication systems:

Design and build a functional prototype control system and housing to actuate
dielectric wedges and steer an RF beam with a budget of $3,500 by April 8, 2009.
265
OD
See also
Chapter 4 of this book.
Scope
Schedule
Project Objective Statement

Resources Scope
(needed)
Schedule
Resources
(needed)
The project objective statement defines the triple constraint of scope, schedule, and
resources for the project. Assuming the vertices must stay connected, this image
shows that when one item (scope, schedule, or resources) expands or contracts, at
least one other must also expand or contract.
266
OD
CD
11.50 Prototyping
SSE Advance your design by building and testing prototypes
Further Reading
Prototyping is the act of physically constructing an approximation of a product or Stanford d.school’s “Open
SR
part of a product. It is a powerful way to learn and communicate during the product vs. Closed Prototypes” which
development process. As expressed by well-known design engineer David Kelley “If focuses on getting feedback
a picture is worth a thousand words, a prototype is worth a million.” Prototypes are from prototypes, available at:
PR valuable because they capture physical phenomena that we often don’t yet know dschool.stanford.edu/blog/
2011/02/28/
how to model, or don’t have time to model. open-vs-closed-prototypes/.
“Prototype to Test” which

PRR Types of prototypes focuses on using prototypes
to answer specific questions,
Physical prototypes exist in many many forms. Some can be made very quickly and available at dschool.stanford.
are rough approximations of a product, while others can take longer and be very edu/wp-content/themes/
good approximations of a product. Here is a description of a few types of prototypes. dschool/method-cards/
prototype-to-test.pdf.
Rough Mock-up: Created by taping, gluing, or otherwise holding/arranging existing
objects together to explore or communicate an idea, a rough mock-up can be
extremely useful when coupled with brainstorming activities. It usually takes
seconds to minutes to create rough mock-ups.
Cardboard Prototype: Created by cutting, folding, or otherwise manipulating
cardboard or foam-core to build an approximation of a product, cardboard
Prototyping
prototypes are an excellent way to explore the general sizes and spatial
relationships of major product components. Typically, very useful cardboard
prototypes can be constructed in less than an hour.
Foam Looks-like Prototype: Cut, carved, or otherwise shaped from high density
urethane foam, after painting these prototypes can approximate very well the
final look and feel of a product. These prototypes can take hours to days to
create. Typically a very useful prototype can be constructed in a day.
Rapid Prototype: Created layer-by-layer on a rapid prototyping machine that uses
CAD data, these prototypes are very close to the final product geometry. If CAD
models are available, very good approximations of products can be made
within hours. Rapid prototyped parts can also be used as casting molds.
Machined Works-like Prototype: Machined on conventional or CNC machining
equipment, these prototypes often provide a robust platform for testing product
functionality. They can be made with or without CAD data. These prototypes
can take hours to days to create. If outsourcing the work, it will likely take
longer than a week to get finished parts.
Soft-tooling Prototype: Produced using production-style process (such as injection
molding) on aluminum tools, rather than typical hardened tool-steel tools,
these prototypes are nearly identical to the final product in esthetics and
function. Soft tools are created in order to allow ready modification during
initial production ramp-up. Soft tools may take several weeks to a few months,
depending on complexity.
How to do it
The value of the prototype is in what design questions it answers and how well it
does so. To that end, a plan should be made for each prototype1 pursued. The
following planning steps may prove useful:
1. Establish a purpose: Will the prototype be used for design learning? If so, what
question will the prototype help answer? Will the prototype be used to
communicate something? If so, what is it designed to communicate? 1
It may not be necessary to have this
plan for rough mock-ups.
267
OD
CD
2. Choose a target approximation level: Will the prototype be a cardboard
prototype, a soft-tooling prototype, or something in between? As long as the
prototype fulfills its purpose, the kind of prototype selected should be the one
SSE
that costs the least in terms of time and money.
3. Create a prototyping schedule: The people who design the prototype are not
always the people who make or test the prototype. To that end, it is useful to
make sure all parties involved are aware of the required schedule. The SR
schedule should be consistent with the purpose and the level of approximation.
4. Develop an experimental plan: What will be done with the prototype once it is
in hand? Developing an experimental plan helps the team understand how PR
many prototype units are needed and what tests should occur in what order.
Generally, photographing and measuring the prototypes are the first action to
be taken. Always do destructive testing after non-destructive testing (yes, PRR
teams do forget this from time to time!)
See also
Prototyping
Product development prototypes for cabinet maker’s impact driver. The swivel head allows the driver to get into
tight spots. (a) Cardboard. (b) Wood. (c) Foam. (d-e) Fused deposition modeling rapid prototypes.
268
OD
CD
11.51 Quality Function Deployment
Use the voice of the customer to improve your design
Further Reading
Quality function deployment (QFD) is a formal method for ensuring that market Chan LK, Wu ML (2002)
requirements (called the voice of the customer or VOC) are fully considered at all Quality function deployment:
levels of product development and production. The chart that is used to track the A literature review. Eur J
VOC is called the house of quality. Oper Res 143:463-498.
Key methods
QFD uses a matrix for translating customer needs from one level to another. The
top-level needs are placed on the left-hand side of the matrix and label the rows.
They are called “Whats” because they describe what is to be achieved by the
development project.
The columns of the matrix are called “Hows” because they describe how
achievement of the Whats is to be measured or ensured. At the intersection of the
rows and columns a symbol is placed indicating how the What and the How interact.
Quality Function Deployment
Interactions include three levels: weak, medium, and strong. Numerically, the three
levels should form a geometric progression; the most common values are 1, 3, and
9, respectively.
An importance rating is given for each of the Whats. This rating captures the
importance of the what to the customer.
The importance for each of the Hows is calculated from the importance of the Whats
and the interaction ratings:
X
Hk = Ijk Wj (11.11)
j=1,Nw
where Hk is the importance of the kth How, Wj is the importance of the jth What,
Nw is the number of Whats, and Ijk is the interaction between the jth What and
the kth How.
A triangular “roof” is placed above the Hows and is used to show interactions
between the Hows. Interactions between Hows can be positive, meaning that
achieving one How helps achieve the other How; or they can be negative, meaning
that achieving one How hinders achieving the other How.
Competitive benchmarking information can also be placed on the QFD matrix.
Market assessment of competitive products is placed at the right-hand side of the
matrix, with an evaluation for each of the Whats. This portion of the matrix is called
the How Wells, because it shows how well the market needs are met.
Technical assessment of competitive products is placed at the bottom of the matrix,
with the performance of the product relative to the How indicated. This section of
the matrix is called the How Muches because it is information on how much of the
Hows should be provided.
Judgment is an important part of QFD application. The matrices can become so big
that it is nearly impossible to finish them, or they can be so small that they are trivial
and provide no benefit.
See also
Development Reference: Requirements Matrix (11.55), Six Sigma (11.62).
product.
Weight
Positive
Negative
Weak Symbol
Strong Symbol
Strong Positive
How Much
Strong Negative
Medium Symbol
Date: 2/5/2006 15:32
Larger the Better
Nominal the Best
Relative Importance
Weighted Importance
Quality of product
Direction of Improvement
3
9
-1
-3
0
Smaller the Better 0
0
3
1
9
A sample of the house of quality.

Want products on-time
File: Example QFD Project BIP
Effective customer contact

Company that is open, honest,
Target program cost performance

understanding of customer needs
Produce innovative solutions that work
Proposal directive draft reviewed before RFP release
.167
.167
.167
.167
.167
.167
5
7
Proposal directive draft reviewed before RFP release Effective proposals that meet or exceed custom
needs
2
9
Price-to-win
Capture
PTW established before proposal team assembles

Business
2
7
Apply Baldrige criteria, ISO 9001, 14001 compliance Quality program management/leadership
6
3
Life cycle cost trades completed before proposal completion Cost as an independent Variable, design to cost
2
3
System-level DFSS analysis performed prior to 1st reqts review Lean product development
Quality Processes
1
7
External process initiatives piloted prior to rollout to program areas Process initiative harmonization
4
3
2+ company teams on system integ. team (at least 4trly mtgs) Corporate teamwork
5
9
50 % predictive metrics in use Effective subcontractor management
4
9
2 SLOC/hr (thru IV&V) with less than 10 defects/KSLOC Effective software development
Voice of the Company
3
1
RM Plan developed with proposal, handling approaches followed Effective risk management
Project Management
1
1
Baseline review within 30 days of ATP Effective earned value mgt. sys.
Enterprise Product Development Capabilities
3
3
Quality deployment --> function deployment --> mechanism Leverage technology
2
Vertical integration
10
All corporate entities contracted thru development stages
Technology
6
5
Pre-positioned technologies
Development
Key characteristics coupled to development plans
is clear how day-to-day operations of the production system affect the quality of the delivered
relates part characteristics to production system parameters. By means of these matrices, it
rameters. The third level relates the design parameters to part characteristics. The fourth level
to the design specifications. The second level relates the design specifications to design pa-
Four levels of QFD matrices are often created. The top-level matrix relates the market needs
269
CD
OD
Quality Function Deployment

270
CD
11.52 Rapid Prototyping
SSE Automatically build prototypes from CAD models
Rapid prototyping is also
known as 3D printing, solid
Rapid prototyping is a layer-by-layer additive manufacturing method that can be freeform fabrication, and
SR
used to quickly create prototypes from CAD data. Rapid prototyping is a relatively additive manufacturing.
inexpensive way to quickly obtain a physical object from the product definition.
Types of materials used

Rapid prototyping can be used with polymers (liquid, powder, filament), metals
(powder, thin sheets), and paper. The resulting properties are generally inferior to
the final product, but the geometry is nearly identical.
Types of machines
Rapid prototyping machines can be classified as deposition machines or
consolidation machines.
Deposition machines carefully place material and fuse it together to build up
geometry. A deposition machine has a computer controlled (x and y direction) head
that extrudes material onto a build platform that progressively lowers (z direction).
Rapid Prototyping
Undercuts are built using support material that is relatively easy to remove after the
build is complete. Machine resolution is often described as z-drop height, which is
typically 0.1 mm.
Consolidation machines use a computer controlled laser to selectively fuse material
already in a bed or bath. When the process begins, the build platform sits just below
the surface of the bed or bath. A laser solidifies or sinters the material from a thin
layer of the part. The build platform drops a small amount, and the laser builds the
new layer on top of the previous layer.
Strategies
Rapid prototyping can be used to make parts or to make tools that make parts. For
example, rapid prototyping can be used to make the back housing for a mobile
phone, or rapid prototyping can be used to create a mold of the housing. Resin can
then be poured into the mold to make a non-rapid prototyped part. Rapid
prototyped parts can also be used to create a casting mold.
Because the layer-by-layer construction method results in a part that does not have
equal strength in all directions, the build orientation is a critical decision.
How to do it
1. Create the CAD Model.
2. Convert the CAD Model to data exchange format (generally STL).
3. Slice the STL File into thin cross-sectional layers.
4. Layer-by-layer Construction.
5. Clean and post-process the part.
See also
Development Reference: Prototyping (11.50).
271
CD
SSE
SR
print head (moves in X and Y)
extrusion nozzles
support
material spool
supports
Rapid Prototyping
build platform
(moves in Z)
build
material spool
This deposition style machine is representative of Fused Deposition Modeling. The

part is built up as filament is extruded onto a build platform that progressively lowers.
laser (moves in X and Y)
laser beam
liquid or powder
lowering
platform
(moves in Z)
This consolidation machine, representative of the SLA machine, builds the part by
solidifying a photosensitive polymer liquid in a bed.
272
CD
11.53 Recombination Table
SSE Combine subconcepts to create hundreds of alternatives
Recombination tables are used to combine subfunction concepts together into

full-function (full-system) concepts. One of the table’s strengths is the large number
of full-function concepts that can emerge. While not all emerging concepts will be
feasible, the table makes it possible to explore the design space in a systematic and
likely more thorough way. The table can also facilitate concept exploration activities
as it helps the team visualize how well distributed across subfunctions the concept
exploration has been.
Parts of the recombination table

The leftmost column of the table lists the subfunctions that a product needs to meet.
These often come directly from a functional decomposition (see Decomposition). In
each row of the table, corresponding to the subfunction, concepts are listed in the
columns. It’s not necessary that an equal number of subfunction concepts be
generated for each subfunction.
Recombination Table
Example
Consider a bicycle-like device for transporting humans. The required subfunctions
are listed in the table. Now, concepts are generated for each subfunction. For
example, the first subfunction listed is power vehicle. Various concepts for meeting
this function include human power, internal combustion engine, electric motor, and
human-electric hybrid.
Facilitated by the table, the team can now perform the recombination by simply
picking a concept for one subsystem and combining it with one from all of the other
subconcepts. The team can do this by intuitively picking concepts that seem
compatible or otherwise worth exploring. Or the team can do this in an automated
way, where every possible combination is made.
The maximum number of unique combinations is the number of concepts for
subfunction one times the number of concepts for subfunction two, and so on. For
this bicycle example, there are a total of 192 full-function (full-system) concepts.
See also
Development Reference: Decomposition (11.14).
273
CD
SSE
Functions Subfunction Concepts
Power Vehicle Human Powered Gas Motor Electric Motor Human-electric

Hybrid
Suspended
Support Rider Small Seat Banana Seat Bucket Seat
Hammock
Contact Ground 1 Wheel 2 Wheels 3 Wheels 4 Wheels
Aesthetic Orange Yellow Blue
...
Recombination Table
Recombination Table for Bicycle Example.
274
OD
CD
11.54 Requirements Hierarchy
Develop a comprehensive list of market requirements
A requirements hierarchy is a list of market requirements that is organized into

groups of related requirements, with each group given a descriptive title. The
requirements hierarchy allows the design team to capture market requirements in a
way that will be very useful for guiding product development.
How to do it
The first step in developing a requirements hierarchy is to obtain input from potential
users. This can be done in several ways, including surveys, focus groups,
interviews, direct observation, and more. The user input should always be captured
in the user’s own words to the extent possible.
Next, the user statements are rewritten as product-focused requirement statements,
as described in Product-Focused Requirement Statements (11.48.)
The requirements statements are then organized. The set of product-focused
requirement statements needs further work to be of most use in product
Requirements Hierarchy
development. There may be hundreds of requirement statements in the list, which

is too many for the design team to effectively consider. Some requirements
statements will be very specific, while others will be general. For most cases, the
requirements hierarchy will be most helpful if it contains between five and twenty
requirements, all of which are at approximately the same level of generality.
The requirements statements are organized by grouping related requirements
statements, eliminating duplicates, and writing new requirement statements that
effectively summarize all of the statements in the group. These primary requirement
statements have all the attributes of the product-focused requirement statements,
except that they summarize the group of related requirements, rather than restating
each of the requirements in the group.
The primary requirements are then placed in the requirements matrix as the market
requirements.
See also
Development Reference: Product-Focused Requirement Statements (11.48),
Requirements Matrix (11.55).
275
OD
CD
Capstone students were
asked to develop a piece of
playground equipment that
would generate electricity
while students played on
it. The electricity would be
used to charge batteries
that would power LED
lanterns to provide light in
the school classrooms as
well as for doing home-
work. They developed a
merry-go-round that drove
a generator.
Requirements Hierarchy
Primary requirement Original requirement statements
Based on statements
statement from market repre-
Equipment is safe to use Equipment feels safe sentatives, a set of
Equipment prevents user from falling off or sliding out product-focused re-
Equipment feels like it will not break
Equipment prevents blistering of hands quirement statements
Equipment prevents injuries to users was developed and
Equipment reliably provides Equipment parts prevent slipping organized into a re-
electricity quirement hierarchy.
Equipment generates sufficient current and voltage to light one
classroom for an hour per hour of play The primary require-
Equipment fits on or into normal Ghanaian school ground ments were used
Equipment works well in Equipment withstands the heavy rain and dust storms of Ghana as the market re-
Ghana quirements in the
Equipment withstands many children using it at the same time
Equipment can be manufactured in Ghana requirements matrix.
Equipment challenges the Equipment allows “push it to the limit”
users
Equipment provides a competition that can last a long time
Equipment is a proving ground (prove to others)
Equipment makes the user feel powerful
Equipment gives the user an opportunity to show off
Equipment allows the user to impress him- or herself with strength
Equipment builds confidence in self (prove to self)
Equipment provides an accomplishable challenge
Equipment provides fun Equipment provides a long time of motion
motion
Equipment is big and fast
Equipment allows the user to move
Equipment moves fast
Equipment is fun and exciting Equipment looks fun to play with
Equipment is new and exciting
Equipment resembles something exciting to children in Ghana
Equipment provides a thrill for the user
Equipment allows friends to gather
Equipment holds multiple children safely
Equipment may be used Equipment may be used creatively
creatively
276
OD
CD
11.55 Requirements Matrix
SSE Capture all information about meeting the market
requirements in one place
SR
The requirements matrix is a convenient place to store the requirements in a way
that is clear, unambiguous, and easily transferable. More importantly, however, it is a
powerful tool for translating broad market requirements into specific performance
measures that are generally quantitative. To be useful, it is important that the
requirements matrix be updated frequently and used to track development progress.
Sections of the requirements matrix

There are six main sections (A–F) to the requirements matrix. Each is discussed
briefly below. The inset image in the example on the facing page indicates the
locations of A–F.
Market requirements (A)

These are the top-level requirements for the product to be successful in the market.
They are often identified/clarified by interviewing clients, end users, and experts,
Requirements Matrix
and by benchmarking and other forms of research. Market requirements are

statements about what the market wants in the product, and are often subjective.
Optionally, the relative importance of each requirement can be assigned. More
important wants have larger importance numbers. The scale used to measure
importance is generally relatively coarse.
Often, the market requirements are the primary requirements from a requirements
hierarchy.
Performance measures and units (B)

These are specific characteristics of a product that can be measured to determine
how well a product meets the market requirements. They can be thought of as how
the market requirement will be evaluated or measured. It is generally preferable to
have objective performance measures. When subjective performance measures are
necessary, they should be unambiguously evaluated. In general, there are multiple
performance measures for each market requirement. Likewise a performance
measure can often apply to multiple market requirements. The units of the
performance measure are listed next to the measures.
Optionally, the relative importance of each performance measure can be assigned.
Higher importance is indicated by larger importance numbers. In QFD, the
importance of the performance measures is calculated from the importance of the
market requirements and the requirement–measure relationships, but this is not
essential.
Requirement–measure correlations (C)

This portion of the matrix captures the correlations between market requirements
and performance measures. In the figure, a dot in a cell shows that the requirement
in the row is at least partially evaluated by the performance measure in the column.
277
OD
CD
Ideal values (D)
This section indicates the values that the market would like to have for each of the
performance measures, in the absence of any trade-offs. There are three kinds of SSE
possible ideal values.
The Lower Acceptable Limit indicates the smallest value for the performance
measure that the market deems acceptable. SR
The Upper Acceptable Limit indicates the largest value for the performance
measure that the market deems acceptable.
The Ideal value indicates the value that the market would prefer if no trade-offs are
required.
Some performance measures will have only one acceptable limit.
The ideal values can be placed in the requirements matrix during the opportunity
development stage.
Together, regions A, B, C, and D comprise the market opportunity. The market
opportunity is created during opportunity development.
Real values (E)

This section indicates the values that are desired, predicted, and measured for the
Requirements Matrix
product. Although it would seem that the target values should be the same as the
ideal values, this is not true. It may be impossible to simultaneously achieve all the
ideal values given technological limits of the selected product concept.
The target values represent the values the team has decided to pursue given the
trade-offs inherent in the selected product concept. These values cannot be added
to the requirements matrix until the product concept is selected in Concept
Development.
During Subsystem Engineering and System Refinement, the design is finalized.
Models that relate the design to the performance measures are developed. When
the models are applied to the design in accordance with the tests, predicted values
of the performance measures are obtained.
The predicted values will change during product development as the design and
tests evolve, and as different models are created. Throughout the development
process, the most current predicted performance values should be listed in the
As prototypes are developed from the design and tested according to the tests,
measured values of the performance measures are obtained. As the product
information and tests evolve, the measured values will change. The most current
measured values should be listed in the requirements matrix.
Market response (F)

This represents the market’s rating of the product relative to the market
requirements. This information is available only at the end of the system refinement
stage when complete prototypes are available for the market to evaluate.
If desired, the market rating of competitive products can be listed in this section as
well.
Using the requirements matrix

The matrix is created in the opportunity development stage to capture market
requirements and translate them into performance measures that will guide the
278
OD
CD
development efforts. It is most easily used by first listing market requirements in
section A. Then, for each market requirement, the team decides what performance
measures would best represent the market requirement. These are placed in section
SSE
B. The team seeks unambiguous objective performance measures. When objective
measures are not possible, the team creates unambiguous subjective performance
measures. This is continued for each market requirement. Next, the team indicates
SR the relationships in section C. Finally, through dialogue with others, benchmarking,
and other research, the team establishes the ideal values in section D.
During concept development, after a concept is chosen, the team reconsiders the
performance measures and the trade-offs that exist between them for the chosen
product concept. This leads to the selection of target values for each of the
performance measures, which are placed in section E.
During concept development, as subsystems are identified, requirements matrices
are developed for each of the subsystems. Subsystem requirements matrices relate
system performance measures (the Whats of the subsystem matrix) to subsystem
performance measures (the Hows of the subsystem matrix).
During any stage of development, the predicted and measured values are placed in
section E of the matrix. The predicted and measured values are compared with the
target values during the approval at the end of various stages.
At the end of the system refinement stage, prototypes of the product can be
Requirements Matrix
evaluated by the market representative and the results of the evaluation placed in
section F.
The matrix is a valuable way to capture product performance in an unambiguous
and transferable way. Like most product development tools, however, the value goes
well beyond this. When used wholeheartedly, the understanding gained about the
product design makes the time spent preparing the matrix well worth it.
See also
Development Reference: Product-Focused Requirement Statements (11.48),
Quality Function Deployment (11.51), Requirements Hierarchy (11.54).
A
Product: DRILL
E
C
D
B
Subsystem: N/A

F
Real Values Ideal Values

4 The Drill seals borehole sides to prevent cave in

Importance
Upper
Importance
3
1
1
9
9
9
9
3
3
3
3
1
9
Measured Predicted Target Acceptable Ideal Lower Acceptable Performance Measures Units
140 – 220 – 250 100 9 1 Maximum borehole depth ft
480 – 60 60 45 – 10 2 Time required to cut through 6 inches of rock min
1313 – 200 – 3,000 500 10 3 Downward drilling force lbs
Not Tested – 300 – 400 200 10 4 Torque applied to drill bit ft-lbs
100 – 95 – 100 90 3 5 Compatable with X% existing drill bits %
65 – 113 – 113 50 6 6 Water pressure down the pipe psi
Not Tested – 5 5 0 – 3 7 Percentage of water that leaks through sides %
Not Tested – 95 – 100 95 3 8 Percentage volume of cuttings removed %
182 – 36 – 36 4 3 9 Depth cut per 8 hours of drilling ft
4 – 4 12 3 – 9 10 Number of required people people
332 – 200 400 50 – 9 11 Weight of heaviest subassembly lbs
84 – 96 96 48 – 9 12 Longest dimension (l,w,h) of biggest subassembly in
66 – 90 – 100 85 9 13 Percentage of drill manufacturable in Tanzania %
1,600 – 1,500 5,000 1,000 – 9 14 Cost to produce 1 drill after development USD
4 – 8 20 4 – 9 15 Time required to learn how to operate hr
3.5 – 3.5 5 3.5 2 1 16 Height of hand operated parts ft
Marginal – Ideal – continuously without the occasional rest, and requires 1 17 Feels comfortable n/a
Measured need to rest. Does not awkward movements that
Ideal Drill has a professional look. Drill looks like a piece of

– Ideal – People are interested in 4 18 The Drill is attractive n/a
Measured machinery for drilling holes.
looking at it.
Ideal The drill, when explained to
Measured – Ideal – investors, is something they 12 19 The Drill interests investors
want to invest in.
Not all of the market requirements and performance measures have been listed for reasons of space.
Market
Response
Excellent
Excellent
Excellent
Excellent
Excellent
Excellent
Excellent
Very Good
Very Good
Very Good
A simplified requirements matrix for the human-powered water well drill described in Appendix B of the book.
Acceptable
Acceptable
Acceptable
279
SR
CD
OD
SSE
Requirements Matrix
280
OD
CD
11.56 Revision Control
SSE Track the evolution of product development artifacts
During product development the requirements, tests, and design evolve. This
SR
evolution is captured in discrete steps through the creation of product development
artifacts. As the information evolves, the artifacts will change. To keep track of these
changes, the artifacts must be placed under revision control.
PR
Principles of revision control

PRR • All product development artifacts should be placed under revision control. This
means that, in addition to the design, the requirements and the tests should be
controlled.
• Revision control is required for effective coordination between and within
teams, because it allows all parties to be sure they are working with the same
information.
• A design artifact should be given a unique revision identifier when changes
have been made and the artifact is to be shared beyond its creator. If a CAD
model is saved every thirty minutes, it need not be given a new revision
identifier with each save. However, if a drawing made from the model is sent to
Revision Control
be checked, both the CAD model and the drawing should have a revision
number, even if the last change was only ten minutes ago.
• While an artifact is being created, before formal approval, the revision identifier
should identify it as unreleased, generally by having a different numbering
system. The revision process for unreleased artifacts is less formal than that for
released artifacts. However, pre-release versions should still be tracked.
• After formal approval, revision to artifacts requires the use of an engineering
change order (ECO) process to ensure that all who would be affected by the
change are made aware of it.
• All revisions of released artifacts should be archived so that they are available
for review at any time. It may be necessary to refer to prior revisions in order to
provide support for older versions of the product.
• Small changes in a design (often defined as those that will not be visible to the
end user or customer) can sometimes have a minor revision number and a less
rigorous ECO process.
How to do it
The following tips can help develop and maintain a revision control system.
• Use a detailed Bill of Materials (BOM) as an index to all of the components in

the design. The BOM itself should be under revision control. Each component
listed in the BOM should also have a revision number.
• Keep a list of requirement and test artifacts as an index to all of the
requirements and test information. The list of artifacts should be under revision
control. Each of the listed artifacts should have a revision number.
• When a revision number is assigned, save a copy of any computer file with the
revision number as part of the name. Revision control software or product data
management software can help with this task.
• Create a formal definition of the change process for released artifacts. Ensure
that the defined change process is followed.
281
OD
CD
• Develop a culture of revision control. Revision control takes work, and the work
of managing revisions is usually not exciting for designers. If the culture of
revision control is not established, it’s likely that revision control won’t happen.
SSE
With strong cultural expectations, revision control can become a regular and
valued part of the process.
SR
Applicability
Revision control is used through all stages of development on all product
development artifacts. PR
See also
Development Reference: Bill of Materials (11.3), Drawings (11.23), Engineering PRR
Change Order (ECO) (11.24).
Revision Control
Revision control software can simplify the creation and management of design revisions.
282
11.57 Robust Design

SSE Design your products to work all the time, in all conditions
Further Reading
Robust design is a method used to ensure that a product will function well even in Taguchi G, Clausing D
SR
non-ideal operating conditions and with the normal variability in manufacturing (1990) Robust quality.
processes. It seeks to maximize signal-to-noise ratios, where signal is the nominal Harvard Bus Rev,
performance and noise is the variation in performance due to deviations from Jan-Feb:65-75. An article
ideality. written by Taguchi for U.S.
management.
Phadke MS (1995) Quality

Key methods engineering using robust
PRR design Prentice Hall, Upper
Robust design aims to minimize the effects of variation on the performance of the
Saddle River New Jersey. A
product that is made. It includes efforts to improve the design as well as efforts to book written by a student of
improve the production process. Robust design was popularized in the 1980s by Taguchi that covers Robust
Gen’ichi Taguchi. Design thoroughly.
Taguchi developed special experimental designs that include both design Phadke MS Introduction to
parameters (called the inner array) and environmental or noise factors (called the robust design (Taguchi
outer array). By varying both design parameters and environmental factors, both the method) is available at www.
isixsigma.com/methodology/
nominal performance of the design and the variation due to environmental noise can robust-design-taguchi-
be estimated. It is then possible to identify parameter settings that not only have method/
high absolute performance, but also have minimal variation due to the introduction-robust-design-
Robust Design
environmental variables. taguchi-method/
To find robust operating points, Taguchi seeks to maximize signal-to-noise ratios, Box G (1988) Signal-to-noise
where signal is the mean performance of the design at a given set of parameters, ratios, performance criteria,
and transformations.
and noise is the standard deviation of the design at the same set of parameters. Technometrics 30(1):1-17.
Taguchi experiments aim to create response surfaces of S/N ratio, so that a location This paper claims that
traditional DOE techniques
of maximum S/N ratio can be found.
are better than Taguchi
Taguchi provides a variety of different experimental plans, with varying numbers of methods for creating robust
designs.
design parameters and noise factors.
Hunter RG, Sutherland JW,
Devor RE (1989) A
Applicability methodology for robust
design using models for
Robust design is generally applicable in subsystem development and later stages. mean, variance, and loss.
Robust design thinking should be a consistent part of product development in order Proc AMSE WAM, San
to produce high-quality products. Francisco:25-42. This paper
compares Taguchi
Some American statisticians believe that the specific experimental designs Taguchi experimental designs with
promotes are less effective than other designs would be. However, the idea of other design of experiments
considering the effects of variation on the design is supported by these same approaches.
statisticians.
See also
Development Reference: Design of Experiments (11.18), Six Sigma (11.62),
Sensitivity Analysis (11.61).
283
SSE
SR
PRR
Robust Design
In robust design, products are tested under conditions that are far from ideal to determine how well they
will perform in adverse conditions.
284
CD
11.58 SCAMPER
SSE Change existing products to create new concepts
Further Reading
SCAMPER is an acronym that captures techniques sometimes used by companies Thought questions and
to expand their product offering by rethinking one or more of their existing products. keywords to help with each
technique can be found at
litemind.com/scamper.
How to do it
Generally SCAMPER can aid brainstorming. Formally as a group, or individually in
one’s head, the points of the acronym can be used to ask the following questions:
1. Substitute: What if a different material, process, person, or place were

substituted for the existing ones? For example, could the handles on a pair of
scissors be made with a different material? Would doing so produce a valuable
product variant?
2. Combine: Can we combine units, purposes, or ideas? For example, can a
standard pair of scissors be combined with another useful tool such as a bottle
opener?
3. Adapt: What adaptations could be made to the idea or product to make it
useful in a similar context. For example, what adaptation would be needed to
make a standard pair of scissors useful for cutting sheet metal?
4. Modify/Magnify: Can the form, size, color, meaning, or motion be modified?
SCAMPER
For example, we could modify the form of the scissor blades that produce
decorative cuts.
5. Put to other uses: Are there new ways to use the product without modifying it?
The scissors could be used as a box cutter, for example.
6. Eliminate: Can a part, function, or person be eliminated? Could the person be
removed as the actuator, for example? This could result in a machine that
performs the actuation, allowing the person to control only the direction and
speed of cut.
7. Rearrange/Reverse: Can a different layout or sequence be used? The pin joint
could be moved to a different location on the scissors, for example.
See also
Development Reference: Brainstorming (11.5).
285
CD
SSE
Original
Substitute
Put to Other Uses

Combine
Eliminate
Adapt
SCAMPER
Modify/Magnify
Rearrange/
Reverse
Example of SCAMPER method as applied to scissors.

286
CD
11.59 Scoring Matrix
SSE Evaluate concepts with greater resolution
A scoring matrix is a tool used to evaluate concepts at a finer resolution than the
scoring matrix in order to provide guidance for selection of a superior concept.
Generally, a scoring matrix is used when there are fewer than ten concepts to
evaluate. The matrix is designed to evaluate each concept relative to weighted
market requirements (or any other design criterion).
How to do it
Construct the matrix: List the market requirements in column one. Assign weighting
factors wi for each concept and list them in column two. These weights most
often range between zero and one, and sum to one. List the concepts at the
top of the remaining columns of the matrix.
Rate the concepts: Moving row by row, one requirement at a time, rate each
concept as compared to the reference concept. The ratings (rij ) typically take
on numerical values from the five-point rating scale as shown in the table. The
five-point rating scale allows more resolution than the three-point scale used in
a screening matrix.
Scoring Matrix
One concept can be selected as a reference concept (as shown in the

example), or each requirement can have a different reference concept.
Two important objectives are met by moving row by row during rating. First, it is
much easier to be consistent in the evaluation of a particular market
requirement if all the concepts are evaluated for that market requirement
before moving on to other requirements. Second, completing an entire row
before moving to the next prevents gamesmanship in artificially raising or
lowering scores for specific concepts. Gamesmanship can also be avoided by
requiring the team to state a rational reason for the rating given each concept.
Calculate the score for each concept: The weighted score for each concept is
calculated as the sum of the weighted ratings or
X
Sj = wi rij
The use of non-uniform weighting factors allows more important requirements

to have greater influence on the concept score.
Use the weighted score estimate to concept quality: The weighted score is used as
a prediction of how well a product based on a particular concept would meet
the market requirements. Concepts with higher scores are considered better
than those with lower scores.
The best concept is not necessarily the one that has the highest score from the
scoring matrix. In fact, it is possible that several concepts will have similar
scores, or that there are other criteria that are important to the team but not
listed in the matrix. In this sense, the matrix does not make the decision. It
simply provides information to help the designer make a decision.
An important, often overlooked benefit of using a scoring matrix is the opportunity to

combine concepts that are strong in one area with others that are strong in different
areas. The same approach can be used to strengthen concepts that are particularly
weak. In this way, the scoring matrix is more than an evaluation tool – it facilitates
systematic concept development and evolution.
287
CD
See also
Development Reference: Controlled Convergence (11.10), Screening Matrix (11.60).
SSE
Scoring Matrix
Weight Concept 1 Concept 2 Reference ... Concept M
Requirement 1 w1 r11 r12 r1REF r1M
...
Requirement N wN rN1 rN2 rN,REF rN,M
Weighted Score S1 S2 S3 S4
Concept Scoring Matrix.
Rating Description
1 Much Worse Than Reference
2 Worse Than Reference
3 Same As Reference
4 Better Than Reference
5 Much Better Than Reference
Typical 5-point scale for rating concepts.

288
CD
11.60 Screening Matrix
SSE Quickly evaluate a relatively large number of concepts
Concept screening is a concept evaluation method that takes a coarse look at

various candidate concepts and rates them relative to a reference concept
(sometimes called benchmark design or concept). The method is conveniently
carried out with the help of a concept screening matrix.
A screening matrix is a quick and effective way to reduce the set of concepts from
roughly 20 to less than 10 and to improve/combine concepts during the process.
The matrix is designed to evaluate each concept relative to each market requirement
(or any other design criterion).
How to do it
To construct the screening matrix, list the market requirements in column 1. List the
concepts at the top of the remaining columns. For each requirement (or criterion)
rate each concept as better than (+), same as (=), or worse than (−) the reference
concept. Count the +’s, =’s, and −’s in each column. Calculate a net score by
subtracting the number of −’s from the number of +’s . Consider the number of +’s,
=’s, and −’s to identify the overall strengths and weaknesses of the concepts.
Screening Matrix
When making a rating, the team should reach consensus in order to give a rating of
+ or −. If the team cannot agree on one of these ratings, the default rating of = is
used.
The choice of the reference concept is up to the team. It is often the lowest-risk or
least novel concept in the set.
Rate all the concepts for one requirement before moving on to the next requirement,
rather than rating a single concept for all requirements. Two important objectives are
met by moving row by row in this way. First, it is much easier to be consistent in the
evaluation of a particular market requirement if all the concepts are evaluated for
that market requirement before moving on to other requirements. Second,
completing an entire row before moving to the next prevents gamesmanship in
artificially raising or lowering scores for specific concepts.
After rating all concepts for all requirements, sum the ratings and calculate the net
score as described above. It’s important to recognize that the best concept is not
necessarily the one that has the highest score from the screening matrix. In fact, it is
possible that several concepts will have equal scores, or that there are other criteria
that are important to the team, but not listed in the matrix. In this sense, the matrix
does not make the decision. It simply provides information that allows the human to
make a decision.
An important, often overlooked benefit of using a screening matrix is the opportunity
to combine concepts that are strong in one area with others that are strong in
different areas. The same approach can be used to strengthen concepts that are
particularly weak. In this way, the screening matrix is more than an evaluation tool –
it facilitates systematic concept development and evolution.
See also
Development Reference: Controlled Convergence (11.10), Scoring Matrix (11.59).
289
CD
SSE
Screening Matrix
Concept 1 Concept 2 Reference ... Concept M
Requirement 1 + + = +
Requirement 2 + – = +
Requirement 3 = – = =
...
Requirement N – – = =
Number of +’s 2 1 0 2
Number of =’s 1 0 4 2
Number of –’s 1 3 0 0
Net Score 1 –2 0 2
Improve/Combine? Improve Combine Combine None
Concept Screening Matrix.

290
11.61 Sensitivity Analysis

SSE Understand how small changes will affect performance
Further Reading
Sensitivity analysis is a technique used to understand the importance of each of the Saltelli A, Ratto M, Andres T,
SR
parameters in a model or product to the performance of the product. It provides Campolongo F, Cariboni J,
understanding about how changes in individual components or features affect Gatelli D, Saisana M,
performance, and is therefore a tool for rational selection of component tolerances. Tarantola S (2008) Global
Sensitivity Analysis. The
Primer, John Wiley & Sons,
Key methods New York.
The first step in sensitivity analysis is to determine the performance for which we Wikipedia has an excellent
entry on sensitivity analysis:
want to do the analysis. The performance can be modeled analytically or it can be
http://en.wikipedia.org/wiki/
measured experimentally. However, we must have some means of obtaining a Sensitivity_analysis
quantitative measure of performance
The second step is to make a first-order Taylor series approximation of the
performance. We do this by varying each of the parameters that affects the
performance, one-by-one. This will require one (if we are content to use a
single-sided derivative approximation) or two (if we wish to use a double-sided
derivative approximation) evaluations of the performance for each parameter.
Sensitivity Analysis
The third step is to estimate the resolution of each of the parameters. Formally, the
resolution is the standard deviation of the parameter. Informally, it may be the
specified tolerance on the parameter.
The final step is to calculate the sensitivity for each individual parameter:
∆Y
Si = δi (11.12)
∆Pi
where Si is the sensitivity for parameter Pi , Y is the performance measure being
∆Y
studied, ∆P is the numerical derivative of the performance with respect to
i
parameter Pi , and δi is the resolution of parameter Pi .
Having measured sensitivities for each of the parameters, we can now see which
parameters have the greatest effect on the performance, and make plans to improve
the resolution or adjust values of the parameters with the largest sensitivities.
Sensitivity analysis is similar to uncertainty analysis, but uncertainty analysis works
with closed-form solutions where partial derivatives can be calculated analytically,
and sensitivity analysis works with numerical solutions where partial derivatives must
be calculated numerically.
Applicability
Sensitivity analysis is most often used in the subsystem engineering and system
refinement stages of development.
See also
Development Reference: Design of Experiments (11.18), Uncertainty
Analysis (11.68).
291
SSE
SR
Model Structures
Resolution Levels
Errors
Sensitivity Analysis
UNCERTAINTY ANALYSIS
SIMULATION
MODEL
Model
Data Output
SENSTIVITY ANALYSIS
Parameters
FEEDBACK ON INPUT DATA AND MODEL FACTORS
How uncertainty affects the outcomes of experiments. Based on image created by Andrea Saltelli.
292
11.62 Six Sigma

Improve quality by designing for manufacturing variations
Further Reading
Six Sigma (6σ) is a set of methods to ensure that designs are robust relative to Tennant G (2001) Sis sigma:
SR
manufacturing variations. It is used to adjust both product and process designs to SPC and TQM in
achieve high quality and low variation. manufacturing and services.
Gower Publishing, Ltd.
PR Harry MJ, Mann PS, De
Key methods
Hodgins OC, Hulbert RL,
Because Six Sigma is a collection of methods, there is no space to describe the Lacke CJ (2011)
methods here. Instead, we provide a fundamental philosophical basis for Six Sigma, Practitioner’s guide to
PRR statistics and lean six sigma
and encourage the interested reader to review the literature for detailed instructions
for process improvements.
on the methods. John Wiley & Sons, New
Six Sigma started at Motorola, where it was recognized that traditional quality limits York.
would not suffice in manufacturing environments like electronics that have
thousands of components. Standard quality limits of plus or minus 3σ (where σ is
the process standard deviation) lead to approximately 3 defective parts per
thousand. If there are a thousand components in the assembly, this would mean
that each assembly would have three defective components.
If instead, quality limits are specified at plus or minus 6σ, even if a 1.5σ drift occurs,
there will only be 7 defective components per million, so for a
Six Sigma
one-thousand-component assembly, there will be only 7 assemblies containing a

defective component per every million assemblies.
Motorola developed a plan for reducing variability in production processes and
increasing the robustness of designs. This combined reduction in standard deviation
and increase in tolerance limits could lead to plus or minus 6σ limits for the process.
Six Sigma gained widespread popularity when Jack Welch applied it throughout GE,
which led to large increases in profitability.
Six Sigma has developed into a full-blown quality system, with training and
certification available.
Applicability
Six Sigma techniques are often applied during system refinement, producibility
refinement, and post-release refinement.
See also
Development Reference: Design of Experiments (11.18), Robust Design (11.57),
293
SR
PR
PRR
Six Sigma
294
OD
CD
11.63 Sketching
SSE Communicate design ideas with high-quality sketches
Further Reading
Sketching is a powerful part of product development. It is a skill everyone could use, Tutorials for engineers can
and everyone could work on improving. We sketch to facilitate concept exploration, be found at web.mit.edu/2.
and we sketch to communicate our ideas. 009/www/resources/
sketchingTutorials.html.
Those trained in the art can produce sketches such as those on the facing page.
Such sketches are very useful in sharing ideas and helping others embrace them.
Sketching tips
Those of us not trained in the art might find these sketching tips useful.
• Lose drawing inhibition: Forget about what others will think of how good or bad
your sketch is.
• Practice: Good sketchers practice. We know some who do sketch warm ups;
they draw pages of straight lines, pages of circles, pages of ellipses, and so on.
• Sketch with your arm (not your finger or wrist) this will produce nice, confident
lines. Not doing this tip will result in chicken scratch (wiggly lines). See
sub-figure b in the facing page.
• Complete line connections: Incomplete connections are cognitively unpleasing
Sketching
(sub-figure c).
• Build from basic shapes: Almost everything can be constructed from lines and
ellipses. Use lines to make cubes. Use lines and ellipses to make cylinders
(sub-figure d).
• Try perspective view using vanishing points (sub-figure f): This is more realistic
than isometric figures (sub-figure e).
• Try shading and shadows (sub-figure g).
See also
295
OD
CD
SSE
Sketching
Concept sketches of a toaster (a). Sketches by Stephen Jensen, used with permission.
296
OD
CD
11.64 Storyboards
Envision what end users will experience using your product
Further Reading
While developing a product, it is surprisingly easy to lose sight of who will interact van Boeijen A, Dallhuizen J,
with the product once it is on the market and what their experience with it will be. Zijlstra J, van der Schoor R
(2014) Delft Design Guide
Storyboards visually represent moments in the user’s experience with the product. BIS Publishers. pp.
They are a powerful way to quickly convey a user-centered experience to project 152-153.
stakeholders, other team members, or potential end users. They help designers
envision and ultimately plan for a meaningful experience for end users early in the Hanington B, Martin
B.(2012) Universal methods
development process. Storyboards help team members focus on what the end user of design: 100 ways to
will do with the product and how they will interact with it. research complex problems,
develop innovative ideas,
Because of their simple language and focus on the human experience, storyboards and design effective
are particularly useful at assisting others – of different backgrounds, disciplines, or solutions. Rockport
cultures – to understand and evaluate a problem or potential product solution. Publishers. pp. 170-171.
How to create storyboards

1. Develop a good understanding of who will use the product. Choose a subject
(character) for the storyboard.
2. Choose one or more of the following to represent in a storyboard, and consider
Storyboards
what the subject will experience when they:

• Find out about the product
• Decide whether they want the product or not
• Acquire the product
• Unpack, install, and/or learn how to use the product
• Use and/or maintain the product
• Dispose of or recycle the product
3. Tell the end user’s story with the product. Do this in a graphical way, using
minimal words. Consider the following visual elements:
• Graphical medium (sketch, photo, computer line-art, etc.)
• Number of panel (typically 12 or less)
• Camera angle and zoom (to focus attention on one area)
• Techniques to convey movement (arrows, wind, etc.)
• Techniques to convey sound (onomatopoeia, sound waves, etc.)
• Techniques to convey emotion (eyebrows, shoulders, head angle, etc.)
• Use of dialogue and other words (speech bubbles, captions, etc.)
How to use storyboards to advance the design

Bring a storyboard to a team meeting and see how it changes the discussion from
that of product to that of how the product betters the user’s life or solves a user
problem. Try using a storyboard to envision the user experience and
brainstorm/refine market requirements. Use storyboards to convey concepts quickly
to a non-technical audience and to get feedback. Use storyboards to promote
discussion and build end-user empathy. Try using storyboards as a low-fidelity
validation prototype.
See also
Development Reference: Personas and Locales (11.45), Sketching (11.63).
297
OD
CD
Simple hand sketched storyboard used to convey camera remote shutter button concept.
Storyboards
A C
B D
A TURN KNOB TO CYCLE THROUGH THE SIX B REPLACE BATTERIES BY C HEADLAMP CAN BE D ADJUST POSITION OF
LIGHT MODES AND PRESS BUTTON FOR TWISTING DIAL AT BASE TILTED VERTICALLY HEADLIGHT BY SLIDING
ADDITIONAL FUNCTIONALITY OF POWER PACK FOR LOW/HIGH BEAM ALONG THE HEADBAND
1 2 3 4 5 6
SPOT FLOOD FLASH SOS RED OFF
press/hold
3 seconds
OFF
press/hold
dimmer
Detailed storyboard showing how to set, use, and adjust a headlamp.

298
OD
CD
11.65 Surveys
Obtain market information from many individuals
Further Reading
Surveys are written, in-person, telephone, or mail-based instruments used to better An excellent overview of
understand the preferences of the market. processes for developing
surveys is found in Dillman
Surveys are generally cheaper to conduct than focus groups, but are harder to get DA, Smyth JD, Christian LM
effective open-ended information from. (2014) Internet, phone, mail,
and mixed-mode surveys:
the tailored design method,
Guidelines for creating effective surveys 4th ed. Wiley, New York.
PRR The following steps have been found useful when creating surveys:
• Define the purpose of the survey: A narrowly focused survey will be far more
effective at obtaining useful information than a broadly focused survey.
Defining the purpose is essential to narrow the focus.
• Define the target audience: Surveys should be tailored to a specific target
audience. Questions, presentation, and topics are likely to be dramatically
different for different audiences.
• Define the questions: Survey questions should be carefully defined to obtain
the purposes of the survey. Careful focus on the purpose helps to keep the
survey short, which increases the response rate and the quality of the answers.
Be sure that questions are not leading, and that response options are balanced.
Surveys
• Test the questions: Before administering a large survey, test the questions on a
smaller sample of the target audience. If possible, administer the test questions
in person, so that you can learn about problems with the questions by personal
comments, rather than just the answers to the questions. Refine the questions
until the test responders understand the questions the same way you do.
• Administer the survey: The survey can be delivered by a variety of methods,
including in-person, mail, telephone, and the web.
• Follow up with non-responders: For mail, telephone, or web surveys you may
find that some people fail to respond. Follow up with those who do not respond
to try to increase the response rate.
• Analyze the result: Statistical analysis of the results is helpful, including
identifying the limits of confidence on the answers.
See also
Development Reference: Focus Groups (11.31).
299
OD
CD
PRR
Surveys
Surveys provide a method for obtaining market information from a large sample of people.
300
CD
11.66 Theory of Inventive Problem
Solving (TRIZ)
Further Reading
Find creative solutions to seemingly insoluble conflicts Altshuller G, Shulyak L,
Rodman S, Fedoseev U
TRIZ (pronounced TREES) is a Russian acronym for Theory of Inventive Problem (2005) 40 Principles: TRIZ
keys to technical innovation.
Solving. TRIZ was developed in 1946 by Genrich Altshuller after leading a study of Techni-Cal Innovation Center.
over 1.5 million patents. Altshuller found that similar problems had been solved in
different technical fields using only a few dozen inventive principles. These inventive Terninko J, Zusman A, Zlotin
principles, which are part of the TRIZ method, can be used to help teams identify B (1998) Systematic
innovation: an introduction
PRR non-traditional solutions to problems – especially problems involving seemingly to TRIZ (theory of inventive
difficult to resolve conflicts. problem solving). CRC Press
LLC.
Altshuller found that there were only 1250 typical conflicts and that they could be
overcome with 40 inventive principles. He also found that there were only 39
Theory of Inventive Problem Solving (TRIZ)
engineering parameters that engineers tried to improve.
How to use TRIZ

1. Phrase the problem to reveal the conflict.
2. Identify the Engineering Parameters involved in the conflict.
3. Identify Inventive Principles (there are only 40) that could resolve the conflict.
4. Create ideas based on those inventive principles.
Example
A product development team worked on a next generation impact driver design.
These drivers (similar to a drill driver) are often used by people in the construction
industry to hang drywall. The team learned that the market required comfort and
little down time because of dead batteries. Using a requirements matrix, the team
translated these requirements into mass of the impact driver (this has a large impact
on the comfort of using the driver), and power capacity in the driver batteries.
The team soon learned that greater power capacity for the batteries leads to a more
massive impact driver – a conflict that is seemingly difficult to resolve.
Following the method above, the team identifies engineering parameters number 1
(weight of moving object) and 21 (power) as being involved in the conflict. With
these two parameters in mind, the team identified an inventive principle that could
resolve the conflict – inventive principle 1 (segmentation). Examples1 of
segmentation include (i) divide an object into independent parts, (ii) make an object
sectional (for ease of assembly or disassembly), and (iii) increase the degree of an
object’s segmentation.
The team chose to divide the impact driver into two parts – the batteries, and the
impact driver mechanism. In the end, they developed a drill driver with a battery in a
backpack. More weight carried in a location that moves less resulted in a more
comfortable drill driver with greater power capacity in the batteries.
See also
1
Development Reference: Brainstorming (11.5). Admittedly, the inventive principles
can be difficult to understand based
only on short description given
in the table. A good expanded
discussion of each principle is given
in (Altshuller and Shulyak, 1996)
301
CD
Electrical Electrical
Cord Runs Contacts Battery for handheld tool
Down Arm in Glove
held in backpack. Tool
powered by contacts in
glove.
Batteries in
Backpack
1. Weight of a moving object 21. Power 39 Engineering PRR

2. Weight of a non-moving object 22. Waste of energy
3. Length of a moving object 23. Waste of substance Parameters for TRIZ
4. Length of a non-moving object 24. Loss of information Method.
5. Area of a moving object 25. Waste of time
6. Area of a non-moving object 26. Amount of substance
Theory of Inventive Problem Solving (TRIZ)

7. Volume of a moving object 27. Reliability
8. Volume of a non-moving object 28. Accuracy of measurement
9. Speed 29. Accuracy of manufacturing
10. Force 30. Harmful factors acting on object
11. Tension, pressure 31. Harmful side effects
12. Shape 32. Manufacturability
13. Stability of object 33. Convenience of use
14. Strength 34. Repairability
15. Durability of a moving object 35. Adaptability
16. Durability of a non-moving object 36. Complexity of device
17. Temperature 37. Complexity of control
18. Brightness 38. Level of automation
19. Energy spent by a moving object 39. Productivity
20. Energy spent by a non-moving object
1. Segmentation 21. Rushing through

2. Extraction 22. Convert harm into benefit 40 Inventive Prin-
3. Local quality 23. Feedback ciples for TRIZ
4. Asymmetry 24. Mediator
5. Combining 25. Self-service
Method.
6. Universality 26. Copying
7. Nesting 27. Short-lived (disposable) instead of durable
8. Counterweight 28. Replacement of a mechanical system
9. Prior counteraction 29. Use of pneumatics or hydraulics
10. Prior action 30. Flexible film or thin membranes
11. Cushion in advance 31. Use of porous material
12. Equipotentiality 32. Change the color
13. Inversion 33. Homogeneity
14. Spheroidality 34. Rejecting and regenerating parts
15. Dynamicity 35. Transform physical and chemical states of an object
16. Partial or overdone action 36. Phase transition
17. Moving to a new direction 37. Thermal expansion
18. Mechanical vibration 38. Use strong oxidizers
19. Periodic action 39. Inert environment
20. Continuity of useful action 40. Composite materials
302
11.67 Troubleshooting
SSE A systematic process helps fix non-working systems
Troubleshooting is the act of identifying and fixing problems that prevent an

SR
engineered system from working properly.
PR
How to do it
The following steps form an effective troubleshooting process.
1. Prepare a troubleshooting log

PRR The troubleshooting log will contain a written record of all of the problems
identified as well as all of the steps taken to solve the problem. It can be either
hardcopy or electronic. However, it must be complete.
2. Document the problem
A clear statement of the problem helps to both focus your efforts and know
when the problem is finally fixed. An effective problem statement includes the
following:
a) What input are you providing to the system?
b) What do you expect to happen?
Troubleshooting
c) What actually happens?

d) What steps are necessary to reproduce the problem?
For intermittent problems, it is not uncommon that most of the time spent
troubleshooting is spent identifying a reproducible method for causing the
problem.
3. Obtain (or develop) a logical model of the system
In order to know that something is wrong with your system, you need to know
how the system is supposed to work. If you cannot obtain a logical model, you
will need to create one. This often takes the form of a block diagram or a
flowchart.
The logical model should identify inputs and outputs for each of the elements
in the model.
4. Narrow down the possible trouble location
Following the procedures listed in step 2, cause the problem to occur.
Divide the system in half. Check the first half of the system. Is it working
properly? The logical model of the system should identify the desired outputs of
the first half. If the first half isn’t working properly, focus on the first half.
Otherwise focus on the second half.
Continue the subdivide and narrow process until you have identified a specific
element that is causing the problem.
Note that in some systems it may be necessary to physically separate the
halves of the system when troubleshooting, as a failed component may affect
signals throughout the system.
5. Repair or redesign the faulty element
If the problem is due to a faulty physical component (e.g., a broken part),
replace the component.
If the problem is due to faulty engineering (e.g., a bug in a program),
reengineer the component.
6. Verify that the change solved the problem
Check to see that the new element is working properly. If this is the only fault in
the system, the system will now work properly. Otherwise, return to step 4 and
identify the next problem.
303
See also
Development Reference: Fault Tree Analysis (11.28).
SSE
SR
PR
PRR
Troubleshooting
Troubleshooting for even the most complex systems is facilitated by using a systematic
troubleshooting process.
304
11.68 Uncertainty Analysis

SSE Predict how changes in parameters change performance
Further Reading
Uncertainty analysis is a calculus-based method of determining how changes in one NASA (2010) Measurement
SR
parameter will affect performance. It requires an analytical (closed-form) solution for uncertainty analysis
the performance. When such a solution exists, uncertainty analysis is very quick and principles and methods:
easy to do. If no such solution exists, sensitivity analysis is used to work with linear NASA measurement quality
approximations of the solution. assurance handbook – annex
3. Available at http://www.
hq.nasa.gov/office/codeq/
doctree/NHBK873919-3.pdf
Key methods
Bevington PR, Robinson DK
Uncertainty analysis uses partial derivatives to estimate the uncertainty in a given
(2002) Data reduction and
measurement. For a calculated quantity Q that depends on N measured values Xi , error analysis for the physical
standard deviation of Q can be estimated from the standard deviation of the sciences, 3rd ed.
measurements: McGraw–Hill.
Wikipedia has an excellent

article on uncertainty
analysis: http://en.wikipedia.
org/wiki/Experimental_
uncertainty_analysis
Uncertainty Analysis
v
uN
uX ∂Q
σQ =t σ2 (11.13)
i=1
∂Xi Xi
This assumes that the individual measurements are independent, so that any
measurement errors are uncorrelated. If the measurements are not independent,
different formulas apply.
Uncertainty analysis can be used to understand the precision needed in
manufacturing, if there is a functional relationship that governs the performance of
the design. The standard deviation of the performance can be calculated from the
design parameters in the same way the standard deviation of a calculated quantity
can be calculated from the standard deviations of the measurements.
The process of determining the necessary precision in individual design parameters
is known as tolerance allocation.
Applicability
Uncertainty analysis can always be used during validation. It is also used during
subsystem design, and may be revisited when the design is refined during later
See also
Development Reference: Design of Experiments (11.18), Robust Design (11.57),
305
SR
SSE
Uncertainty Analysis
306
CD
11.69 Value Engineering
SSE Focus on the parts of the design that add value to the
customer Further Reading
Borza J, (2011) Fast
Value engineering is a design process focused on understanding the aspects of a diagrams: the foundation for
creating effective function
product that provide value to a customer, and driving the design to create the best models. Proceedings of
value. Value is provided to a customer by delivering product functions. Value is TRIZCON 2011 Detroit, Mi.
defined as the ratio of the benefit provided by the function to the cost of providing the Available for download from
function. So it is important to look at both increasing benefits and reducing costs. http://www.aitriz.org/
documents/TRIZCON/
Proceedings/2011-06_FAST-
PRR
Key methods Diagrams-The-Foundation-
for-Creating-Effective-
In value engineering, a product is analyzed in terms of the functions it provides. Function-pdf
Each function a product provides is described in two words – an active verb followed
A variety of summary
by a measurable noun. Transmit force would be a valid function for value resources is available as a
engineering. Orient bracket would not, because “bracket” is not a measurable noun, pdf from SAVE International,
it’s a component. For value engineering to reach its potential, we want to avoid a professional society
describing the components of the product, as they are subject to change. Instead, focused on value
we want to describe the functions, which are unchanging. engineering.
http://www.value-eng.org/
Value engineering recognizes two major categories of functions: basic functions and education_publications_
Value Engineering
secondary functions. Basic functions are the functions that are necessary to perform function_monographs.php
the task that all products of this type must perform. For example, all fuel tanks must
perform the function “contain fuel,” so it is a basic function for a fuel tank.
Secondary functions are functions that are designed into a product to allow or enable
the basic function to occur. They are further subdivided into the following categories:
Dependent Critical Functions: Functions that must occur in order to have the basic
function occur.
Independent or Supporting Functions: Functions that help the basic function to be
delivered better, faster, longer, etc. Virtually all of the competitive advantage for
a particular product will be found in the supporting functions, because every
product performs the basic functions.
All-the-time Functions: Functions that are requirements for the product but that are
not generally related to the basic function, such as providing reliability,
corrosion resistance, working in typical conditions, etc.
Design Criteria: Functions that are related to the important market requirements of
the product that are not otherwise captured.
A key diagram to understand the functions provided by a product is the function

analysis system technique (FAST) diagram. FAST diagrams capture the basic
function, the dependent critical functions, the supporting functions, the design
criteria, and the all-the-time functions in one brief diagram.
Applicability
Value Engineering is often applied more in redesign of existing products than in
design of totally new products.
The FAST diagram is typically created during the opportunity development or
concept development stages of development.
Once the FAST diagram is created, concept creation is carried out on key functions
that are identified as opportunities to increase value.
307
CD
See also
Development Reference: Quality Function Deployment (11.51), Six Sigma (11.62).
SSE
PRR
HOW? PC PROJECTOR WHY?
WHEN? “DESIGN CRITERIA” “ALL THE TIME”
Value Engineering
Transfer Idea Minimize Noise Provide Styling Inform Customer
Maintain Meet Enhance

Durability Specifications Aesthetics Prevents Injury
Lower Order
Higher Order CRITICAL PATH (assumed or
(Final Goal) causative)
Share Information Project Image Focus Image Transmit Light Generate Light Convert Energy Receive Electricity Transmit Electricity
Minimize Heat Minimize Power

CAUSED BY
OR AT
THE SAME
Convert Signal Receive Signal Transmit Signal
TIME AS
SCOPE OF PROBLEM UNDER STUDY
A FAST diagram for a video projector, focusing on the basic function of the projector – sharing information. After
Borza.
APPENDIX A
Summary of Evolution in Product
Development
This appendix contains a brief summary of to test how well the design meets the
the evolution that takes place during requirements at a given state of evolution.
product development.
Figure A.2 shows how the requirements,
The six stages of product development are tests, and design evolve in a coordinated,
shown in Figure A.1. They are: iterative fashion.
At the end of each stage of development,
1. Opportunity development the design is submitted for review and
2. Concept development approval. Major work on the subsequent
stage is undertaken only after the results of
3. Subsystem engineering the current stage have been approved.
4. System refinement Figure A.3 shows how desirability and
transferability are evaluated during a
5. Producibility refinement development stage. It shows the
6. Post-release refinement relationships between artifact checking,
performance testing, and validation testing.
The stages of product development are Table A.1 summarizes the nature of
fundamentally stages of design evolution, information checks, performance tests, and
as the design moves from less detail to validation tests. Before approval at each
more detail. Along with the design, stage, the design must be demonstrated to
requirements and tests evolve in concert have sufficient desirability and
throughout the stages of development, as transferability. The demonstration must
shown in Figure A.1. The evolution is satisfy the project approvers, who are
tracked by observing changes in design external to the development team.
artifacts that capture the team intent in a
transferable manner. The six stages of product development are
summarized in Tables A.2 through A.7.
Models and prototypes are testable The top-level activity maps for each stage
representations of the design that are used are repeated in Figures A.4 through A.10

https://doi.org/10.1007/978-3-030-14899-7
310 APPENDIX A. SUMMARY OF EVOLUTION IN PRODUCT DEVELOPMENT
Increasing Detail
OPPORTUNITY CONCEPT SUBSYSTEM SYSTEM PRODUCIBILITY POST-RELEASE

DEVELOPMENT DEVELOPMENT ENGINEERING REFINEMENT REFINEMENT REFINEMENT
REQUIREMENTS
TESTS
MODELS &
PROTOTYPES
DESIGN
A B
Figure A.1: The product requirements, tests, and design evolve through the stages of product development; the design
is eventually used to manufacture the product. Prototypes and models are testable representations of the design used to
determine the performance of the design at the current stage of evolution.
311
Initial Revised Second Final

REQUIREMENTS Requirements Requirements Requirements Requirements

TESTS Tests Tests Tests
MODELS & First Models Second Models

PROTOTYPES & Prototypes & Prototypes

DESIGN Design Design Design
Figure A.2: The co-evolution of the requirements, the tests, and the design as aided by prototypes and models. Proto-
types and models are created as a snapshot consistent with the current design and tested to measure and predict the
performance of the design to compare with the requirements.
REQUIREMENTS
Assess Assess Assess
Predicted Measured Market
Values Values Response
TESTS
Performance Predicted Measured Market Validation
Testing Values Values Response Testing
Testing T
Testing Validation
Models Prototypes Prototypes
DESIGN
Artifact Checking Team Intent

Complete, Clear,
Follows Standards
Figure A.3: Evaluation of desirability and transferability testing during a development stage. This shows the relationship
between artifact checks, performance tests, and validation tests. The design is checked for quality and completeness.
Using prototypes and models based on the design, product performance is measured or predicted using the tests. Vali-
dation testing consists of having a market representative to evaluate a prototype and pass judgment on the quality of the
design. For approval, all required information should be present, the predicted and/or measured performance should
meet the ideal or target values, and the market response should demonstrate that the market requirements are met.
313
Table A.1: Overview of desirability and transferability testing. This table summarizes the artifact checks, performance
tests, and validation tests that must be successfully completed to obtain approval at the end of a product development
stage.
Artifact Checks Performance Tests Validation Tests

Test Check the quality and Use models and prototypes Have the market
objective: completeness of the design, based on the design to representatives evaluate
requirements, and tests. predict and measure the design artifacts to evaluate
Ensure that these fully and performance of the design the quality of the design from
unambiguously capture what according to the tests. the market perspective.
the team intended. Compare the predicted and
measured performance with
the requirements.
Artifacts Transferable medium Models or prototypes based Prototypes that communicate

used in appropriate for on the design; standard test appropriately to the market
testing: communicating the design methods that govern testing representatives; standard
(e.g., written list, technical test methods that govern
drawing, bill of materials, test validation tests
report, requirements matrix)
Artifacts Formal approval of the Test reports indicating the Test reports indicating the
created artifacts checked; usually results of applying tests to results of validation tests;
during includes release of a given models and prototypes; market response values (in a
testing: revision predicted and/or measured requirements matrix, for
values (in a requirements example)
matrix, for example)
Who is Evaluation performed by Evaluation performed by Evaluation coordinated by

involved: member(s) of the product product development team development team and
development team, performed by market
excluding the person who representatives
created the artifact
Table A.2: Summary of the opportunity development stage.
Opportunity Development: Develop clear statements of market and engineering requirements that capture the market’s desires for
the product.
Required
information
Consistent level of generality?
Capture the most important Complete and appropriate as
Market Section A of the
requirements? Appropriate number evaluated by market
requirements requirements matrix
of requirements? Reasonable representative
differences in importance?
Clearly measurable (even for
subjective)? Capture market Market representatives (for less
requirements well? Generally technical measures) and/or
Requirements
Performance Section B of the

dependent, rather than project approvers (for highly
measures requirements matrix
independent? Units given and technical measures) find the
appropriate? Number appropriate? measures to be appropriate.
Appropriate importance ratings?
All requirements have at least one
measure? All measures have at
Requirement-
Section C of the least one requirement? More than Judged appropriate by project
measure
requirements matrix just one-to-one correlations? approvers
correlations
Appropriate, defensible
correlations?
Values make sense? Values are Judged appropriate by project
Section D of the
Ideal values consistent with market approvers and market
requirements matrix
requirements? representatives
Reports of team interactions

Not approved directly, but used
with market representatives Are the interactions accurately
Tests
None required to support approval of the

(e.g., surveys, interviews, conveyed in the report?
requirements
etc.)
Simple models that relate

desirability to measured Not approved directly, but used
Models
None required performance of competitors Do the models make logical sense? to support approval of the
(e.g., screen size, battery requirements
life)
Rough prototypes
(foamboard, paper, foam,
clay, cardboard, plywood, Do the prototypes facilitate Not approved directly, but used
Prototypes
None required etc.) used to communicate communication with market to support approval of the
with market representatives. representatives? requirements
Don’t fully reflect eventual
product design.
Rough sketches or drawings
of competitors or generic Do the sketches or drawings Not approved directly, but used
Design
None required product possibilities. Don’t facilitate communication with to support approval of the
fully reflect eventual product market representatives? requirements
design.
Basic design process, competitive benchmarking, financial analysis, focus groups, interviews, observa-
Useful tools: tional studies, patent searches, planning canvas, project objective statement, quality function deployment,
requirements matrix, surveys.
Common Assuming, not validating; using only subjective performance measures; delaying feedback; devaluing the
pitfalls: opportunity development stage; spending too much time.
315
requirements,
Initial performance measures,
idea and correlations, and ideal
team Translate values
market
statements Identify missing or 15 21
Interact with 6 8 hidden
client Organize requirements
Capture
requirements
performance
into hierarchy
measures from
t
arke
1
market
19 22
ith m
Create Project statements Identify

9
Objective Statement further
act w
to which team can correlations

commit
Inter
11 12 13
10
Seek approval 20
Objective Identify initial from client
Statement Capture reqt.-measure Identify missing
2 3 performance correlations performance Seek feedback
measures found measures from market
in benchmarking
5 7 14
Seek approval Model market
for Objective preferences
Study competitive
Statement
products and 17 18
4 technology in 16
general Use market model to
establish acceptable
limits and ideal values to Concept
Development
OUTCOMES
Client’s wishes about scope, schedule,
1 8 Product-focused requirement statements 15
resources
2 Initial project objective statement 9 Initial market requirements Models of market acceptance vs
16 performance
3 10 Initial performance measures Ideal values and acceptable limits for
17 performance measures
4 Approval of project objective statement 11 Initial measures and requirements
18
5 Approved project objective statement Initial requirement-measure correlations
12 19 Approval of opportunity development
Market/customer statements related to the
6 product Market feedback on requirements,
13 20 measures, and ideal values
7 General benchmarking data
14 21
22
Figure A.4: Top-level activity map for the opportunity development stage.
Table A.3: Summary of the concept development stage.
Concept Development: Create a concept for the product and evolve it to have enough information to create basic estimates of cost,
size, weight, and feasibility. Also include subsystem definitions, interface definitions, and target values for performance.
Required
information
See the Opportunity
Subsystem Section A-D of the requirements matrix Development summary for the Complete and
Requirements
requirements for each subsystem checking criteria for appropriate.

requirements matrices.
Consistent with ideal values?
Achievable with the selected
product concept? Target values
Target values for the Consistent with
Section E of the requirements matrix for for all performance measures?
system and the expectations of
the system and all subsystems. Distinction between constraints,
subsystems. market
success measures, stretch
goals? Trade-offs to less than
ideal performance justified?
List, chart, or summary of considered
Justification for
concepts.
concept selection,
Evaluation summary of considered Are the test methods complete
including model The desirability of
Tests
concepts demonstrating feasibility of and correct? Is there enough

analysis and/or the concept is
selected concept. detail for a third party to repeat
prototype test data demonstrated.
Model and/or prototype test reports the tests?
demonstrating
demonstrating the validity of the
concept feasibility.
selected concept.
Low-fidelity fundamental models of the
Rough technical concept’s operating principles. Are the models reported in Not directly
Models
models of the Statistical models describing the enough detail to allow a third approved; used
product concept. performance of experimental party to use them? with tests.
prototypes or related existing products.
Rough prototypes (foamboard, paper,

Prototypes
Simple prototypes of Not directly

foam, clay, cardboard, plywood, etc.) Are the prototypes appropriate
the product approved; used
used to show how the concept for the intended use?
concept. with tests.
functions.
One or more of the following: The design is

Annotated hand sketches of concept. sufficiently
Geometric and other Is the design clearly
Overall system CAD model. Layout transferable to
appropriate communicated? Can a third
drawing. Skeleton drawing. Notes on support cost,
definition of the party understand the intended
sketches/drawings explaining concept. size, weight, and
concept. design?
Block diagrams of electrical or fluid feasibility
systems. estimates.
The
Decomposition of Tree or other relationship diagram that decomposition is
Are the subsystems and their
product concept shows structure of decomposition. List appropriate for
relationships clearly shown?
Design
into subsystems. of subsystems. the selected

concept.
Interface matrix showing where
Is the interface matrix complete?
subsystems interact. Product-focused
Are the interface definitions The interfaces
requirement statements for each of the
Subsystem interface complete? Are the interface are fully defined
interfaces. Performance measures for
definitions. definitions appropriate to and appropriate
each of the interfaces. Subteam
achieve the desired for the concept.
responsibility assignments for each
performance?
interface.
Spreadsheet or database table that lists The bill of
Preliminary Bill of Is the BOM complete at the level
all known components, even if they materials is
Materials. of known detail?
have only a part name at this time. appropriate.
Bill of materials, bio-inspired design, brainstorming, competitive benchmarking, controlled conver-
gence, decomposition, internet research, interviews, literature review, method 635, mind maps, proto-
Useful tools:
typing, recombination table, requirements matrix, scoring matrix, screening matrix, sketching, theory
of inventive problem solving (TRIZ).
Common pitfalls: Concept fixation; premature concept critique; reinventing the wheel; vague interfaces; decision delay.
317
From models, prototypes

Opportunity Compare
12
requirements
7 9 13 14
Create
candidate
solution set 10 16
8 11 Select
1 Predict/measure 15
concept
performance
team
Create supports
needed test prototypes models 23 Formalize
Reduce to procedures epts preliminary
tractable conc 22 24 cost models
concept set Formalize
6 predicted Formalize
Select concepts performance preliminary
Combine/improve worth testing technical
concepts Make models
2 4 tradeoffs and
30 choose target
5 25 values
Seek
18
schedule BOM
3 27
26 19 17
Formalize
geometric
33
Develop
32 opportunity and
engineering
To Subsystem
Engineering
Establish interface
requirements and
responsibility
OUTCOMES
3 Concept ratings Concept evaluations Predicted performance of concept

14 25

17 Final concept 28
7 concepts
21 Design 32
Figure A.5: Top-level activity map for the concept development stage.
Table A.4: Summary of the subsystem engineering stage.
Subsystem Engineering: Create high-quality engineered subsystems that have been demonstrated to be desirable. Design for other
characteristics such as manufacturability and ergonomics should have been accomplished. At the end of this stage, the entire system
has been designed, although the integration of subsystems has not yet been demonstrated.
The subsystems meet or
exceed the target values of the
Predicted and All predicted values are
Section E of the subsystem performance
measured values for present, even if the value
requirements matrix for measures. If a few of the
subsystem performance is N/A? All measured
each subsystem targets are not met,
Requirements
measures. values present?

acceptable range.
The predicted values meet or
Predicted values for all
exceed the target values for the
Predicted values for performance measures?
Section E of the system system performance measures.
system performance Consistent with
requirements matrix If a few of the targets are not
measures subsystem measured
met, performance is at least in
values?
Test data demonstrating results demonstrating the Are the test methods The tests have been carried
subsystem desirability desirability of the subsystem complete and correct? Is out with sufficient quality and
Tests
(measured values for designs. Plots showing there enough detail for a transferability to provide strong
subsystem performance variation of subsystem third party to repeat the evidence for the measured and
measures). performance with changes tests? predicted values.
in design parameters.
Software source code with
Engineering models
run results. Input files for
Models

values for subsystem a third party to use them?
Prototypes

used to measure values. Fully functional intended use? Is the
with tests.
measured values of subsystems for testing fidelity and workmanship
subsystem performance measured values. appropriate?
measures.
ordering information) for all The design is sufficiently
the necessary
purchased parts. Assembly transferable to allow the
Geometric, material, components included? Is
drawings for the system and creation of complete
and other appropriate the design package
all subsystems. Schematic subsystems and their
definition of the design sufficient to allow a third
diagrams. Piping and/or integration into a complete
Design
for each subsystem. party to correctly make

wiring diagrams. Block system by a third party.
compliance with
part of the design.
control?
components
and unambiguous?
Useful tools:
drawings, ergonomics, experimentation, failure modes and effects analysis, fault tree analy-
sis, finite element modeling, prototyping, sensitivity analysis, uncertainty analysis.
Avoiding analysis; reinventing analysis; never doing analysis; poor experimental procedure;
Common pitfalls:
focusing on the prototype, rather than the design.
319
Seek approval for

subsystem A
13
Seek approval for 12

subsystem B
11
Engineer
Subsystem A 2 16
Test integrated A-B 14
performance 15
7 9
Engineer
Subsystem Seek approval for
From Concept 3
B subsystem C To System
Development
19 17
Engineer 18
Subsystem C
Assign 1 4 8 10
resources to Test integrated
22 20
subsystems B-C-D performance
21
5 26
Engineer
Subsystem D
Seek approval for
subsystem D
25 23
Engineer n 24
Subsystem n
6
Seek approval for

subsystem n
OUTCOMES
1 Subsystem assignments 10 Measured B-C-D integrated performance 19 Approved subsystem C
2 Subsystem A ready for integration testing 11 Subsystem A approval 20 Subsystem D approval
3 Subsystem B ready for integration testing

12 21
4 Subsystem C ready for integration testing
13 Approved subsystem A 22 Approved subsystem D
5 Subsystem D ready for integration testing

14 Subsystem B approval 23 Subsystem n approval
6 Subsystem n ready for system testing
15 24 n
7 Integrated subsystems A and B
16 Approved subsystem B 25 Approved subsystem n
8 Integrated subsystems B,C,D
17 Subsystem C approval 26 All subsystems approved
9 Measured A-B integrated performance
18
Figure A.6: Top-level activity map for the subsystem engineering stage. There is a great deal of complexity not shown
in this map related to the engineering of each individual subsystem. Please refer to Figure A.7 for the detailed top-level
map for engineering a single subsystem.
From
subsystem 30
ass
assignment Create preliminary subsystem test procedures
Create preliminary
subsystem BOM 7
Test component
Determine Identify performance
Create 29
selection criteria candidate set of Evaluate set and subsystem Test
for off-the-shelf off-the-shelf choose best testing design
components components component prototype using
2 3 4 5 6 prototype
Revise 31
component
Fo sys
helf components
su
rm te
selection
all m d
Find any
ya e
dd sig
component that
to n
Identify required will give
performance performance Formally add component to subsystem design 32
8 9 10 28
Identify vital off-the-s
Add to
Identify vital
lf
Use models to subsystem

-she
parameters of 24 design
component 17 23
pon ff-the
Re
performance
vis dra
Rev
Identify Create
ents
e wi
14
com ane o
co ng
engineering component
ise d
m
principles of
po
drawing
nd
ne
esig
component
mu
n
Determine
n
tify
mathematical Find parameter

Check
Iden
relationships between values that give

component
performance and desired
drawing
27 25 33
parameters performance
1 13 16 19 21
Identify vital
custom
components
Identify Identify 22 26
preferences for mundane
subsystem parameters of Select some
performance component working values
Ide om c
cu
15 for mundane
st
Formally add to
nti om
parameters
fy
subsystem
mu pone
18 20 design
nd nts
Design the
an
To necessary
e
mundane
component integration tests
11 12
OUTCOMES
1 Working subsystem Bill of Materials 12 Drawing of mundane component 23 Predicted values for performance measures
2 List of vital off-the-shelf components 13 List of vital custom components 24 Engineering drawing of component
3 Selection criteria for vital component Parameters, constraints, performance, Revised drawing
14 correlations
25
4 Candidate set of off-the-shelf components
15 Subsystem performance preferences 26 Drawing check passed
5 Preliminary component selection

16 Component requirements 27 Checked component drawing
6 Component selection
17 List of vital parameters for component 28 Subsystem design
7 Measured component performance
18 List of mundane design parameters 29 Subsystem prototype
8 List of mundane off-the-shelf components
Engineering models relating parameters to
19 30 Subsystem test procedures
Performance requirements for mundane performance
9 component
20 Selected values for mundane parameters 31 Subsystem design, prototype, procedures
10
21 Selected values for vital parameters 32 Measured values for subsystem
11 List of mundane custom components
22 Values for component parameters 33 Subsystem ready for integration testing
Figure A.7: Top-level activity map for engineering a single subsystem. This map will be repeated for each subsystem.
Included in this map are submaps dealing with mundane off-the-shelf components, vital off-the-shelf components, mun-
dane custom components, and vital custom components. Note that a given subsystem may have zero, one, or more than
one of any or all of these kinds of components.
321
Table A.5: Summary of the system refinement stage.
System Refinement: Integrate the subsystems into a demonstrated, high-quality working system. Refine the design as necessary to
resolve any difficulties encountered during testing.
Measured system Section E of the system present, even if the value performance measures. If a
performance values requirements matrix is N/A? Are all measured few of the targets are not met,
Requirements

acceptable range.
Section F of the
Reports on customer Has the market response
Market response to the The market finds the product
response to the product, as been adequately
product desirable.
measured by surveys, focus assessed?
groups, interviews, or other
direct interaction.
Updated methods used results demonstrating the Are the test methods The tests have been carried
to predict and measure desirability of the product. complete and correct? Is out with sufficient quality and
Tests
the performance of the Plots showing variation of there enough detail for a transferability to provide strong
entire system (or system performance with third party to repeat the evidence for the measured and
product). changes in design tests? predicted values.
parameters.
Model source code with run
Engineering models
results. Input files for
Models

values for system a third party to use them?
Prototypes

used to determine values. Fully functional intended use? Is the
with tests.
measured values of systems for testing fidelity and workmanship
system performance measured values. appropriate?
measures.
purchased parts.
the necessary
Subassembly and assembly The design is sufficiently
drawings and instructions transferable to support the
for all subsystems and the creation of the entire system by
system. Schematic a third party.
Design

compliance with
control?
part of the design.
components
and unambiguous?
Useful tools:
drawings, experimentation, failure modes and effects analysis, fault tree analysis, finite ele-
ment modeling, prototyping, sensitivity analysis, uncertainty analysis.
Following poor experimental procedure; creating new and distracting performance measures;
Common pitfalls:
making poor trade-offs; creating new problems; substituting team judgment for the market.
Run validation
tests
15 16
Make validation
Reassess and prototype
modify system
design 7
(components,
subsystems) To Producibility
14
3 6
From Identify system Reassess and Seek approval
Subsystem weaknesses modify
Engineering requirements Make testing
prototype 13
2 tests as
Make
necessary 11
system 5
prototype
Run 10 12
Assess system
sytem-wide test
4 performance
1
Run
8 performance
9 tests
OUTCOMES
1 System prototype 7 12 System performance assessment
2 Measured system performance 8 Testing prototype 13 System approval
3 List of weaknesses 9 Testing essentials Approved system

14
4 Improved tests and procedures 10 System measured performance
15 Validation prototype
5 Improved requirements 11 Assessment essentials

16 Market response
6 Improved system design
Figure A.8: Top-level activity map for system refinement.

323
Table A.6: Summary of the producibility refinement stage.
Producibility Refinement: Refine the design as necessary to allow a desirable product to be produced in the desired quality and
quantity. Note that this stage is primarily about fixing producibility weaknesses that are identified during production ramp-up.
Requirements

Updated predicted and Part E of the system and
present, even if the value performance measures. If a
measured values of subsystem requirements
is N/A? Are all measured few of the targets are not met,
performance measures. matrix.
acceptable range.
to predict and measure Are the test methods The tests have been carried
results demonstrating the
the performance of the complete and correct? Is out with sufficient quality and
Tests
desirability of the product.

system. Methods used there enough detail for a transferability to provide strong
Reports of producibility
to demonstrate the third party to repeat the evidence for the measured and
challenges and their
producibility of the tests? predicted values.
resolution.
product.
Engineering models
Models
characteristics related to commercial software with Not approved directly; used

producibility. Statistical run results. Excel with tests.
analysis of producibility spreadsheets. MathCAD
challenges (defects, low worksheets. Hand solutions.
rate, high cost, etc.).
Prototypes used to
Pilot-scale production runs
explore possible
Prototypes
with statistical analysis. Do the prototypes

producibility solutions. Not approved directly; used
Producibility studies on demonstrate the solutions
Prototypes used to with tests.
initial product runs and to producibility problems?
measure producibility of
refined design.
revised design.
purchased parts.
the necessary
components included? Is The design is sufficiently
drawings and instructions
Refined definition for the design package transferable to support
for all subsystems and the
the entire system. sufficient to allow a third production by a third party.
system. Schematic
Design

compliance with
control?
part of the design.
components
and unambiguous?
Useful tools: ure modes and effects analysis, fault tree analysis, plan-do-check-act, sensitivity analysis, six
sigma, theory of inventive problem solving, troubleshooting, uncertainty analysis.
Creating new problems; inadequate sample sizes; waiting until this stage to consider pro-
Common pitfalls:
ducibility.
10 9
Assess system
From System 4 performance
Run
performance
Reassess and 6 11 tests
Make initial modify
production requirements 13
run of
products
Reassess and modify Seek approval

1 system design To Post-release
5 12
(components,
subsystems) product
Identify Make
production additional
weaknesses production run
7
2 3 8
as necessary
OUTCOMES
1 Products from production run 6 11 System performance assessment
2 List of weaknesses 7 Products from production run 12 System approval
3 Improved tests and procedures 8 Testing essentials Approved system

13
Figure A.9: Top-level activity map for producibility refinement.

325
Table A.7: Summary of the post-release refinement stage.
Post-release Refinement: Refine the design to improve the desirability of the mass-produced product. This includes items such as
decreasing cost, increasing functionality, and eliminating weaknesses that become apparent after the product has been offered to the
market.
The changes in the market and
product requirements capture
Updated market and
Requirements
the market’s desires.

product requirements,
Updated subsystem and The system meets or exceeds
including the additional Are all of the matrices
system requirements the target values of the system
information that was complete and correct?
matrices. performance measures. If a
learned during this
few of the targets are not met,
stage.
acceptable range.
Are the test methods The tests have been carried
Reports on methods and complete and correct? Is out with sufficient quality and
Tests
to predict and measure

results demonstrating the there enough detail for a transferability to provide strong
the performance of the
desirability of the product. third party to repeat the evidence for the measured and
system.
tests? predicted values.
Engineering models
Models
characteristics of the commercial software with Not approved directly; used

product. Statistical run results. Excel with tests.
analysis of product spreadsheets. MathCAD
weaknesses (defects, worksheets. Hand solutions.
low rate, high cost, etc.)
Prototypes used to
explore possible Do the prototypes
Prototypes
improvements. Production runs with demonstrate both the Not approved directly; used
Prototypes used to statistical analysis. problem and the with tests.
measure producibility of solutions?
revised design.
purchased parts.
the necessary
drawings and instructions The design is sufficiently
for all subsystems and the transferable to support
system. Schematic production by a third party.
Design

compliance with
control?
part of the design.
materials information? Is it clear appropriate.
components
and unambiguous?
ure modes and effects analysis, fault tree analysis, plan-do-check-act, sensitivity analysis,
Useful tools:
six sigma, theory of inventive problem solving, troubleshooting, uncertainty analysis value
engineering.
Ignoring the market; creating new problems; inadequate sample sizes; failure to fully docu-
Common pitfalls:
ment everything.
From
Producibility
Reassess and
modify system
Post-release 6 product
design To Post-release
(components,
13
subsystems)
Evaluate 2 5
performance Reassess and
modify Seek approval
and
producibility requirements Make revised
product on
Identify system production system 12
1 weaknesses tests as 14
necessary 10
4
9 11
Assess system
3 Run performance
performance
7 tests
8 Run validation tests
OUTCOMES (if needed)
1 Product evaluation data 6 11 System performance assessment
2 List of weaknesses 7 Testing prototype 12 System approval
3 Improved test procedures 8 Testing essentials Approved system

13
14 Market response (if needed)
Figure A.10: Top-level activity map for post-release refinement.

APPENDIX B
Human-Powered Water Well Drill
The following case consistency with the language used

study describes a product development throughout other parts of this book1 .
effort to bring clean drinking water Project Client: WHOlives.org
to rural communities in sub-Saharan Africa.
A more detailed case study on the village Engineering Development Team:
drill that articulates the introduction of the WaterDOT, a Brigham Young
village drill into the market can be found at University Capstone team.
C.A. Mattson, A.E. Wood, and J. Renouard,
Project Dates: September 2010 – May
“Village Drill: A Case Study in Engineering
2011.
for Global Development With Five Years
of Data Post Market-Introduction,” 2017, Project Scope: Middle of the opportunity
Journal of Mechanical Design, Volume 139, development stage to the end of the
Issue 6, pages 065001 (10 pages), doi: system refinement stage.
10.1115/1.4036304. This development
effort resulted in a human-powered machine Eight-Year Update: Product is in the
that can drill a 6 inch diameter hole 250 feet post-release refinement stage.
into the ground to access clean drinking Eighty-seven drills have been
water. Throughout this book, the machine produced, and are being used in 33
will be referred to as the human-powered countries across Africa, Asia, and Latin
water well drill, or the drill for short. America. More than 3,400 wells have
been drilled. More than 2.5 million
people are getting water from those
wells.
The purpose of this case study is to provide
enough details regarding the drill so that B.1 Case Study Introduction
the product development theory presented
in Part I of this book can be discussed in Tanzania is one of the many countries in
the context of a real product (the drill). We the world that suffers from extreme poverty.
choose to use the drill as a case study
1
because we have access to nearly all the Much of the information in this chapter was pro-
information related to its development. We duced by the development team as a final project re-
port. To that end, we recognize the team members as
note that in some cases we have made Devin LeBaron, Eric Janmohamed, Jimmy Stacey, Ken
minor alterations to the development team’s Langely, Nathan Toone, Sabin Gautam, and Christopher
original work in order to maintain Mattson (coach).

https://doi.org/10.1007/978-3-030-14899-7
328 APPENDIX B. HUMAN-POWERED WATER WELL DRILL
Figure B.1: The

full system de-
sign being tested
in Tanzania.
Many of the hardships in Tanzania can be and provides clean water for more than
attributed to the lack of clean water. 750 people per well.
Despite the fact that the country is
surrounded by three major lakes and an Unfortunately, many villages lack clean
ocean, and 7% of its area is covered by water wells because the current methods of
fresh water, it is difficult to find clean water drilling in Tanzania are limited to opposite
because the water is contaminated and not extremes. On one extreme, the drilling is
suitable for human consumption. done by a professional drilling rig, which is
too expensive (from 7,000 to 15,000 USD),
Potable, or drinkable, water is the basis for while the other extreme is a homemade
a better life. It is estimated that Tanzanian drilling system, which is unsuccessful
women and children spend an average of 2 drilling beyond 150 feet, where potable
hours a day just collecting water, and it is water is often reached.
common to find people who walk 6 hours
just to find water. In addition to the time Of course, a professional drilling rig can
concerns, 80% of all disease in developing drill to depths sufficient enough to access
countries is caused by bad water. Many of clean drinking water, but it costs upwards
these people die because of the lack of of ten thousand dollars to hire the rig for
medicine and health care. Since these the few days required to drill the borehole.
people are collecting contaminated water, The villages that need these wells cannot
they spend their time being sick, visiting afford to spend this extreme amount of
doctors, and paying for medicine they money. As a result, they turn to homemade
cannot afford. Although the people know drilling systems, which often are
the water makes them sick, they have no insufficient. The primitive, manual methods
alternative. Installing a village water well with which they drill simply cannot drill
dramatically reduces all of these concerns deep enough to access clean water. The
B.2. PROJECT SUMMARY 329
two main homemade (both manual) various soil formations. In an effort to

methods in Tanzania are Hand Augering bridge the gap between expensive
and Rota-sludge. Hand Augering uses an professional rigs and less effective
auger to dig the earth away and is effective homemade systems, it was established that
only in soft soil formations, reaching depths the drill would use existing drill pipe and
of no more than 125 ft. Rota-sludge is a bits from the oil-drilling industry, operate
more effective method because it reaches primarily on manual power, and be portable
the same depths, but is able to work in to move from village to village. Further, the
more diverse soil formations. However, due team determined that in order to break
to limited mechanical advantage and through the rock formations, the drill would
strength of tools, both of these methods are need to supply up to 2,000 pounds of
more practically limited to depths of less downward force, mostly from the drill pipe
than 100 feet. itself, as well as apply a maximum of 1000
foot-pounds of torque to the drill pipe.
In mid-2010, a non-profit organization
called WHOlives.org2 was organized for the Team WaterDOT successfully created a
purpose of providing greater access to design that meets the above requirements.
clean water, better health, and to provide By the end of the project, the design
more opportunity to those who lack the consisted of three major components: the
financial means of achieving it on their structure, the wheel support, and the
own. Accordingly, they have commissioned wheel. The structure was designed to
team WaterDOT to develop a way to bridge withstand loads of up to 6750 pounds
the gap between the village and the water before yielding, which is over three times
by providing a manual water well drill that the weight of 250 feet of drill pipe. The
will enable the people to drill their own wells structure was designed with a low center of
for roughly US$1,500. Intended mainly for mass to prevent tipping and add stability to
developing countries such as Tanzania, the the drilling process. The lifting of the pipe
design needs to be affordable, and also is accomplished through the use of a winch
extremely simple, as no product support or and pulley system. This also allows the
spare parts will be available. operators to control the penetration rate of
the drill bit. The wheel support is able to
stabilize and support the weight of the
B.2 Project Summary wheel (200 pounds). The wheel support
also allows ready access to the borehole
Team WaterDOT has developed a
and the drill pipe underneath the wheel.
human-powered water well drill that will
The innovative design of the wheel consists
provide access to clean drinking water to
of a hub that is permanently attached to the
villages in Tanzania at an affordable cost. A
wheel support and 8 removable spokes.
prototype that represents the design at the
Each of the spokes is pinned in place on
end of the system refinement stage is
the hub, and additional strength is gained
shown in Figure B.1.
from two-foot-long cross braces that are
During the opportunity development stage placed between the spokes. This design
the team discovered that the project would allows for easy transportation and allows
need to be developed in less than 1700 workers to remove spokes for improved
man hours and cost less than US$2,800 to access to the drill string.
manufacture all prototypes combined.
In addition to meeting the quantitative
They also discovered that in order to
specifications for drilling a borehole, the
maximize the likelihood of reaching potable
team’s final design also meets the
water, the six-inch borehole would need to
economic specifications. It is able to be
reach a depth of 250 ft and cut through
manufactured for approximately US$1,600,
2
The WHO in WHOlives.org stands for Water, Health, and since the design consists mostly of
and Opportunity. welded steel, the majority of manufacturing
can be performed in Tanzania. The entire The founders of WHOlives.org shared what
drilling rig can also be easily disassembled they expect from the drill and its
and packed into the bed of a regular sized capabilities. From this meeting, the main
truck or small trailer for transportation to requirements became evident. In addition
remote areas of Tanzania. to the needs outlined by the client,
members of the development team
WaterDOT has verified this design in both
discovered other important needs through
theory and reality. Throughout the design
research and visiting with well drilling
process the team has conducted many
experts. The requirements were evaluated
tests to determine the acceptability and the
by the team and written in a form that
feasibility of each concept. The testing in
facilitated the creation of the requirements
the USA culminated in a final test with the
matrix. Figure B.2 shows a reduced4
fully functional steel prototype in which a
version of the matrix. The reduced matrix
27 foot hole3 was drilled in a sandy soil
shows what the team believed to be the
condition. Including setup, drilling, and
most important requirements.
cleanup, the entire test was completed in a
5 hour period. The system refinement tests The team was able to successfully meet the
in Tanzania involved drilling over 26 feet main requirements outlined at the
through significant rock formations and 130 beginning of the project. As a result, the
ft in sandy soil conditions. These system team’s final design was ready to proceed
refinement tests took 7 days of drilling. through the producibility refinement stage
by WHOlives.org and their manufacturing
In all, team WaterDOT has successfully
partner in Africa. During the earlier stages
designed a human-powered water well drill
of product development, the team put
that can be implemented in Tanzania. This
considerable effort into developing a design
drill is substantially more robust than other
that could be easily manufactured in
manual drilling methods in use in Tanzania.
Tanzania. The development team believes
Also, this drill can be manufactured and
that since the final design consists of
operated for a fraction of the cost of drilling
mostly steel parts that are welded together,
one well with a professional drilling rig.
the drilling rig can be manufactured in
Tanzania without the need of expensive and
B.3 Main Requirements specialized machining equipment
(excluding the pulleys, bearing, and winch,
In September 2010 the founders of which are purchased parts).
WHOlives.org described their desires for
The entire drilling rig can also be easily
the outcomes of this project. They
disassembled and transported in the bed of
explained their work in Tanzania and their
a regular size pick-up truck, which is
plans for the future, including their vision of
approximately 5.5 feet wide and 7 feet
bringing water, health, and opportunity to
long. This falls well within the ideal value of
the people. The team learned that
being transported on a 6 foot by 10 foot
WHOlives.org plans to produce the drills for
trailer. As a whole, the final design costs
a manufacturing cost lower than US$5,000,
approximately $1,600 to manufacture. This
and lease the drills to villages for US$1,500
manufacturing cost fell well below the
per successful borehole. Under the
requirement that manufacturing costs be
assumption that villagers are motivated to
below $5,000.
improve their village, WHOlives.org plans to
have local villagers operate the drill without
compensation. The revenue generated B.4 The Team’s Final Design
from the leases would pay for the drill
manufacturing, the drill maintenance, a The final design is described by the team
local trainer–leaser agent, and other as three major subsystems: the structure,
operational costs of the organization. 4
The matrix has been reduced to maintain readabil-
3
Without a well driller’s permit, the team was not al- ity in the format of this book; the team’s original matrix
lowed to drill beyond 30 feet in the USA. had 68 market requirements and 83 performance mea-
sures.
Product: DRILL

Subsystem: N/A



Ideal Values

Importance
Importance
3
1
1
9
9
9
9
3
3
4 The Drill seals borehole sides to prevent cave-in 3
3
1
9
Upper Acceptable Ideal Lower Acceptable Performance Measures Units
and to descend into the borehole

– 250 100 9 1 Maximum borehole depth ft
B.4. THE TEAM’S FINAL DESIGN
60 45 – 10 2 Time required to cut through 6 inches of rock min

10
the wheel support, and the wheel. The

– 3,000 500 3 Downward drilling force lbs
– 400 200 10 4 Torque applied to drill bit ft-lbs
allows the pipe to be gripped by the wheel

a kelly bar. Since the kelly bar is square, it
team’s final design is shown in Figure B.3.
descending through the wheel is known as

3
The square, yellow pipe shown in the figure

– 100 90 5 Compatable with X% existing drill bits %
– 113 50 6 6 Water pressure down the pipe psi
5 0 – 3 7 Percentage of water that leaks through sides %
– 100 95 3 8 Percentage volume of cuttings removed %
– 36 4 3 9 Depth cut per 8 hours of drilling ft
12 3 – 9 10 Number of required people people
400 50 – 9 11 Weight of heaviest subassembly lbs
96 48 – 9 12 Longest dimension (l,w,h) of biggest subassembly in
– 100 85 9 13 Percentage of drill manufacturable in Tanzania %
5,000 1,000 – 9 14 Cost to produce 1 drill after development USD
20 4 – 9 15 Time required to learn how to operate hr
5 3.5 2 1 16 Height of hand operated parts ft
accompanied the design.

– continuously without the occasional rest, and requires 1 17 Feels comfortable n/a
need to rest. Does not awkward movements that
Drill has a professional look. Drill looks like a piece of

4
with the engineering analysis that

– People are interested in 18 The Drill is attractive n/a
machinery for drilling holes.
looking at it.
from rotary table drilling had a large

influence on the form of the rest of the

– investors, is something they 12 19 The Drill interests investors
design. In the subsequent sections each

want to invest in.
simultaneously. The use of this technology
component will be described in detail along

331
drill.
trix (reduced) for
quirements ma-
Figure B.2: Re-
Figure B.3:
CAD rendering
of team’s final
design. This
represents the
design at the
end of the sys-
tem refinement
stage of product
development.
Structure structure has to rotate 36.7 degrees from

the vertical. To cause this rotation a
The structure is composed of 4 parts: a horizontal force of 220 pounds must be
base, two vertical columns, and a applied to the high end of the cantilever
cantilevered beam for lifting the pipe (see beam, or a force of 352 pounds must be
Figure B.3). As depicted in figure, the base applied at the top of the 5 foot column; the
has two horizontal legs sufficiently long and likelihood that these large forces will be
wide enough apart to keep the structure applied to the structure is extremely low.
balanced and stable. The two columns are 3 inch square tubes,
with 1/4 inch wall thickness. This allows
Overall, the base is 47 inches wide and 84
enough clearance to slide into the sleeves,
inches long. It is made of 3.5 inch square
yet strong enough to withstand the applied
tubing, 3/8 inch wall thickness. The size
loads.
and mass of the base structure keep the
center of mass for the whole structure low The cantilevered beam is a 5 inch square
to prevent tipping over. In order to tip, the steel tube that is 7 feet long with a wall
B.4. THE TEAM’S FINAL DESIGN 333
thickness of 3/16 of an inch. The beam has safety factor of 1.5, a wall thickness of
two sleeves of 3.5 inch steel tubing welded 0.188 inches, and a vertical load of 4,500
at a 45 degree angle that allow the beam to pounds.
be slid securely on top of the vertical
columns. The beam is designed to be The winch was then chosen to be able to
pinned to the columns by four 4 inch long lift the weight of the pipe and more. The
clevis pins. The high end is 9 feet above team wanted to ensure that there would
the ground, directly above the borehole. never be any failure of the lifting structure.
Both ends of the beam have a pulley inside, A hand winch with a 3,500 pound first layer
and a winch is attached to the low end of capacity (and a 1,849 pound full drum
the beam. The stranded wire cable from capacity) was selected. This winch has an
the winch goes through the beam and can enclosed gear for protection from the harsh
then hook onto the pipe/kelly bar for lifting. environments of drilling and an automatic
brake, which means that it cannot move
A series of rectangular steel tubing sections unless an operator is rotating the handle
are welded between the legs of the base even with tension in the wire rope.
over the borehole for additional support. Furthermore, at its maximum capacity the
They also provide a rest for the slip plate, operator only has to apply 19.4 pounds of
which is used to secure the pipe while force to the end of the winch handle to
adding or removing pipe sections (this is move the load.
called changeover ).
Pulleys were selected to match the lifting
Structural Analysis of Lifting System capabilities of the winch as close as
possible; however, the pulleys were also
The requirement for the lifting system is to constrained in size by the inside dimension
be able to support and lift the weight of 250 of the beam. Stainless steel pulleys with a
feet of drill pipe. Based on the density of 4.25 inch diameter and plain bronze
steel (490.6 pounds per cubic foot), a pipe bushings were selected. These pulleys
wall thickness of 0.25 inches, and an outer have an operating capacity of 3,000
diameter of 2.875 inches, the weight of 250 pounds.
feet of pipe is 1,725 pounds. While drilling,
the borehole may cave in on top of the pipe, Wheel Support
thus necessitating the ability to lift more
than the just the weight of the drill pipe. The wheel support is significantly different
than previous designs considered by the
The three major components of the lifting team. It is made of several 3 inch by 2 inch
system are the hoist structure, the winch, rectangular steel tubing sections that are
and the pulleys. Of these components the welded together to make a platform on one
most critical component is the hoist end that the lazy susan bearing and wheel
structure. During development the team can rest on (see Figure B.3). The other end
ensured that the hoist would not yield, even has sections of tubing spaced wide enough
under extreme lifting conditions. Because to fit over the vertical columns of the
of the length of the cantilevered beam, the structure. Two parallel sections slide
highest stresses occur in the beam at the around both columns and are bolted in
junction with the first column. This stress is place. Then two smaller sections six inches
due to a combined bending load and axial above the long sections slide around the
load. Therefore, to select the appropriate long column only and are bolted in place.
beam size, the von Mises stresses were Bolting the wheel support to the columns in
calculated at this point. A simple this manner provides more structural
optimization program was created in Excel stability to the structure and the wheel
to optimize the beam dimensions given a support.
load, a safety factor, and a beam wall
thickness. From this optimization routine a The platform end is 44.75 inches from the
5 inch square steel beam was chosen with ground, which will make it ergonomically
the yield strength of steel as 50,000 psi, a ideal for an average height operator to turn
the wheel. The platform is 12 inches wide assembled and taken apart for
with ample space in the middle for the kelly transportation. Additionally, the weight of
bar and pipe to slide through. The only the wheel, especially the solid steel handles
load that will be placed on the wheel at the end of the spokes, provides enough
support is the weight of the wheel itself. inertia for the wheel to maintain a
continuous motion and act as a flywheel.
Wheel
The wheel is made up of a central hub and Twist and Torsion of Drill Pipe
eight spokes (see Figure B.3). The hub With the wheel applying a constant torque
consists of eight 4 inch long sections of 3 to the drill pipe, it is possible that some
inch by 2 inch rectangular steel tubing that angle of twist will develop through the
are spaced evenly in an octagonal pattern length of the drill pipe. This can cause
with the open ends facing outward. These unwanted wind-up that could potentially be
form sleeves for the spokes to be inserted dangerous if the wheel were suddenly
and are sandwiched between two 1/4 inch released. Therefore, calculations were
thick octagonal plates that are 12 inches performed to determine the twist angle with
wide. The plates have 4.1 inch square 250 feet of pipe and a maximum torque of
holes in the middle that are aligned for the 1000 foot-pounds, which corresponds to
kelly bar to slide through. All components three operators exerting 111 pounds of
of the hub are welded together for force at the edge of the wheel. In the
robustness. A small piece of metal is limiting case where the drill bit is held
welded to the inside bottom lip of each of stationary, 49 degrees of twist will develop
the open tubing sections of the hub to in the pipe. This would result in the wheel
prevent the spokes from sagging. The unwinding a bit more than 1/8 of a turn,
wheel hub is then attached to the wheel which means that at most one spoke will
support by a thrust bearing allowing the pass by the operator. In addition, with use
wheel to spin freely. of a winch and the subsequent upward
The spokes are 1.5 inch by 2.5 inch force that can be applied to the pipe, the
rectangular tubing sections with a length of situation in which the drill bit is held
3 feet. One end fits into one of the sleeves stationary can be avoided.
of the hub and is pinned in place. The
other end has a handle consisting of an Change-over Process
11.5 inch long by 1.25 inch diameter solid
steel rod going through the middle The change-over process has gone through
perpendicular to the main axis of the many improvements since the team’s
spoke. The diameter of 1.25 inches is previous designs. The largest change that
ergonomically optimal for a power grip. The has occurred is changing the 6 foot
handle is centered on the spoke with 5 sections of pipe to 3 foot sections, and the
inches protruding on each side of the kelly bar has also been reduced from 7.5 to
spoke. The purpose of this is to 3.67 feet. This allows a quicker changeover
accommodate people of different heights and more manageable parts for manual
working on the drill. The outside end of the labor.
spoke is closed and deburred for safety.
For additional support of the wheel spokes, When drilling starts, the kelly bar is almost
a 2 foot piece of 1 inch by 1 inch by 1/8 completely above the wheel. As the drill
inch angle iron is pinned as a cross brace cuts, the kelly bar and pipe will lower until
between all the spokes. the top of the kelly bar is level with the top
of the wheel hub. Then the winch operator
The six foot diameter of the wheel provides lifts the pipe until the slip plate can fit
enough torque to drill efficiently in all soil under the coupler and over the base (see
types while still maintaining its portability. Figure B.4). After unthreading the kelly bar
The spokes are not permanently attached from the drill pipe, the kelly bar is raised
to the hub so that the wheel may easily be until it reaches the top of the cantilever
B.5. EXPLORATORY TESTING 335
can remove the cuttings from the borehole.

This process occurs by pumping a viscous
slurry down the hole through the center of
the drill pipe. The slurry then returns
through the annulus between the borehole
wall and the pipe with the cuttings created
by the drill bit. This process can remove
any type of cuttings by adjusting the
viscosity of the slurry. WaterDOT’s drill
design uses drilling fluid consisting of a
Figure B.4: Photo of the slip plate (yellow) holding mixture of bentonite and water, mixed at a
a coupler and the drill string (extending vertically ratio to provide the desired viscosity. Since
below it). The kelly bar is unscrewed from the drill the cuttings are typically denser than the
string and lifted. A new pipe segment is added drilling fluid, a combination of buoyant
between the coupler and the kelly bar. force and shear stress acts on the cuttings
to propel them to the surface.
beam. A new 3 foot pipe section is then This results in pump requirements that can
placed between the kelly bar and the pipe provide the necessary flow rate and fluid
(see Figure B.4). The new section is pressure. A flow rate of 50 to 100 gallons
threaded onto the pipe, and then onto the per minute is sufficient to create the
kelly bar. This is done under the wheel by necessary shear stresses on the cuttings
one operator holding the pipe with a pipe and remove the cuttings at a quick enough
wrench and the other operators tightening rate. In order to provide adequate
the kelly bar by turning the wheel (as the pressure, the pump needs to provide one
drill runs, the pipes will fully tighten). A foot of pressure head for every foot of depth
wrench stop has also been welded to the of the borehole. This equates to a pressure
base so that the operator does not have to of approximately 100 psi at a depth of 250
supply the resistance to loosen or tighten feet. Using these pump specifications, a
the pipe. The pipe is lifted slightly, the slip pump power curve was created to
plate is removed, the drill string is lowered, determine the feasibility of operating a
and drilling continues. pump with human power. The resulting
curve is shown in Figure B.5.
Pump
The final design of the drilling rig does not B.5 Exploratory Testing
include a human-powered pump. The
second major prototype made by the team The team’s final design was only reached
included a prototype of a treadle pump after considering and testing many ideas.
system; however, due to time constraints, Throughout the product development
the design of the treadle pumps could not process, the team conducted tests to learn
be more fully developed. In conjunction more about the difficulties of drilling and to
with the sponsor and team coach, it was determine if the selected concepts would
determined that the necessary analysis and meet the requirements. In all, the team has
development of a pump would not be able drilled holes 7 separate times, 2 as proof of
to be satisfactorily completed in the allotted concepts in Utah, 1 in clay in Utah, 1 in
time. Although the treadle pump is still a cobblestone in Utah, 1 in sand in Utah, one
feasible concept, designing and building a in rocky soil in Tanzania, and one in sandy
pump has been eliminated from the scope soil in Tanzania.
of the project.
Proof of Concept Testing
Drilling Slurry and Pump Requirements October 2010: The first idea that was
In order to operate an effective mud rotary proven through testing was the ability to
drill, a drilling fluid must be utilized that turn the pipe by walking in circles around
Figure B.5:
Wheel Power Curve Pump Power Curve
Pump power
2500
requirements. 2 Operators
160
1 Operator
4 Operators 140 2 Operators
2000 6 Operators 3 Operators
8 Operators 120
4 Operators
Flow Rate (gpm)

Torque (ft∙lb)
100
1500
80
1000 60
40
500
20
0
0 10 20 30 40 50
0 5 10 15 20 25 30
Slurry Pressure (psi)
Rotation Rate (RPM)
the pipe. The test was very simple. A drill between pushes. This made for a smooth
bit was spot welded to a pipe, and using operation. The diameter of the wheel was a
pipe wrenches to grip the pipe, the pipe good size to operate and it would easily
was turned. During this test, 1 inch of enable operators to apply enough torque.
depth was drilled in 10 minutes (see Figure
B.6a). A similar test was performed with
weights resting on top of the drill bit to Drilling in Clay
provide downward cutting pressure (see December 2010: After the proof of concept
Figure B.6b). tests, the fully functional wooden prototype
Before these simple tests, the team was finished. The team faced some
envisioned a system that would have the difficulty finding a location where property
workers walk around the pipe twisting it as owners would allow holes to be drilled into
they walked in circles. However, while the ground. The team used the property of
testing these early-stage prototypes the one of the team members as the first place
idea that it would be much easier to be to test the prototype (see Figure B.6d). This
stationary and pass the wrench around was location was selected because of ease of
developed. This idea was taken forward access to water and because the soil
into the development of the first fully conditions were known (known to be clay).
functional prototype. Parts of design that were specifically being
tested were the pumping system, the
November 2010: The first fully functional wheel, and the amount of downward
prototype was made of wood (see Figure pressure needed to drill. Through 24
B.6c). This was done to reduce cost and minutes of continuous drilling a hole 29
decrease manufacturing time. A six foot inches deep was drilled. From this test, the
wooden wheel was used to harness human team learned that one treadle pump could
power to turn the pipe. This wheel had not provide enough flow to lift all of the
vertical handles and was pushed along by cuttings out of the borehole. This caused
up to 6 workers that could stand around it the drill to get stuck easily and increased
in a circle. This design could be both the effort required by the operators to turn
operated with minimal effort and apply the wheel. When extra downward pressure
large amounts of torque to the drill pipe. was added the drill dug a little faster at first,
This prototype was first tested in a small but then the bit became stuck. It was
hole to ensure its feasibility. It met the determined that the ability to remove the
team’s expectations. The inertia of the cuttings needed to be improved by adding
wheel was able to keep the drill spinning in a second treadle pump before the next test.
Figure B.6: Field tests of drill system, in sequence of product development. a) Simple walk-around-in-a-circle proof of
concept test in October 2010. b) Simple test with downward force and bit rotation. Test occurred in October 2010.
c) Wood prototype for testing rotating bit by large wheel. Test occurred in November 2010. d) Wood prototype tested
with treadle pump in clay. Test occurred in December 2010. e) Wood prototype tested in cobblestone soil with gasoline
fueled mud pump. Test occurred in January 2011. f) Steel prototype tested in sandy soil. Test occurred in March 2011.
g) Final prototype tested in rocky soil with local workforce. Test occurred in Tanzania in May 2011. h) Final prototype
tested in sandy soil with local workers. Test occurred in Tanzania in May 2011. i) Use of refined production units by
WHOlives.org.
Drilling in Cobblestone
January 2011: The next two tests were
located at All American Gardens, a BYU
property near the main campus in Provo,
where the soil was known to contain rocks
varying in diameter from 0.5 inches to 4
inches (see Figure B.6e). The team refers
to this soil condition as cobblestone. These
tests were performed on two separate days
using the wooden prototype. In these tests
a second pump was added and bentonite
was used to thicken the drilling mud. This
was done in hopes that the cuttings would
be removed more effectively. However, Figure B.7: Photo used as evidence that the drill
was capable of cutting rocks.
during the second test both treadle pumps
failed because they could not generate the
pressure needed to move the thick slurry.
To keep the test going, the team rented a
mud pump and evaluated other aspects of
the prototype.
The first 4 feet of digging was very similar to
the test in clay, but then the cobblestones
were encountered. The cobblestones made
the drilling slow and arduous and it became
difficult to measure progress. Since there
was no way to lift the drill bit off the bottom
of the borehole, the cobblestones were
simply moved around instead of being cut
through. Despite the slow progress, the
prototype was able to drill through rock and Figure B.8: Photo used as evidence that the slurry
pull up the cuttings with a mud pump. was capable of lifting the cuttings out of the bore-
From the borehole a rock was pulled that hole.
had the profile of the drill bit deeply carved
into it (see Figure B.7), and the settling
pond contained shovels full of gravel.
These were taken as proof that the drill had Tanzania, a gas-powered pump will be
drilled through and removed rock (see used to pump the drilling slurry. Although
Figure B.8). During these tests it became this uses a consumable fuel, it will use
apparent that the design made it hard to drastically less fuel than a conventional rig.
access under and around the table to add
and remove pipe. This resulted in
modifications to the design. Drilling in Sandy Soil
The team decided that the final design March 2011: The final test in the USA with
needed to include a way to remove the the steel prototype was performed in Terra,
wheel to provide greater access in and UT, in sandy soil condition (see
around the pipe interchange area. Also, the Figure B.6f). In all, 27 feet was drilled in
hoist should always be in place so that the 1.5 hours. The actual time the drill was
pipe could be lifted and lowered while spinning was 21 minutes. The average time
drilling. At this point it was also decided to for adding a new pipe was 2.5 minutes.
remove the human-powered pump from Extrapolating from this data it is calculated
the scope of the project. For the initial that it would take 11 hours to drill 250 feet.
implementation of the drilling rig in This number may be optimistic, because it
assumes that no problems will be drilling. The team broke through some
encountered with increased depth that rocks and encountered others. On the
have not already been encountered. most difficult day of cutting through rock
However, a professional driller who was the team cut 53 inches of rock. A 27 foot
present at the test stated that there is no hole was created as part of this test.
reason to believe that it becomes harder to
dig with increased depth. This makes the In the end, the local workers had little to no
11 hour estimate more feasible. trouble understanding the drill and how to
use it. Also, the drill continued to dig
The ability to raise and lower the pipe while through rock the entire time, albeit slowly in
drilling was an important part of this some cases. The team showed that the drill
success. When the drill string’s (all pipes can indeed dig through rock at a rate that is
and cutting bit) full weight was resting in consistent with the client’s goals.
the hole, the drill would dig too fast and the
wheel would become very hard to turn. The Drilling in Sandy Soil in Tanzania
winch was used to control the rate of
penetration. This made the drill easy to May 2011: The final test performed by the
keep at a constant 30 RPM. Being able to team was to dig as deep as possible in the
keep a constant rhythm while spinning the time remaining in Tanzania. The goal was
wheel greatly increases the human power to test the functionality of the pump at
sustainability. depths beyond 100 feet, and to observe the
difficulties that exist the deeper the bit
Before this test, the process of adding new travels.
pipe had only been tested once at the All
American Gardens. The procedure was The team found a sandy soil formation a
very difficult, dangerous, and took the few hours outside of Arusha Tanzania, in
entire team to perform. One of the main the small town of Magugu (see
purposes of this test was to evaluate our Figure B.6h). The dig through sand was
pipe changing procedure. In the current simple and straight forward. After just a few
version of the design, the team made the hours, the local workers were handling the
pipes smaller, for easy handling, and entire operation. The pump continued to
cleared out space to work underneath the work beyond the depth the team had
wheel. During the testing it was very easy to predicted it would fail. The team had
change the pipe with only two people. planned to put two pumps in series, but
Overall the results were very pleasing. this was not necessary.
From the test, the team observed that the
Drilling in Rocky Soil in Tanzania structure worked well and that with small
improvements it would have no trouble
May 2011: The first test in Tanzania used a meeting the client’s requirements. The part
refined version of the steel prototype that began to yield in the design was the
described above. The test was performed shaft that held the pulley at the top of the
on the outskirts of Arusha Tanzania (see beam. This particular part of the product
Figure B.6g). The goal of this dig was to needs to be refined. Also, by standard
evaluate the challenges of training the local drilling procedures, the drill string should
workers how to use the machine. It was be pulled up each night to avoid seizing the
also to see how the drill would do digging bit. An unanticipated issue related to this is
through rock formations. The team was that the deeper a team digs each day, the
fortunate to encounter a professional well more time needs to be reserved to remove
driller, who showed us where to dig to the drill string, and the more time is needed
encounter rocks. The first few meters of the next morning before actual digging can
digging were simple and completed without begin since the string needs to be lowered
difficulty. The team encountered rock, just into the hole.
as predicted, and the drilling slowed
significantly. At its slowest the drill cut 0.75 In the end, a 140 foot hole was created as
inches of rock in one hour of continuous part of this test.
B.6 Team Conclusions and Team WaterDOT has successfully met the
Recommendations requirements of designing and building a
human-powered water well drill that is
Throughout the course of the development capable of reaching underground potable
process many improvements have been water. This success is measured by
made to the design to ultimately create a meeting the functional specifications. The
design that can efficiently drill a borehole. final prototype was manufactured for
Through testing, it has been determined $1,600 USD and is easily disassembled
that the current design is capable of drilling into pieces that can fit in a truck bed or a
in several soil types including clay, sand, small trailer. Furthermore, the rig is able to
loose cobblestones, and rock. Although at successfully drill in many soil conditions. In
times the progress may be slow drilling all, the team has developed a product that
through rock, the drill remains capable of can be successfully implemented in
cutting. The drill is also affordable, easily Tanzania and bring clean water to villages,
transportable, and robust, meeting the improving the quality of life for potentially
main requirements. thousands of people.
Although team WaterDOT has successfully

met the functional specifications, there is
still room for the design to be improved.
There are three main areas that can be
considered for improvement:
manufacturability, safety, and cost. As a
whole the manufacturing of the device is
accomplished with simple operations;
however, there are a few components that
are manufactured using mills. Ways to
eliminate the need for these more complex
operations can be sought. The device also
contains many exposed moving parts,
which can be better shielded to prevent the
possible pinching of operator’s body parts.
Finally, ways to reduce the overall cost of
the device should be explored.
In addition to these three main areas of

overall improvement, the team
recommends that tool joints be used at
every pipe connection to improve
change-over and prevent over-tightening of
joints. Also, a second slip plate can be
added to introduce redundancy to better
prevent the pipe from falling down the
borehole during the removal of pipe. A
sealed thrust bearing can be used between
the wheel hub and the wheel support to
protect against corrosion and to improve
the performance of the wheel. Finally, the
wheel can be improved by employing a
unidirectional mechanism that can prevent
the wheel from being spun in the wrong
direction and employing a method of
stopping the wheel while it is turning.
APPENDIX C
Product Development Terminology
Terms used in this book are defined below. Approvers often include the client and
While we have tried to keep definitions organizations in the development
consistent with accepted usage, in some company outside the development
cases words have several different team. Very rarely will the market act as
meanings. an approver; the market input is
obtained during validation testing.
Our usage throughout the book is
consistent with these definitions. Architecture (n): The arrangement of and
interface between major parts and
subsystems of a concept or system.
Acceptable limits (n): Limits on the value As used in this book, the product
of a performance measure that define architecture consists of a concept, a
the boundaries of a desirable product. definition of its major subsystems, and
If a product has performance above a definition of the interfaces between
the upper acceptable limit or below subsystems.
the lower acceptable limit in a given
measure, the product will not be Artifact (n): An object made by the product
desirable, regardless of how well it development team as a transferable
performs in other measures. result of their work. Also referred to as
a product development artifact. In
Approval (n): A statement given by the general, there are three classes of
project’s approvers that the desirability product development artifacts:
and transferability of the design are requirement artifacts, test artifacts,
sufficient to move on to the next stage and design artifacts.
of development. Approval will
generally be given the design has been Bill of materials (n): A design artifact, in
transferably demonstrated to meet the form of a table, listing each
market requirements through the component comprising a design. The
evaluation of artifact checks, bill of materials generally includes
performance testing results, and information beyond the name of the
validation testing results. part; for example, it can include the
material of each part, the cost of each
Approver (n): A person or organization part, part number, approved vendors,
charged with granting approval at the and so on. It is often organized in a
end of a development stage. way that makes it clear which

https://doi.org/10.1007/978-3-030-14899-7
342 APPENDIX C. PRODUCT DEVELOPMENT TERMINOLOGY
components comprise each development along with requirements

subassembly. and tests.
Checks (n) as in artifact checks: The Design (v): The act of advancing a design
evaluation of the extent to which a (n) through the stages of development.
product development artifact Note that to avoid confusion, we do
representing requirements, tests, or not use the word design as a verb in
design is complete, unambiguous, this book.
transferable; accurately conveys the Design activities (n): Actions the
nature, scope, or meaning intended by development team or development
the product development team; and team members take to advance the
complies with applicable artifact product design through the stages of
standards. development.
Client (n): The entity paying for or Designer (n): One who engages in product
otherwise driving the product development activities. Also called
development effort. In most cases it is product developer.
someone other than the end user.
Desirable (adj): Wanted or wished for as
Component (n): A low-level, often lowest being attractive, useful, or necessary.
level, part in a subsystem or Used here to mean that the
subassembly. quantitative and qualitative product
performance are sufficient to entice
Concept (n): A means for achieving a customers to purchase the product.
design outcome or meeting a design
requirement, where enough detail is Idea (n): An indefinite or unformed
provided about the spatial and conception.
structural relationships of the principal Ideal values (n): The values of the
subsystems that basic cost, size, performance measures for a product
weight, and feasibility estimates can that the market would like to have,
be made. neglecting any required trade-offs.
Coordination interval (n): The smallest Ideal values generally comprise an
period of time between team or ideal value and one or both of an
subteam coordination actions. upper acceptable limit and a lower
acceptable limit.
Customer (n): An individual who is likely to Market (n): The group of customers who
purchase or has purchased the are interested in the purchase of a
product. A customer is a member of product.
the market, and may be part of the
market representatives. The customer Market opportunity (n): The set of
is often an end user. requirements that define what the
market would like to have in a product.
Decomposition (v): The act of breaking The market opportunity also comprises
something down into simpler performance measures for the
constituents. requirements, requirement–measure
relationships, and ideal values.
Design (n): The definition of the product
that will eventually be transferred to Market representative (n): An individual or
the production system and used to group of people chosen to represent
determine what product is made. The the market for purposes of defining
design also includes any testing and evaluating product desirability. In
procedures and performance most cases, the best designs result
measures necessary to verify the when the market representative
quality of the produced product. The consists of individuals outside of the
design evolves throughout product development team.
343
Market response (n): A statement given by Predicted values (n): Values of

the market or the market performance measures that a product
representatives as to the desirability of is expected to have based on testing of
a product relative to the market predictive models.
requirements.
Producibility (n): The measure of the
Market requirements (n): Objective and relative ease of manufacturing a
subjective product characteristics that product that meets market
determine the desirability of the requirements. A highly producible
product to the market. product should be easily and
economically fabricated, assembled,
Measured value (n): The value of a inspected, and tested with high quality.
performance measure that has been
demonstrated by testing a prototype. Product (n): A tangible item manufactured
by a production system and purchased
Outcome (n): The result of a design by someone to fulfill some need.
activity. In most cases, outcomes in Product development (n): The act of
activity maps describe the state of the advancing a design through the stages
design (or of particular artifacts) that is of development.
expected at the end of the activity
leading to the outcome. Product development process (n): The
plan for advancing a design through
Performance measure (n): A characteristic the stages of development.
of a product that will be measured by
the development team during Project (n): An organized effort to execute
performance testing. This evaluation is the product development process, or
used as an internal measurement that to advance the design through one or
can give guidance about the actual more stages of development.
market preferences.
Project management (n): The act of
Performance test artifacts (n): Artifacts guiding a development project to a
used for performance testing. These successful conclusion. Project
artifacts typically include prototypes management usually consists of
and models based on the current tracking the progress of the design
design. and comparing it with the project plan,
then adjusting activities and resources
Performance testing (n): The evaluation of to ensure timely completion of the
the performance of a design, desired outcomes.
prototype, or product. Measured or
Project planning (n): The act of choosing
predicted values of performance
which design activities to execute,
measures are obtained by
when to execute them, and with what
performance testing. Evaluation of the
resources in order to successfully
design quality is partially based on
complete a project.
how well the tested performance
meets the design targets. Prototype (n): A physical approximation of
the product, in whole or in part, based
Post-release refinement (n): An on the design at the time the prototype
engineering activity that refines the is created.
product after it has been introduced to
the market, including correction of Real values (n): Values for performance
post-release defects, incompleteness, measures that are chosen by the team
documentation, producibility, to best meet market requirements.
reliability, or any other issues that are The real values include the effects of
directly tied to product desirability and trade-offs, recognizing that it is
transferability. generally impossible to meet every
344 APPENDIX C. PRODUCT DEVELOPMENT TERMINOLOGY
market requirement. Real values be applied to prototypes for testing

include a target value, predicted measured performance and to models
values, and measured values. for testing predicted performance.
Requirements (n): Product development Transferable (adj): Able to be used for its
artifacts that capture the definition of intended purpose when delivered to a
desired and measured performance recipient who has no specific
for a product. The requirements knowledge except that which is
comprise market requirements, transferred.
performance measures,
requirement–measure correlations, Validation (n): The assurance that an
ideal values, and target values. They artifact meets the expectations of the
also comprise the predicted and market. It often involves evaluation by
measured values and market a market representative (which is
response. always someone external to the
product development team).
Requirements matrix (n): A matrix used to
display the requirements in an
integrated way.
Stage of Development (n): A portion of the
development lifecycle where particular
effort is placed on creating a specific
set of product development artifacts. A
stage is completed when approval is
given after checking the artifacts to
determine transferability and testing
and validating the performance to
determine desirability.
Stakeholders (n): A person or set of
persons with an interest or concern in
the outcome of the development.
Subsystem (n): A self-contained system
forming a subset of a larger system.
System (n): A set of connected things or
parts forming a complex whole. For
the purposes of this book the system is
the whole design or the whole product.
Target values (n): The performance
measure values hoped-for after
considering the trade-offs between the
various market requirements. Because
the choice of target values takes into
account the trade-offs across
performance measures, they can only
be chosen after a concept has been
selected. This is because the nature of
the concept determines the nature of
the trade-offs.
Tests (n): Methods used to predict or
measure the performance of a product
or its competitors. Tests will generally
Bibliography
Altshuller G, Shulyak L (1996) And Dym C, Little P (2008) Engineering design:

suddenly the inventor appeared: TRIZ, a project based introduction. Wiley,
the theory of inventive problem solving. Hoboken
Technical Innovation Center, Worcester
Griffin A, Hauser JR (1993) The voice of
Avallone E, Baumeister T, Sadegh A (2007) the customer. Market Sci 12(1):1–27
Marks’ standard handbook for
mechanical engineers, 11th edn. IDEO (2003) IDEO method cards: 51 ways
McGraw-Hill, New York to inspire design. IDEO, Palo Alto
Boothroyd G, Dewhurst P, Knight W (2010) Jiao JR, Simpson TW, Siddique Z (2007)
Product design for manufacture and Product family design and
assembly. Manufacturing engineering platform-based product development: a
and materials processing, 3rd edn. Taylor state-of-the-art review. J Intell Manuf
& Francis, Boca Raton 18(1):5–29
Brooks F (2010) The design of design: Kelley T, Littman J (2001) The art of
essays from a computer scientist. innovation. A currency book. Doubleday,
Pearson Education, London New York
Brown T (2009) Change by design: how Miklosovic DS, Murray MM, Howle LE, Fish
design thinking transforms organizations FE (2004) Leading-edge tubercles delay
and inspires innovation. Harper stall on humpback whale (Megaptera
Business, New York novaeangliae) flippers. Phys Fluids
16(5):L39–L42
Budynas R, Nisbett J, Shigley J (2011)
Shigley’s mechanical engineering design, Norton R (2006) Machine design: an
SI version. McGraw-Hill series in integrated approach. Pearson Prentice
mechanical engineering. McGraw-Hill Hall, Upper Saddle River
Education, New York
Osborn A (1963) Applied imagination;
Chase K, Parkinson A (1991) A survey of principles and procedures of creative
research in the application of tolerance problem-solving. Scribner, New York
analysis to the design of mechanical
Pahl G, Beitz W, Feldhusen J, Grote K,
assemblies. Res Eng Des 3(1):23–37
Wallace K, Blessing L (2007)
Cushman W, Rosenberg D (1991) Human Engineering design: a systematic
factors in product design. Advances in approach, 3rd edn. Springer, London.
human factors/ergonomics. Elsevier, https://doi.org/10.1007/978-1-84628-
Amsterdam 319-2
Dieter G (2000) Engineering design: a Pugh S (1991) Total design: integrated
materials and processing approach. methods for successful product
McGraw-Hill series in mechanical engineering. Pearson Education.
engineering. McGraw-Hill, New York Addison-Wesley, Boston

https://doi.org/10.1007/978-3-030-14899-7
346 BIBLIOGRAPHY
Sanders MS, McCormick E (1993) Human

factors in engineering and design.
McGraw-Hill International Editions, 7th
edn. McGraw-Hill Higher Education, New
York
Shah JJ, Smith SM, Vargas-Hernandez N
(2003) Metrics for measuring ideation
effectiveness. Des Stud 24(2):111–134
Tilley A, Henry Dreyfuss Associates (2002)
The measure of man and woman:
human factors in design, vol 1. Wiley,
New York
Ulrich K, Eppinger S (2012) Product design
and development. McGraw-Hill, New
York
Young W, Budynas R, Roark R, Sadegh A
(2012) Roark’s formulas for stress and
strain, 8th edn. McGraw-Hill Education,
New York
Index
approval, 26, 27 concept development, useful activities

approval, obtaining, 31 for, 72
approved vendor list, 172 concept rating, 87
approvers, 30 concept set quality, 85
artifact checks, 27 concept, choosing, 88
assembly drawings, 99 concept, develop strong, 84
consensus, 44
basic design process, 168 constraints, 230
basic measures, 230 controlled convergence, 186
benchmarking, 170 convey, 248
benchmarking, design, 90 conveying, 44
benchmarking, market, 61 cost, 188, 190
benchmarking, technical, 61 cost estimation, 188
bill of materials, 100, 172 cost target, 190
bio-inspired design, 174 creating, 39
biomimicry, 174 creation activities, typical for stages, 91
block diagrams, 99 critical path analysis, 152, 192
board layout, 99 critique, 204
brainstorming, 176 customer statements, 62
Brooks, Frederick, 16
data plot, 219
CAD models, 99, 178 deciding, 42
calculation worksheet, 219 decision making process, explicit, 43
catalog search, 89, 180 decision making processes, 43
characteristics of model solutions, 115 decision making processes, implicit, 43
checking drawings, 210 decision making, individual, 43
choose best concept, 88 decision making, motivations for, 44
classification tree, 85, 184 decision matrix, 44
clear design, 6 decisions, team, 43
co-evolution, 16, 17, 311 decomposition, 71, 90, 194
codes and standards, 182 definition, interface, 78
competitive benchmarking, 170 Delphi method, 90, 196
competitive landscape, 61 dependent characteristics, 52
complete design, 6 design benchmarking, 90
component, designing, 111 design components, 25
computer aided design, 178 design constraints, 230
concept, 71 design critique, 204
concept classification tree, 85 design evolution, 25
concept development, 67 design for assembly, 198
concept development, summary of, 68, design for manufacturing, 200, 204
316 design information, 25, 98

https://doi.org/10.1007/978-3-030-14899-7
348 INDEX
design iteration, 17 FEM, 226

design of experiments, 202 fidelity, 116
design process, 168 financial analysis, 224
design review, 204 finding equations, 117
design structure matrix, 206 finite element modeling, 226
design, clear and complete, 6 FMEA, 220
design, evolution of, 15 focus groups, 60, 228
designing components, 111 functional decomposition, 194
desirability, 5
desirability testing, 30, 313 glossary of terms, 341
destructive tests, 218 goal pyramid, 230
detailed part drawings, 99 goals of product development, 5
determining product expectations, 59 guidelines for experimentation, 218
develop strong concept, 84 guidelines for product-focused
DFA, 198 requirement statements, 63,
DFM, 200 263
DFx, 198, 200
diagrams, block, 99 ICD, 72
diagrams, logic, 99 idea generation, 90
diagrams, piping, 99 idea generation, suggested methods, 91
diagrams, schematic, 99 ideal values, 53
diagrams, wiring, 99 IGES files, 99
dimensional analysis, 208 implicit decision making processes, 43
discovering, 38 importance of performance measures,
documentation, 248 52
drawings, 212 individual decision making, 43
drawings, assembly, 99 information checks, 26, 29, 30, 312,
drawings, checking, 210 313
drawings, part, 99 interface control drawing, 72
DSM, 206 interface definition, 71, 78, 79
interface matrix, 71, 78
ECO, 214 internet research, 232
empirical studies, 202 internet search, 89
engineering change order, 214 interviews, 60, 234
engineering drawing, 39 intuition, 41
engineering models, 113
equations, finding, 117 key success measures, 230
ergonomics, 216
evaluation, 41 level of approximation, 114, 116
evaluation activities, 42 logic diagrams, 99
evaluation matrix, 44
evaluation types, 41 market benchmarking, 61
evaluation, quantitative, 41 market opportunity, 51
existing solutions, 88 market representatives, 59
expectations, determining, 59 market requirements, 52
experimental plan, 116, 218 matrix, interface, 78
experimental summary, 219 measured value, 100
experimentation, guidelines for, 218 method 635, 236
experimenting, 41 mind maps, 238
experiments, planning for, 218 mock-ups, 53
explicit decision methods, 43 model solutions, 115, 116
model types, 115
failure modes and effects analysis, 220 modeling, 40, 113
fault tree analysis, 222 modeling, principles of, 116
INDEX 349
modeling, uses of, 113 predictive models, 113

models, 98 preliminary results, 219
models, characteristics of, 115 presentation graphics, 40
models, engineering, 113 principles of engineering modeling, 116
models, equations for, 117 process design, 9
models, fidelity of, 116 process development, 9
models, physical, 118 producibility refinement, 129
models, planning for, 114 producibility refinement, summary of,
models, predictive, 113 131, 323
motivations for decision making, 44 product concept, 71
multivoting, 87, 240 product development terminology, 341
mundane many, 43 product development, stages of, 25,
309
nature’s design, 174 product ergonomics, 216
nucor’s circles, 242 product expectations, determining, 59
numerical solutions, 117 Product information, 25
product-focused requirement
objective statement, 264 statements, 52, 262
objective tree, 244 product-focused requirement
observational studies, 61, 246 statements, guidelines for,
obtaining approval, 31 63, 263
one pager, 248 project approvers, 30
opportunity definition, 51 project objective statement, 264
opportunity development, 49 project review, 204
opportunity development, summary of, prototypes, 70, 98
50, 314 prototypes, planning for, 118
opportunity, market, 51 prototypes, purposes for, 119
optimal candidate set, 88 prototyping, 40, 266
optimization, 117, 250
overlap of stages, 27 QFD, 268
qualitative evaluation, 41
parts list, 172 qualitative performance measures, 52
patent search, 252 quality function deployment, 268
PDCA cycle, 258 quantitaive evaluation, 41
performance measures, 52, 62, 254
performance measures, importance of, rapid prototyping, 270
52 rate concepts, 87
performance measures, qualitative, 52 recombination, 91
performance measures, units, 52 recombination table, 272
performance testing, 30, 313 reduce solution set, 87
performance tests, 26, 27, 29, 312 rendering, 178
personas, 256 representing, 39
physical models, 118 requirement – measure correlations, 62
piping diagrams, 99 requirement information, 25
plan-do-check-act, 258 requirement statements, 262
planning, 38, 260 requirements, 309
planning canvas, 260 requirements hierarchy, 52, 62, 69, 274
planning for experiments, 218 requirements matrix, 51, 276
planning for models, 114 results, preliminary, 219
planning for prototypes, 118 revision control, 280
post-release refinement, 133 robust design, 282
post-release refinement, summary of,
134, 325 SCAMPER, 284
predicted value, 100 schematic diagrams, 99
350 INDEX
scoring matrix, 286 transferability, 5

screening matrix, 288 transferability testing, 30, 313
search, catalog, 180 TRIZ, 300
sensitivity analysis, 290 troubleshooting, 302
Shewhart cycle, 258
six sigma, 292 uncertainty analysis, 304
sketching, 39, 294 units for performance measures, 52
solid modeling, 40 using solutions, 117
solution characteristics, 115
solution set, 85 validation prototypes, 100
solution set quality, 86 validation testing, 26, 27, 29, 30, 312,
solutions to models, 116 313
solutions, numerical, 117 value engineering, 306
solutions, symbolic, 117 vital few, 42
solutions, using, 117 voting, 43
source code, 99
stage transitions, 26 wiring diagrams, 99
stages of development, 25, 309
standards, 182
statistical analysis, 219
statistical model, 118
STEP cycle, 17
storyboards, 296
stretch goals, 230
structural decomposition, 194
subsystem engineering, 95
subsystem engineering, summary of,
96, 318
subsystem interfaces, 71
subsystem opportunity, 69
subsystem requirements matrix, 69
summary of concept development, 68,
316
summary of opportunity development,
50, 314
summary of post-release refinement,
134, 325
summary of producibility refinement,
131, 323
summary of subsystem engineering, 96,
318
summary of system refinement, 124,
321
surveys, 60, 218, 298
symbolic solutions, 117
system refinement, summary of, 124,
321
target values, 69
team decision methods, 43
technical benchmarking, 61
technical models of concept, 70
tests, 309
theory of inventive problem solving, 300

Product Development

Uploaded by

Copyright:

Available Formats

Product Development

Uploaded by

Document Information

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

Product Development

Uploaded by

Copyright:

Available Formats

Christopher

A. Mattson · Carl D. Sorensen

ISBN 978-3-030-14898-0 ISBN 978-3-030-14899-7 (eBook)

an inexperienced designer, this can be the evolution of the design. We introduce

List of Figures xii

I Product Development Process 1

2 Product Development Fundamentals 13

7 Product Refinement 123

8 Customizing the Product Development Process 141

9 Seven Ways to Become a Better Designer 157

II Product Development Reference 165

11.52 Rapid Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Appendix A Summary of Evolution in Product Development 309

Appendix B Human-Powered Water Well Drill 327

Appendix C Product Development Terminology 341

1.1 Docking station for handheld computer . . . . . . . . . . . . . . . . . . . . 4

2.1 Steps, paths, and milestones . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1 A model of the near finished human-powered water well drill . . . . . . . . . 55

5.1 Subsystem requirements from system performance measures . . . . . . . . 71

5.13 Factors determining solution set adequacy. . . . . . . . . . . . . . . . . . . 86

6.1 Subsystem requirements matrix with measured values . . . . . . . . . . . . 102

7.1 Top-level activity map for system refinement. . . . . . . . . . . . . . . . . . 127

8.1 Scoped Development for Human-Powered Water Well Drill. . . . . . . . . . . 143

9.1 Diverge then converge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

A.1 Evolution during product development . . . . . . . . . . . . . . . . . . . . . 310

B.1 The full system design being tested in Tanzania. . . . . . . . . . . . . . . . 328

2.1 Overview of desirability and transferability testing . . . . . . . . . . . . . . . . 30

3.1 Typical evaluation activities used in various development stages. . . . . . . . . 42

4.1 Summary of the opportunity development stage. . . . . . . . . . . . . . . . . 50

5.1 Summary of the concept development stage. . . . . . . . . . . . . . . . . . . 68

6.1 Summary of the subsystem engineering stage. . . . . . . . . . . . . . . . . . 96

7.1 Summary of the system refinement stage. . . . . . . . . . . . . . . . . . . . 124

A.1 Overview of desirability and transferability testing . . . . . . . . . . . . . . . . 313

Product Development Process

1.1 On the Shelves the production line weeks earlier in China.

© Springer Nature Switzerland AG 2020 3

PRODUCT DEVELOPMENT TEAM

Increasing Level of Detail / Production Readiness

The desirability and transferability of the complete, transferable definition of the

Product Development Activities Evolving Design

***** In fact, we did hundreds of product

four principles of product

© Springer Nature Switzerland AG 2020 13

1) Requirements for achieving A.

-Utilize your advisors.

3) Requirements for achieving C. 3) Requirements for achieving C.

-Address root cause -Address root cause

-Communicate your success -Communicate your success

Initial Revised Second Final

Initial Revised Final

MODELS & First Models Second Models

Initial Revised Final

PRESERVE Figure 2.4:

each day by an indecisive client? Unless evolved to a point of sufficient desirability

The way in which the requirements, the 1. Shrink

skills (described more fully in evolution that occurs when executing a

2.3 The Sequence of Design In this book, we choose to consider the

Craft and revise Search internet

1 Understanding of client wishes 4 Internet research summary 6 Market research summary

2 Project objective statement 5 Benchmarking summary 7 Initial requirements for drill