I recently finished reading "Managing the Design Factory" by Donald G. Reinertsen. I had heard the recommendation multiple times that it was a good idea to read it before reading his newest book "The Principles of Product Development Flow".
It took me a while to read as I had a couple of events come up that I needed to prepare for by putting this book aside and reading some others, so forgive me if the earlier chapters are not as fresh in my mind as they should be. It is a great book and I recommend it. A lot of the ideas currently in the community are based on the fact that product design is different to management and focus on how managers need to think and act in different ways to the manufacturing manager. This book takes a step back and first asks what design managers can learn from manufacturing, and then of course covers what we cannot really apply from manufacturing. This is implied in the metaphor on the title. When I first heard the term "managing the design factory" I thought "no, no, managing design and managing a factory are completely different, this book must be Taylorist or something…". But it isn’t. Everything in it seems to confirm the things we talk about these days regarding the way variability requires a focus on flow and understanding the nature of the work and our capacity rather than simple economies of scale. Once we consider that the book was published in 1997 then we can imagine that the context back then was very different. I wasn’t really involved in the topic back then but I can imagine that the field of design management was probably fairly immature and not yet even tainted by 20th century management thinking optimized for repeatable processes with low variability. I am completely guessing but I imagine the design activities back then were managed in a more ad hoc fashion perhaps by a senior engineer without formal management training. In that context, a book discussing what design managers can learn from the manufacturing world (and what they cannot) makes a lot of sense.
The focus on making decisions based on concrete financial data is one of the important points in this book, as is the idea that design is mostly about the generation of information. Failing tests for example are great because they generate more information than passing ones. It allows us to go back and improve the design. Especially valuable for me as someone involved in software development is the idea that we can modify our decision making process based on whether time to market is more or less important than either total throughput, or reducing costs. With all the hype around Agile and Kanban we sometimes forget that not all software development is a race against competitors, and by realizing that time to market is say less important than other attributes, we can save a lot of money.
There is a good balance between theory and practical tips. Specifically queuing theory, information theory, and systems theory. Everywhere is different after all, and anyone who thinks a simple to-do list of "best practices" is going to optimize product development at their organization is mistaken. You have to understand the theory, and modify the practices to suit your needs. The book doesn’t just pick one situation and describe the practices that suit that situation, rather he covers various topics, and presents various options within each topic that suit different specific needs.
I don’t know if it is a must-read. I certainly got a lot from it, and I expect to really get the most out of it once I have read Flow. I suspect a lot of newer material has already incorporated the real insight of the book. Perhaps if you have some special needs that are not covered by more recent literature on the topic you will find inspiration in this book for maybe diverging from the typical mantras we have all come to accept almost as best practices in say agile or lean software development. I don’t know what things are like in the design and development of non-software e.g. consumer and hardware products for example, but if there isn’t as much new material floating around out there that addresses those needs as their is in the software world, then I could imagine this book is still absolutely current. It is current for software too if I am being honest. Many of the more current books don’t cover everything that this book does.