This will probably be a short review, as it has been some months since I have read the book. This book is really dense with information. Many people find it very difficult and suggest reading his previous book first. In fact at the Kanban Leadership Retreat we had a session called “Dumbing Down Don”. I had read his previous book, reviewed it here and heard the author Don Reinertsen speak probably 3 or 4 times at conferences before I read the book. Also his ideas were already well known to anyone in the “Kanban community”, so I felt well prepared and didn’t find the material particularly challenging. Actually challenging is the wrong word. I didn’t find the book particularly difficult to understand. It does however challenge much mainstream thinking in the area of the economics of product development management, so in that sense it is indeed challenging.
This is probably the best book I have read so far this year. It was an easy 5 stars on Amazon and Goodreads. I continually recommend it as the most important book for anyone using Kanban to read. Assuming one gets training or manages to understand the basics through experience or other sources, I might even consider it more important for Kanban practitioners than David’s book. The third Kanban core practice, Manage Flow, is one of the hardest to grasp, and this book is essentially the guide to this practice.
The biggest takeaway for me was the material on understanding the true costs of product development. Too many places I have worked at think cost is a simple matter of counting the hours a developer spends pushing buttons on a keyboard. This book helps highlight the importance of paying attention to other types of costs, particularly the costs associated with queues and the cost of delay. I also really like the way he brings things back to real numbers, as in financial numbers. That is something many in the agile community for example seem to avoid or at least overlook. In a lot of ways Don Reinertsen reminds me a lot of Tom Gilb. Another concept in the book that has occupied my thoughts lately is the asymmetry of payoff functions. This is the idea that we cannot expect every product to meet our desired expectations, and in fact often only a minority of products can be or should be fully leveraged in order to fund the less successful ones. Basically we should recognise and accept that most of our products will not be hits and kill them as soon as we have invested enough to realise that they will not be hits. The minority of hits should be successful enough to fund the investment in the non-hits. This is standard practice in the pharmaceutical industry for example. The question that haunts me, is how can software development service providers leverage what we know about the asymmetry of payoff functions. Service providers earn the same regardless of the level of success of the product. Could this be changed? Should we price software development services according to the level of success the product reaches in the market? It is a dysfunction splitting the organisation developing the product from the organisation that realises the value of it? One thing I am convinced of is that most software development service providers spend way too much time, effort and money on products that will not meet their market expectations. It still seems unintuitive for a software development service provider to kill a “project” that is not meeting its financial expectations, and this needs to change. Too much development capacity is wasted on such low-value work.
This book is definitely a must-read not just for Kanban practitioners, but anyone involved in developing products, especially at a management level.
Oh that reminds me, another thing that I really liked is that he uses the phrase “Product Developer” in places where we might expect to read “Manager”. He does this all through the book when discussing decisions that need to be made. Now in the real world the old “Taylorist” split between manager-thinkers, and worker-doers still exists. Even in software development. The idea that a e.g. Software Developer will be involved in an investment decision based on concrete financial information is still very foreign, but one that I see as a desirable and necessary future, and the language in this book assumes and hopefully reinforces this ideal future, which really appealed to me.