What do you think?
Rate this book
Managing the Design Factory : The Product Developer's Toolkit
The man who launched a revolution in product development with his bestselling Developing Products in Half the Time is back with a new book that's also certain to be a classic. In Managing the Design Factory Donald G. Reinertsen presents concepts and practical tools that will be invaluable for anyone trying to get products out of the pipeline and into the market.The first book to put the principles of World Class Manufacturing to work in the development process, Managing the Design Factory combines the powerful analytical tools of queuing, information, and system theories with the proven ideas of organization design and risk management. The a methodical approach to consistently hit the "sweet spot" of quality, cost, and time in developing any product. Reinertsen illustrates these concepts with concrete examples drawn from his work with many leading companies across different industries.Fresh and thought-provoking, the book challenges many of the conventional approaches to product development. "There are no best practices," Reinertsen writes, "the idea of best practices is a seductive but dangerous trap." Unlike other books that promote rules and rituals based on benchmarking "best practices," this book focuses on practical tools that account for varied situations. He breaks new ground with a disciplined, quantitative approach for making decisions on critical When should we use a sequential or concurrent process? Centralized or decentralized control? Functional or team organizations?Full of practical techniques, concrete examples, and solid general principles, this is a real toolkit for product developers. Moreover, it is written with the clarity, precision, and humor that are Reinertsen's trademarks. He promises to challenge the thinking of anyone involved in product development.
256 pages, Hardcover
First published October 1, 1997
20 people are currently reading
1019 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 19 of 19 reviews
June 12, 2018
If you are in product development and are in your 40s or 50s, you probably ran across Reinertsen's book on someone's desk at some point. It is a fairly readable book about design and design making that does a decent idea of abstracting PLM and manufacturing. Maybe not essential business reading, but nonetheless engaging and insightful.
April 15, 2024
This is a book about product development from 1997, and not only has it aged very well, it is also highly relevant for anyone in software development. While Reinertsen's main focus is the development of physical products, and software products are only mentioned in very few examples, the problem of software development is in fact very similar to product design. This means that the tools he describes are absolutely applicable to the development of software products as well. It's fascinating how many of the tools covered in this book have been adopted in IT and in the startup scene in recent years.
August 23, 2012
Wow! This is one of the most concise books I have ever read. Don manages to introduce a wealth of valuable tools for managing product devlopment. From shaping the organisation to improving testing practices. All with sound theoretical underpinnings in place.
Clear writing, excellent examples and impressive coverage. While you will not get all the latest buzzwords within the agile movement, it is all there. And with everything delivered with sound financial arguments that will get the attention of management at all levels.
Don't take notice that this book is now almost 15 years old, it is still as current as ever.
Now I have to buy Don Reinertsen's flow book.
Clear writing, excellent examples and impressive coverage. While you will not get all the latest buzzwords within the agile movement, it is all there. And with everything delivered with sound financial arguments that will get the attention of management at all levels.
Don't take notice that this book is now almost 15 years old, it is still as current as ever.
Now I have to buy Don Reinertsen's flow book.
March 3, 2020
Originally published back in 1997, Managing the Design Factory contains many ideas that nowadays are considered common sense and widely understood in the realm of product development.
The recurrent theme of the book is that there is no such a thing as best practices in product development that work universally irrespective of the context. There's a wide array of options which all have different impacts on the economics of the business, and it is only by understanding what the optimizing goal is for our business that we can make sound decisions.
I did really like the book, however I felt it was mostly based on the WHAT (ideas and principles) and WHY with very little on the HOW (for example, how to generate economic models... although Reinertsen points at the end of the book to involve the finance department to help with this). As such, I think the ideas included are invaluable, but to explain and adopt to the wider organization would require a lot of more work on the reader part.
The recurrent theme of the book is that there is no such a thing as best practices in product development that work universally irrespective of the context. There's a wide array of options which all have different impacts on the economics of the business, and it is only by understanding what the optimizing goal is for our business that we can make sound decisions.
I did really like the book, however I felt it was mostly based on the WHAT (ideas and principles) and WHY with very little on the HOW (for example, how to generate economic models... although Reinertsen points at the end of the book to involve the finance department to help with this). As such, I think the ideas included are invaluable, but to explain and adopt to the wider organization would require a lot of more work on the reader part.
March 1, 2023
Excellent book! I highly recommend this for anyone in an engineering/design field.
Reinertsen does an incredible job of breaking down the process of conceptualizing, prototyping and preparing to manufacture a product. Whether it is a 1 up or high production, much can be learning from his in depth analysis of trade offs.
Reinertsen does an incredible job of breaking down the process of conceptualizing, prototyping and preparing to manufacture a product. Whether it is a 1 up or high production, much can be learning from his in depth analysis of trade offs.
September 21, 2010
The central point of the book is that all decisions should be based on economic indicators, rather than intuition or some other "feeling." All companies exist for "profit, not product" - an interesting comment on how we do business. We talk about producing information & knowledge, which is then used to make economic decisions.
Queuing Theory
Queuing Theory is an important aspect of the Design Factory in that it shows that overloading (or attempting to get 100% utilization of) a variable process will always be unsuccessful.
The author points out that there are plenty of ways to handle this. He discusses three sources of variability: design specifications, resources ($ and human), and schedule. Significantly, he talks about the idea that one must allow one of these to vary. The common method is to fix the specs and resources, thus the schedule must fluctuate. Likewise, a fixed spec and schedule means the resources must be allowed to vary.
The other important aspect of QT is that it suggests smaller "batch sizes" when making transitions in the design process. Large batches essentially lengthen queues, creating more delay potential. When process batch sizes are different, Reinertsen suggests lumping similar-sized batches together. This is most obvious in scheduling activities. Pharma companies have learned this lesson in running many clinical trials in parallel, instead of fewer in series. The risk of failure is worth the potential benefits. The TOC ideas about critical chain and the project buffer really come into play here.
Information Theory
Information Theory tells us about the value of information. In design it helps us decide what experiments will provide the most value. The basic message here is that surprising results provide more information than expected results. If there is never a failure, do we really know the limits of what we have designed?
This also pokes holes in the ideas of "do it right the first time." This is only the right thing when the economics work. Getting it wrong once or twice could be quite valuable, in terms of information gathering.
Feedback Control
The third introductory chapter talked about feedback control as applied to design and organizations. This also leads to discussion of Systems theory and the various loops that Senge discusses in The Fifth Discipline.
The rest
The third & fourth parts of the book discuss the more practical application of these ideas, from organization design, process design, product architecture, product specification, uncertainty & risk.
Queuing Theory
Queuing Theory is an important aspect of the Design Factory in that it shows that overloading (or attempting to get 100% utilization of) a variable process will always be unsuccessful.
The author points out that there are plenty of ways to handle this. He discusses three sources of variability: design specifications, resources ($ and human), and schedule. Significantly, he talks about the idea that one must allow one of these to vary. The common method is to fix the specs and resources, thus the schedule must fluctuate. Likewise, a fixed spec and schedule means the resources must be allowed to vary.
The other important aspect of QT is that it suggests smaller "batch sizes" when making transitions in the design process. Large batches essentially lengthen queues, creating more delay potential. When process batch sizes are different, Reinertsen suggests lumping similar-sized batches together. This is most obvious in scheduling activities. Pharma companies have learned this lesson in running many clinical trials in parallel, instead of fewer in series. The risk of failure is worth the potential benefits. The TOC ideas about critical chain and the project buffer really come into play here.
Information Theory
Information Theory tells us about the value of information. In design it helps us decide what experiments will provide the most value. The basic message here is that surprising results provide more information than expected results. If there is never a failure, do we really know the limits of what we have designed?
This also pokes holes in the ideas of "do it right the first time." This is only the right thing when the economics work. Getting it wrong once or twice could be quite valuable, in terms of information gathering.
Feedback Control
The third introductory chapter talked about feedback control as applied to design and organizations. This also leads to discussion of Systems theory and the various loops that Senge discusses in The Fifth Discipline.
The rest
The third & fourth parts of the book discuss the more practical application of these ideas, from organization design, process design, product architecture, product specification, uncertainty & risk.
January 19, 2010
This revolutionised the way I look at product development (in my case, software development). It brings together systems thinking, information theory and queueing theory to derive a set of tools to manage product design. The tools are there to influence four design factors: expense, unit cost, product performance and schedule.
Everything is based on an economic model, which is the book's real value. There are no hard and fast rules ("no best practices") because different forms of product development (eg software vs processor design) have different economic properties. Even organisational structure is treated according to the product development model.
Everything is based on an economic model, which is the book's real value. There are no hard and fast rules ("no best practices") because different forms of product development (eg software vs processor design) have different economic properties. Even organisational structure is treated according to the product development model.
September 1, 2017
Schwaber in «Agile software development with scrum» pinpointed two valuable ideas: software development is not a defined process and so it should be controlled iteratively, and software development is analogous not to manufacturing (with its repetitious processes), but to product development (with its one-time processes, and where you mostly do thing for the first time, every time). Manufacturing is a phase usually absent in software development.
Linking software development to product development (i.e. designing an airplane or a microwave oven) opened a whole bag of tricks to software practitioners. The name «scrum» itself famously derived from the ten years old article on product development by Takeuchi and Nonaka.
This book – written five years before Schwaber’s one – is a big part of that bag of tricks. If you’ve been studying scrum, agile and recent «lean» literature you’ll find a lot of familiar ideas and practices here. And while scrum often derives it practices from values and principles, almost emotionally rather than rationally, Reinertsen tries hard to derive practices from economic goals and management science (based on good accounting and forecasting, theory of queues, system thinking and information theory). He sometime fails and some connections feel weak and half-baked, yet it’s a refreshing and fruitful point of view. He also never present any practice as «good» or «bad» (like in «agile’s good» vs «waterfall is bad»), but just as more or less consistent with stated economic goals: an attitude that’s thankfully been spreading through the less faith-based counties of the very diverse agile nation.
Here’s a sample of the pleasurable clarity of thought you’ll find in this book (and again, if your familiar with recent literature expect that slight «déjà lu» feeling):
«Accuracy and Feedback
Another important difference between open loop and closed loop systems is how they achieve accuracy. In an open loop system we try to make the process as accurate as possible. We must do this because there is no feedback. In a closed loop system we focus on the feedback loop. This distinction has quite far-reaching implications, because it dictates where we will spend our time as managers. If we are dealing with an open loop system everything must do what it is told, because it is the
only way to achieve the desired objectives. In a closed loop system what is most important is the feedback loop. The quality of our output will depend on the quality of the feedback loop.
Let us illustrate this with an example. Consider two approaches to steering a ship between Los Angeles and Toyko. One approach would be to use an open loop system. We could accurately calculate the course that we needed to follow, point the ship perfectly in that direction, and sail off to the destination. Success in this situation requires a ship that goes exactly in the direction that it is pointed. Unfortunately, this is not very practical because we cannot set and maintain direction accurate to a thousandth of a degree.
A more practical solution would be to lay out a course and buy a global positioning system (GPS). The GPS will tell us where we are in relation to our planned course. If we find ourselves straying from our intended course we will steer back towards the baseline. This is a closed loop system. Feedback on actual position causes us to modify our behavior to come closer to our goal.
Notice where the key control point is in each of these solutions. For the closed loop system we need to accurately assess our current position. If the feedback system which tells us whether we are on track is accurate, then we will achieve our goal. If the GPS breaks then we will fail. If it works, the feedback system will compensate for changes in the environment. If wind or tides blow us off course feedback will allow us to compensate for these changes and reach our goal. The feedback system even compensates for changes in system performance. The ship could drift back and forth from its course and we would still achieve our goal. The key to system performance lies in the feedback loop. In contrast, an open loop system depends on the system to function. The ship must stay perfectly on course to reach its destination.
These general observations contain another subtle implication. We often discover that the key to controlling the feedback loop lies in the accuracy of a single component, such as the GPS. It is usually much easier to assure the accuracy of one component than the accuracy of the entire system. For example, the course of a ship would be affected by the speed of the engines as well as the position of the rudder. The speed of the engines might be affected by the temperature of the ocean, the density of the fuel, the settings of the throttle, and so on. Thus, we get entangled in very complex control problems when we try to control the
entire system, as we do for open loop systems, instead of just controlling the feedback loop, as we do for closed loop systems.
This means it is important for managers who are used to operating with open loop systems to change their focus when they shift to using closed loop systems. For example, with an open loop approach, if you were asking a designer to design a circuit board you would try to constrain all the things that he might do incorrectly. You would give him very detailed instructions and rules to ensure that he would reach his goal. If you were trying to manage the same designer using a closed loop approach, you would request that he work on the design a bit and then come back to see you. Based on what had been accomplished you would provide additional instructions.»
Linking software development to product development (i.e. designing an airplane or a microwave oven) opened a whole bag of tricks to software practitioners. The name «scrum» itself famously derived from the ten years old article on product development by Takeuchi and Nonaka.
This book – written five years before Schwaber’s one – is a big part of that bag of tricks. If you’ve been studying scrum, agile and recent «lean» literature you’ll find a lot of familiar ideas and practices here. And while scrum often derives it practices from values and principles, almost emotionally rather than rationally, Reinertsen tries hard to derive practices from economic goals and management science (based on good accounting and forecasting, theory of queues, system thinking and information theory). He sometime fails and some connections feel weak and half-baked, yet it’s a refreshing and fruitful point of view. He also never present any practice as «good» or «bad» (like in «agile’s good» vs «waterfall is bad»), but just as more or less consistent with stated economic goals: an attitude that’s thankfully been spreading through the less faith-based counties of the very diverse agile nation.
Here’s a sample of the pleasurable clarity of thought you’ll find in this book (and again, if your familiar with recent literature expect that slight «déjà lu» feeling):
«Accuracy and Feedback
Another important difference between open loop and closed loop systems is how they achieve accuracy. In an open loop system we try to make the process as accurate as possible. We must do this because there is no feedback. In a closed loop system we focus on the feedback loop. This distinction has quite far-reaching implications, because it dictates where we will spend our time as managers. If we are dealing with an open loop system everything must do what it is told, because it is the
only way to achieve the desired objectives. In a closed loop system what is most important is the feedback loop. The quality of our output will depend on the quality of the feedback loop.
Let us illustrate this with an example. Consider two approaches to steering a ship between Los Angeles and Toyko. One approach would be to use an open loop system. We could accurately calculate the course that we needed to follow, point the ship perfectly in that direction, and sail off to the destination. Success in this situation requires a ship that goes exactly in the direction that it is pointed. Unfortunately, this is not very practical because we cannot set and maintain direction accurate to a thousandth of a degree.
A more practical solution would be to lay out a course and buy a global positioning system (GPS). The GPS will tell us where we are in relation to our planned course. If we find ourselves straying from our intended course we will steer back towards the baseline. This is a closed loop system. Feedback on actual position causes us to modify our behavior to come closer to our goal.
Notice where the key control point is in each of these solutions. For the closed loop system we need to accurately assess our current position. If the feedback system which tells us whether we are on track is accurate, then we will achieve our goal. If the GPS breaks then we will fail. If it works, the feedback system will compensate for changes in the environment. If wind or tides blow us off course feedback will allow us to compensate for these changes and reach our goal. The feedback system even compensates for changes in system performance. The ship could drift back and forth from its course and we would still achieve our goal. The key to system performance lies in the feedback loop. In contrast, an open loop system depends on the system to function. The ship must stay perfectly on course to reach its destination.
These general observations contain another subtle implication. We often discover that the key to controlling the feedback loop lies in the accuracy of a single component, such as the GPS. It is usually much easier to assure the accuracy of one component than the accuracy of the entire system. For example, the course of a ship would be affected by the speed of the engines as well as the position of the rudder. The speed of the engines might be affected by the temperature of the ocean, the density of the fuel, the settings of the throttle, and so on. Thus, we get entangled in very complex control problems when we try to control the
entire system, as we do for open loop systems, instead of just controlling the feedback loop, as we do for closed loop systems.
This means it is important for managers who are used to operating with open loop systems to change their focus when they shift to using closed loop systems. For example, with an open loop approach, if you were asking a designer to design a circuit board you would try to constrain all the things that he might do incorrectly. You would give him very detailed instructions and rules to ensure that he would reach his goal. If you were trying to manage the same designer using a closed loop approach, you would request that he work on the design a bit and then come back to see you. Based on what had been accomplished you would provide additional instructions.»
May 10, 2024
I worked on a project with a client on the optimization of the R&D department, and I wanted to learn a little about theory in research and development processes.
This is my second book about the topic, and I learned a great deal about the dynamic of the product development and how to increase the pace of the product development process since it means faster income and being competitive.
Author says: "The Design Factory exists for one purpose—the same purpose as the manufacturing factory—to make a profit."
Important thing that I learnt about development is that there are 4 KPI's that every design factory should follow: development expense, product cost, product performance and speed of development.
This is my assessment of the book Managing the Design Factory by Donald G. Reinertsen according to my 8 criteria:
1. Related to practice - 5 stars
2. It prevails important - 4 stars
3. I agree with the read - 4 stars
4. not difficult to read (as for non-English native) - 4 stars
5. Too long (more than 500 pages) - short and concise (150-200 pages) - 4 stars
6. Boring - every sentence is interesting - 3 stars
7. Learning opportunity - 5 stars
8. Dry and uninspired style of writing - Smooth style with humouristic and fun parts - 4 stars
Total 4,125 stars
This is my second book about the topic, and I learned a great deal about the dynamic of the product development and how to increase the pace of the product development process since it means faster income and being competitive.
Author says: "The Design Factory exists for one purpose—the same purpose as the manufacturing factory—to make a profit."
Important thing that I learnt about development is that there are 4 KPI's that every design factory should follow: development expense, product cost, product performance and speed of development.
This is my assessment of the book Managing the Design Factory by Donald G. Reinertsen according to my 8 criteria:
1. Related to practice - 5 stars
2. It prevails important - 4 stars
3. I agree with the read - 4 stars
4. not difficult to read (as for non-English native) - 4 stars
5. Too long (more than 500 pages) - short and concise (150-200 pages) - 4 stars
6. Boring - every sentence is interesting - 3 stars
7. Learning opportunity - 5 stars
8. Dry and uninspired style of writing - Smooth style with humouristic and fun parts - 4 stars
Total 4,125 stars
November 18, 2019
This book offered pretty broad, but specific advice on managing product design cycles, particularly for hardware. The mental models used in this book tend to hail from a more traditional systems engineering background rather than the current agile terminology, but I actually found this to be refreshing because it concretely expresses a process and it lends itself to mathematical expression. The exploration of queues in the design process and their impact on timelines and staffing was particularly instructive.
July 22, 2017
Most of what we consider contemporary Lean/Agile practice can be extrapolated from this work.
For the maths-phobic, an easier read than "Principles of..."
For the maths-phobic, an easier read than "Principles of..."
November 16, 2019
Dense and broad. The kind of book I want to keep on my desk.
April 26, 2021
I had to read this for work - specifically the parts about batching and batch process and some throughput studies.
March 19, 2017
Essential. This book is staying on my desk so I can revisit it regularly. I read this following on from The Principles of Product Development Flow and I found it had even more impact.
January 10, 2017
I'm not product manager, I am a software engineer. Who picked up this book to see what if anything would be practical for me. The first two to three quarters of book was something I could really power read and get a lot out of, but the remainder I've got to say hasn't really stuck because its all application.
For a software developer the chapters and Queuing Theory and Information Theory were very valuable. Especially the former because when it comes to designing large-scale systems you're going to have to schedule jobs. Which will backup or bottleneck if you don't have a proper queuing system, and its absolute nightmare to manage on the fly. In fact, not knowing how to structure it properly just might be the death of your project. So needless to say I'm happy to have found that tidbit in this book.
For a software developer the chapters and Queuing Theory and Information Theory were very valuable. Especially the former because when it comes to designing large-scale systems you're going to have to schedule jobs. Which will backup or bottleneck if you don't have a proper queuing system, and its absolute nightmare to manage on the fly. In fact, not knowing how to structure it properly just might be the death of your project. So needless to say I'm happy to have found that tidbit in this book.
Want to read
May 31, 2015For a book about management, this was a great peek at the methods and psychology of management in a smaller development company. Reinertsen's discussions on leadership are also very informative.
Read
December 20, 2008I've only skimmed this book but it looks to be chock full of good information.
Read
January 22, 2013jyi
This entire review has been hidden because of spoilers.
May 17, 2013
Disappointing
Displaying 1 - 19 of 19 reviews