What do you think?
Rate this book
The Principles of Product Development Flow: Second Generation Lean Product Development
"...the dominant paradigm for managing product development is wrong. Not just a little wrong, but wrong to its very core." So begins Reinertsen in his meticulous examination of today's product development practices. He carefully explains why invisible and unmanaged queues are the underlying root cause of poor product development performance. He shows why these queues form and how they undermine the speed, quality, and efficiency in product development. Then, he provides a roadmap for changing this. The book provides a well-organized set of 175 underlying principles in eight major areas. He shows you practical methods Improve economic decisions Manage queues Reduce batch size Apply WIP constraints Accelerate feedback Manage flows in the presence of variability Decentralize control The Principles of Product Development Flow will forever change the way you think about product development.
294 pages, Hardcover
First published May 1, 2009
593 people are currently reading
7,980 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 - 30 of 137 reviews
March 31, 2010
Don Reinertsen's book is somewhat difficult to review. There are two aspects to a book: the information it contains, and the way in which it is presented, and since my take on these two aspects of so different, I wish to speak about them separately.
In terms of the information contained in the book, it is phenomenal. Reinertsen basically takes the principles of Lean Manufacturing and explains the ways in which they can apply to product development and the ways in which they cannot. For the principles that cannot, the philosophy behind those principles is used to develop new principles for product development. These overall principles are career-changing. There's a good change your product development team is doing things wrong, and this book will show you why and what you should do instead. Information: 5/5.
The manner in which it is presented is another story. The book is dense, dry, and difficult to read. Reinertsen often assumes a level of familiarity with manufacturing terminology, economics, and management theory that readers may simply lack. He warns in his introduction that his book is very technical, but it's worse than that: the book left me in the dark a number of times, unwilling to explain terms that I think only managers or mechanical engineers could understand. It's one thing to use a STYLE that is difficult for non-engineers, but its another thing to use terminology, so I found myself often having to look up information that should have been in the book itself.
The book also comes off as very hand-wavey. Lots of graphs and figures are presented, but the sources of these graphs and figures are never made clear. Sometimes it felt like the book was simply trying to distract me from asking questions with a pretty picture.
The book is strongest when it uses examples and tries to appeal to intuition. When Reinertsen can explain why something just "makes sense", the principle sticks. When it makes no intuitive sense and Reinertsen attempts to "prove" it with graphs, the lack of hard data makes the claims seem dubious. Book: 2/5.
But while the book is difficult to get through and leaves much to be desired in terms of its writing, the information it contains is invaluable. I consider this a must-read for product development companies in the 21st century.
In terms of the information contained in the book, it is phenomenal. Reinertsen basically takes the principles of Lean Manufacturing and explains the ways in which they can apply to product development and the ways in which they cannot. For the principles that cannot, the philosophy behind those principles is used to develop new principles for product development. These overall principles are career-changing. There's a good change your product development team is doing things wrong, and this book will show you why and what you should do instead. Information: 5/5.
The manner in which it is presented is another story. The book is dense, dry, and difficult to read. Reinertsen often assumes a level of familiarity with manufacturing terminology, economics, and management theory that readers may simply lack. He warns in his introduction that his book is very technical, but it's worse than that: the book left me in the dark a number of times, unwilling to explain terms that I think only managers or mechanical engineers could understand. It's one thing to use a STYLE that is difficult for non-engineers, but its another thing to use terminology, so I found myself often having to look up information that should have been in the book itself.
The book also comes off as very hand-wavey. Lots of graphs and figures are presented, but the sources of these graphs and figures are never made clear. Sometimes it felt like the book was simply trying to distract me from asking questions with a pretty picture.
The book is strongest when it uses examples and tries to appeal to intuition. When Reinertsen can explain why something just "makes sense", the principle sticks. When it makes no intuitive sense and Reinertsen attempts to "prove" it with graphs, the lack of hard data makes the claims seem dubious. Book: 2/5.
But while the book is difficult to get through and leaves much to be desired in terms of its writing, the information it contains is invaluable. I consider this a must-read for product development companies in the 21st century.
May 28, 2017
This was sometimes a frustrating read. The author wants this to be a dense reference resource rather than a long explanatory text. This is fine. I can pull out the internet to look up unfamiliar terms. However, I do think that Reinertsen's brevity hurt his core arguments at time. For example, much of the discussion of the impacts of queues depended on details of the M/M/1/� queue. The shape of the conclusions apply to other queueing disciplines, but the equations don't apply exactly. It would have been useful to at least address that.
That said, this was still a highly worthwhile read. It lays out major themes in how to think about product development that offer a more nuanced view than most methodologies do. For example, Reinertsen discuss in multiple contexts the trade-offs between large and small batch sizes. Large batches can be more efficient to process in isolation, but at the cost of increased delay, slower feedback, and slower iteration. In general, Reinertsen believes product development tends to bias too much toward large batches, but he acknowledges that the right queue size depends on the situation.
I'll go into a bit more detail about the major themes of this book, although it's worth noting that there's much more than I can usefully summarize.
The first theme is that decisions should be made based on economic criteria rather than proxy variables. Reinertsen uses life cycle profits as the key economic measure, but the deeper point is that trade-offs should be made based on consideration of the underlying value you're trying to achieve rather than proxies. The example above about batch sizes is a good illustration. It would be easy to declare a principle about what the right batch size is, but instead, the particular economic trade-offs of batches in a particular situation should be taken into account.
The second key theme is queues. By thinking about queues in a mathematically rigorous way, we can better understand the impact of queues and high utilization rates. The key takeaway from the discussion of queues is that as resource utilization goes up, the total amount of time work spends waiting rather than in process goes up dramatically. Depending on the exact queuing discipline, there's generally a fairly dramatic uptick in the proportion of time spent waiting once utilization of the resources doing the work exceeds somewhere between 70% and 90%. Accurately measuring utilization is hard (plus, people tend to think that high utilization is a good thing), and changing it is even harder. It's much easier to monitor and control queue length and queue wait time. The other key observation with respect to queue size is that not all tasks have the same cost of delay. By taking cost of delay into account when pulling work from queues, you'll make better trade-offs than if you use a non-economic discipline like FIFO.
The third key theme is variability. The standard view is that variability is bad. This view comes from manufacturing where tasks themselves are uniform, so economic payoff is maximized when variability is minimized. Product development contrasts with manufacturing in that there is much more inherent variability in the tasks and also much more variability in payoff. Each widget you make gives the same profit, but every new product you develop has different trade-offs for both profit and loss. Instead of focusing on reducing variability, focus on reducing the cost of variability, e.g., through working through risks early instead of late so that less will be invested if the project fails. Importantly, the variability is still here. Some work may work will take much longer than
Theme number four is batch size. Although, as noted above, batching can sometimes be the right trade-off, controlling batch size is one of the key ways of controlling queue size (and, therefore, delay). Batch size tends to have a U-curve relationship to economic costs, with small frequent batches decreasing cost over large infrequent batches up until the point where the fixed-cost overhead per batch dominates the cost. But even then, small batches can be the right choice since the fixed costs can often be reduced and frequent batches provides motivation to do so.
Work in progress (WIP) constraints are one of the primary mechanisms for controlling queue size. By providing local WIP constraints for each queue and not allowing upstream workflows to add work to full queues, over utilization at one workflow can fairly quickly propagate to upstream workflows, leading them to adjust their rate of work production or figure out how to increase the capacity of downstream flows.
Principle number six is the importance controlling flow through cadence and synchronization. Having a regular cadence for work can reduce the cost overhead of smaller batch size. As a tiny example, if a project is reviewed on demand, then setting up the review meeting is a lot of effort, but if a review meeting has a repeated schedule at an appropriate cadence, that cost is lowered. Synchronization often builds upon cadence although it's not the same. Synchronization is the observation that if work is arriving to a queue at a random wait, then wait times will be longer than if the two workflows are syncronized so that the first produces work at approximately the rate at which capacity is available at the next work flow.
Fast feedback sounds like a non-controversial principle, but large queues, large batch sizes, and long delays have the unintended effect of slowing down feedback. This is problematic because fast feedback is especially important when trying to control risk and the cost of variability. An organization that deeply values fast and frequent feedback will structure work differently than one which is focused on maximizing utilization as a measure of efficiency.
The final approach for improving development processes is balancing centralized and decentralized control, erring much more on the side of decentralization than organizations currently tend. This is the section that had the most novel-to-me domain of inspiration: the military. Despite stereotypes, the reality of war is that decentralized groups must be able to make dynamic decisions based on local conditions to achieve a larger objective. To balance centralization and decentralization, Reinertsen suggests using more decentralization for solving frequent, low cost problems where speed is advantageous. Centralization is valuable for infrequent, large problems or when it's significantly more cost effective to centralize decisions. One approach is to assume most problems are amenable to decentralization and then have a well defined escalation process for when that's not the case. For decentralization to be effective, leaders need to make sure that the decentralized decision makers are aligned with the larger organizational goals. Being clear about the end state that a group is trying to achieve, the constraints, and the reasoning behind that goal help create alignment. Transparency in decision making process also helps; leadership in a decentralized organization should consider their job to teach everyone how to make good decisions even more than making good decisions themselves.
This only begins to scratch the surface of the content of the book. Overall, it was well worth the read, and I spent much more time reading it than usual because I kept pausing to think about the principles involved and how they apply to my work.
That said, this was still a highly worthwhile read. It lays out major themes in how to think about product development that offer a more nuanced view than most methodologies do. For example, Reinertsen discuss in multiple contexts the trade-offs between large and small batch sizes. Large batches can be more efficient to process in isolation, but at the cost of increased delay, slower feedback, and slower iteration. In general, Reinertsen believes product development tends to bias too much toward large batches, but he acknowledges that the right queue size depends on the situation.
I'll go into a bit more detail about the major themes of this book, although it's worth noting that there's much more than I can usefully summarize.
The first theme is that decisions should be made based on economic criteria rather than proxy variables. Reinertsen uses life cycle profits as the key economic measure, but the deeper point is that trade-offs should be made based on consideration of the underlying value you're trying to achieve rather than proxies. The example above about batch sizes is a good illustration. It would be easy to declare a principle about what the right batch size is, but instead, the particular economic trade-offs of batches in a particular situation should be taken into account.
The second key theme is queues. By thinking about queues in a mathematically rigorous way, we can better understand the impact of queues and high utilization rates. The key takeaway from the discussion of queues is that as resource utilization goes up, the total amount of time work spends waiting rather than in process goes up dramatically. Depending on the exact queuing discipline, there's generally a fairly dramatic uptick in the proportion of time spent waiting once utilization of the resources doing the work exceeds somewhere between 70% and 90%. Accurately measuring utilization is hard (plus, people tend to think that high utilization is a good thing), and changing it is even harder. It's much easier to monitor and control queue length and queue wait time. The other key observation with respect to queue size is that not all tasks have the same cost of delay. By taking cost of delay into account when pulling work from queues, you'll make better trade-offs than if you use a non-economic discipline like FIFO.
The third key theme is variability. The standard view is that variability is bad. This view comes from manufacturing where tasks themselves are uniform, so economic payoff is maximized when variability is minimized. Product development contrasts with manufacturing in that there is much more inherent variability in the tasks and also much more variability in payoff. Each widget you make gives the same profit, but every new product you develop has different trade-offs for both profit and loss. Instead of focusing on reducing variability, focus on reducing the cost of variability, e.g., through working through risks early instead of late so that less will be invested if the project fails. Importantly, the variability is still here. Some work may work will take much longer than
Theme number four is batch size. Although, as noted above, batching can sometimes be the right trade-off, controlling batch size is one of the key ways of controlling queue size (and, therefore, delay). Batch size tends to have a U-curve relationship to economic costs, with small frequent batches decreasing cost over large infrequent batches up until the point where the fixed-cost overhead per batch dominates the cost. But even then, small batches can be the right choice since the fixed costs can often be reduced and frequent batches provides motivation to do so.
Work in progress (WIP) constraints are one of the primary mechanisms for controlling queue size. By providing local WIP constraints for each queue and not allowing upstream workflows to add work to full queues, over utilization at one workflow can fairly quickly propagate to upstream workflows, leading them to adjust their rate of work production or figure out how to increase the capacity of downstream flows.
Principle number six is the importance controlling flow through cadence and synchronization. Having a regular cadence for work can reduce the cost overhead of smaller batch size. As a tiny example, if a project is reviewed on demand, then setting up the review meeting is a lot of effort, but if a review meeting has a repeated schedule at an appropriate cadence, that cost is lowered. Synchronization often builds upon cadence although it's not the same. Synchronization is the observation that if work is arriving to a queue at a random wait, then wait times will be longer than if the two workflows are syncronized so that the first produces work at approximately the rate at which capacity is available at the next work flow.
Fast feedback sounds like a non-controversial principle, but large queues, large batch sizes, and long delays have the unintended effect of slowing down feedback. This is problematic because fast feedback is especially important when trying to control risk and the cost of variability. An organization that deeply values fast and frequent feedback will structure work differently than one which is focused on maximizing utilization as a measure of efficiency.
The final approach for improving development processes is balancing centralized and decentralized control, erring much more on the side of decentralization than organizations currently tend. This is the section that had the most novel-to-me domain of inspiration: the military. Despite stereotypes, the reality of war is that decentralized groups must be able to make dynamic decisions based on local conditions to achieve a larger objective. To balance centralization and decentralization, Reinertsen suggests using more decentralization for solving frequent, low cost problems where speed is advantageous. Centralization is valuable for infrequent, large problems or when it's significantly more cost effective to centralize decisions. One approach is to assume most problems are amenable to decentralization and then have a well defined escalation process for when that's not the case. For decentralization to be effective, leaders need to make sure that the decentralized decision makers are aligned with the larger organizational goals. Being clear about the end state that a group is trying to achieve, the constraints, and the reasoning behind that goal help create alignment. Transparency in decision making process also helps; leadership in a decentralized organization should consider their job to teach everyone how to make good decisions even more than making good decisions themselves.
This only begins to scratch the surface of the content of the book. Overall, it was well worth the read, and I spent much more time reading it than usual because I kept pausing to think about the principles involved and how they apply to my work.
October 31, 2012
I had very high expectations for this book. I've had it recommended by a number of people - and thought I would really benefit from reading it.
It does add value, but Mr. Reinertsen is making some obvious mistakes that makes me doubt the more valuable parts of the book.
The book's format is inspired by the world of physics, and is providing 100+ principles that to some extend build on top of each other. This unfortunately also means that if one is a fallacy, the rest could be impacted.
Mr. Reinertsen is making false statements, like: "The batch size for production is dictated by set-up time" (p.128). This is not always true. Consider a bakery - the batch size is limited by what can fit into the oven - not how long time it takes the oven to heat. There are multiple similar naïve mistakes, and it could be attributed to Mr. Reinertsen's attempt to write a condense book. Yet it leaves me hesitant to buy the facts at face-value.
The book's main principle is about applying an economic view on decisions. The book clearly explains why - but doesn't address the how (even though it claims to do so in the summary).
Mr. Reinertsen is flaming Goldratt's theory of constraints (TOC) - apparently without understanding it. (p133+134). TOC works perfectly with high variability and outside production (read We All Fall Down: Goldratt's Theory of Constraints for Healthcare Systems, if you doubt). TOC even prescribes smaller batch sizes, as it enables higher utilization of the bottlenecks. The example of the cafeteria on p.133 offers exactly the same solution you would do under TOC. Remember how the utilization of the oven bottleneck got optimized in The Goal: It was run 24/7 and buffers protected it. No one bought a bigger oven. This is equivalent to the staggered lunch hours suggested by Reinertsen - perfect alignment. Yet Reinertsen is bad-mouthing TOC - and suggesting TOC would lead to a different solution. On the very next page Reinertsen attacks the boy-scout parable from The Goal. And again they are in perfect alignment. Reinertsen offers a new example of optimizing utilization of the bottleneck (by having a group run ahead, pave the path and collect water). This aligns perfect with Goldratt's thinking in The Goal: A Process of Ongoing Improvement. Here other ways were mentioned, including carrying some of the bottleneck's load). IMO Mr. Reinertsen didn't have to attack TOC - his points are in perfect alignment with TOC. I think he wanted to prove something new - but he can't.
TOC is the superset of Lean (and Reinertsen's 2nd Gen Lean). TOC is the superset, as it offers clear ways of reaching the results Reinertsen are only hinting at. Including finding none physical bottlenecks, finding right batch sizes, and most importantly how to implement changes. Read We all fall down - where TOC is applied on a hospital - variation is high and unpredictable (the healing time of patients) and the obvious physical bottleneck turns out not to be the bottleneck - but hospital policies. And management gets convinced by economic views, and other stakeholders by sheer down-to-earth logic. And it is based on a true story.
I would have rated this book a 4 star - had the title been: An economic view of TOC, and the book had openly embraced TOC.
To get the last star the book had to be readable - the format is very condensed, making it a quite tough read.
It does add value, but Mr. Reinertsen is making some obvious mistakes that makes me doubt the more valuable parts of the book.
The book's format is inspired by the world of physics, and is providing 100+ principles that to some extend build on top of each other. This unfortunately also means that if one is a fallacy, the rest could be impacted.
Mr. Reinertsen is making false statements, like: "The batch size for production is dictated by set-up time" (p.128). This is not always true. Consider a bakery - the batch size is limited by what can fit into the oven - not how long time it takes the oven to heat. There are multiple similar naïve mistakes, and it could be attributed to Mr. Reinertsen's attempt to write a condense book. Yet it leaves me hesitant to buy the facts at face-value.
The book's main principle is about applying an economic view on decisions. The book clearly explains why - but doesn't address the how (even though it claims to do so in the summary).
Mr. Reinertsen is flaming Goldratt's theory of constraints (TOC) - apparently without understanding it. (p133+134). TOC works perfectly with high variability and outside production (read We All Fall Down: Goldratt's Theory of Constraints for Healthcare Systems, if you doubt). TOC even prescribes smaller batch sizes, as it enables higher utilization of the bottlenecks. The example of the cafeteria on p.133 offers exactly the same solution you would do under TOC. Remember how the utilization of the oven bottleneck got optimized in The Goal: It was run 24/7 and buffers protected it. No one bought a bigger oven. This is equivalent to the staggered lunch hours suggested by Reinertsen - perfect alignment. Yet Reinertsen is bad-mouthing TOC - and suggesting TOC would lead to a different solution. On the very next page Reinertsen attacks the boy-scout parable from The Goal. And again they are in perfect alignment. Reinertsen offers a new example of optimizing utilization of the bottleneck (by having a group run ahead, pave the path and collect water). This aligns perfect with Goldratt's thinking in The Goal: A Process of Ongoing Improvement. Here other ways were mentioned, including carrying some of the bottleneck's load). IMO Mr. Reinertsen didn't have to attack TOC - his points are in perfect alignment with TOC. I think he wanted to prove something new - but he can't.
TOC is the superset of Lean (and Reinertsen's 2nd Gen Lean). TOC is the superset, as it offers clear ways of reaching the results Reinertsen are only hinting at. Including finding none physical bottlenecks, finding right batch sizes, and most importantly how to implement changes. Read We all fall down - where TOC is applied on a hospital - variation is high and unpredictable (the healing time of patients) and the obvious physical bottleneck turns out not to be the bottleneck - but hospital policies. And management gets convinced by economic views, and other stakeholders by sheer down-to-earth logic. And it is based on a true story.
I would have rated this book a 4 star - had the title been: An economic view of TOC, and the book had openly embraced TOC.
To get the last star the book had to be readable - the format is very condensed, making it a quite tough read.
October 23, 2016
I was intentionally postponing reading this book for 2-3 years already. How could I benefit from reading it when I've already digested Anderson, Poppendiecks, ToC classiscs, whole Lean series & many more? I was very persistent in ignoring several, repeated recommendation & it appears that I was wrong.
"The Principles ..." are very different from all the books mentioned above. How come?
1. it clearly states that we can't just copy The Toyota Way as manufacturing is very different to building software products / services - there are several differences explicitly indicated & described
2. it has a very strong background in queuing theory & it utilises it very thoroughly in a way that is not trivial to comprehend, but personally I find it truly revealing (e.g. I loved the considerations regarding the variability - this is NOT the way I was thinking about it until now)
3. book is far from being strictly theoretical - e.g. I like the numerous references to Marines
In short words - this is A-MUST-READ. It's not an easy read (clearly not for everyone either) & you'll need some time & focus to get through it. But in the end, one of the best business books I've ever read.
"The Principles ..." are very different from all the books mentioned above. How come?
1. it clearly states that we can't just copy The Toyota Way as manufacturing is very different to building software products / services - there are several differences explicitly indicated & described
2. it has a very strong background in queuing theory & it utilises it very thoroughly in a way that is not trivial to comprehend, but personally I find it truly revealing (e.g. I loved the considerations regarding the variability - this is NOT the way I was thinking about it until now)
3. book is far from being strictly theoretical - e.g. I like the numerous references to Marines
In short words - this is A-MUST-READ. It's not an easy read (clearly not for everyone either) & you'll need some time & focus to get through it. But in the end, one of the best business books I've ever read.
July 3, 2018
Marvelous 5 star content obscured by sub-par organization and style choices
November 18, 2021
The book is a little tedious to read, but one of the most valuable books on my shelf.
Because it reads more like a scientific paper, speaking always in abstract terms it can give the impression that it's being indirectly rude about "the orthodoxy" (thinly veiled pejorative term used to describe the classical agile methodologies) which is somewhat at-odds with the otherwise fact based writing style.
Ultimately the book talks about a systematic mindset to help understand, measure and visualize healthy systems, where the reader is invited to mentally model their workplace similar to how water- or traffic-systems work, decisions, work, cars or water molecules flowing through a system, and stalling at the intersections.
The book both offers abstract philosophical tools, bicycles for the mind to help unwrap some unintuitive concepts, but also concrete, actionable steps that can be taken objectively to improve the health of a system.
Planning for short work cycles (but not too short), how to plan for delay, how to plan capacity, how to justify a "20% engineering" time, and more can all be justified by taking systematic measurements and applying improvements to keep the system _flowing_.
My main takeaways are that most companies have too much WIP, too much cruft accumulating in issue trackers, and not enough monitoring on latency, or turn-around time for units of work, the industry at large lacks any kind of proper tooling for this, certainly Atlassian's suite falls very very short, although with care, some processes can be developed around these tools which can help solve the problems.
The book starts with strong criticism of agile, but I think that applying the techniques in this book are a great complement to the agile orthodoxy to help systematically prevent some of the problems that can arise in the velocity-arms-race with pushy business stakeholders who are unlikely to be familiar with all the nuance and cultural cues it takes to really apply agile methodologies effectively.
Because it reads more like a scientific paper, speaking always in abstract terms it can give the impression that it's being indirectly rude about "the orthodoxy" (thinly veiled pejorative term used to describe the classical agile methodologies) which is somewhat at-odds with the otherwise fact based writing style.
Ultimately the book talks about a systematic mindset to help understand, measure and visualize healthy systems, where the reader is invited to mentally model their workplace similar to how water- or traffic-systems work, decisions, work, cars or water molecules flowing through a system, and stalling at the intersections.
The book both offers abstract philosophical tools, bicycles for the mind to help unwrap some unintuitive concepts, but also concrete, actionable steps that can be taken objectively to improve the health of a system.
Planning for short work cycles (but not too short), how to plan for delay, how to plan capacity, how to justify a "20% engineering" time, and more can all be justified by taking systematic measurements and applying improvements to keep the system _flowing_.
My main takeaways are that most companies have too much WIP, too much cruft accumulating in issue trackers, and not enough monitoring on latency, or turn-around time for units of work, the industry at large lacks any kind of proper tooling for this, certainly Atlassian's suite falls very very short, although with care, some processes can be developed around these tools which can help solve the problems.
The book starts with strong criticism of agile, but I think that applying the techniques in this book are a great complement to the agile orthodoxy to help systematically prevent some of the problems that can arise in the velocity-arms-race with pushy business stakeholders who are unlikely to be familiar with all the nuance and cultural cues it takes to really apply agile methodologies effectively.
February 7, 2020
This book bears many analogies to product (and software) development that, to me, seem much more suitable than many of the manufacturing parallels that are often made when talking about things like Kanban or the Theory of Constraints, albeit they also still hold their value in certain places.
Nevertheless, the nature of product (and software) development is in many parts fundamentally different than the challenges of optimising a production line, and so are the choices to be made. Using analogies like telecommunication networks, CPU scheduling or multi-level caches when talking about queues, priorities or ressources and response times made much more sense to me in that respect.
Finally, the book does not talk about optimisation just for the sake of optimisation (where optimisation can mean a lot of different things), but always stresses the need for holistically and economically founded choices. As I always strive to keep a systemic view when thinking about organizations and processes, this was something that I additionally appreciated.
While I sometimes wished Donald G. Reinertsen would have diven deeper into some of his thoughts and ideas, his book is already packed with lots of thought provoking information, making it a read that is not always easily to digest, especially while commuting.
Nevertheless, the nature of product (and software) development is in many parts fundamentally different than the challenges of optimising a production line, and so are the choices to be made. Using analogies like telecommunication networks, CPU scheduling or multi-level caches when talking about queues, priorities or ressources and response times made much more sense to me in that respect.
Finally, the book does not talk about optimisation just for the sake of optimisation (where optimisation can mean a lot of different things), but always stresses the need for holistically and economically founded choices. As I always strive to keep a systemic view when thinking about organizations and processes, this was something that I additionally appreciated.
While I sometimes wished Donald G. Reinertsen would have diven deeper into some of his thoughts and ideas, his book is already packed with lots of thought provoking information, making it a read that is not always easily to digest, especially while commuting.
May 11, 2017
I'm a software developer with ten years of professional experience, lately making manufacturing and R&D product development support software. I have not read about lean manufacturing, but I was exposed to some of its practices indirectly in my work at Amazon.
This book was very practical for me. It honors the existing orthodoxy about kanban, lean manufacturing, and Toyota, while carefully drawing distinctions between repeatable production and innovative product development. So it serves as a useful introduction into that field, if only by contrast.
In the software world, all development is innovative product development, because it's so easy to reuse the wheel rather than reinvent it. So this book has many lessons that apply directly to software development.
But it also has great application to my current domain, which is organizing and optimizing rocket manufacturing at Blue Origin. On many pages, I could find an example of received wisdom at Blue Origin that is questioned by the book.
Fortunately, after the author diagnoses the problem (treating product development like manufacturing), he provides many practical solutions, such as measuring and reducing work queues, or promoting fast feedback. These are solutions we will be able to encode directly into the company's software on my team.
The interdisciplinary grounding of the book is very interesting. The author uses lessons from economics, control theory, operations research, queueing theory, the algorithms running the internet, and even the Marine Corps. The portions I was already exposed to, such as lessons from agile software development practice, seem normal and used aptly. It would be hard for me to judge any other area, because I don't have the background. But the book was also a useful entry point into those fields for me, and there's a list of textbook references at the back for Further Reading.
If I have one problem with the book, it's that the author is touching the elephant from so many angles that I don't know if I have received an overall theory of development. Do I understand lean development in a holistic Gestalt? I don't think so. The book contains a list of 175 takeaways, almost its section headings. There are big themes, but the book tends to flatten them where it could have highlighted the most important. I would have liked a final chapter putting it all together, perhaps a case study.
All in all though, I think there are too many gold nuggets on the ground to give this less than full marks.
This book was very practical for me. It honors the existing orthodoxy about kanban, lean manufacturing, and Toyota, while carefully drawing distinctions between repeatable production and innovative product development. So it serves as a useful introduction into that field, if only by contrast.
In the software world, all development is innovative product development, because it's so easy to reuse the wheel rather than reinvent it. So this book has many lessons that apply directly to software development.
But it also has great application to my current domain, which is organizing and optimizing rocket manufacturing at Blue Origin. On many pages, I could find an example of received wisdom at Blue Origin that is questioned by the book.
Fortunately, after the author diagnoses the problem (treating product development like manufacturing), he provides many practical solutions, such as measuring and reducing work queues, or promoting fast feedback. These are solutions we will be able to encode directly into the company's software on my team.
The interdisciplinary grounding of the book is very interesting. The author uses lessons from economics, control theory, operations research, queueing theory, the algorithms running the internet, and even the Marine Corps. The portions I was already exposed to, such as lessons from agile software development practice, seem normal and used aptly. It would be hard for me to judge any other area, because I don't have the background. But the book was also a useful entry point into those fields for me, and there's a list of textbook references at the back for Further Reading.
If I have one problem with the book, it's that the author is touching the elephant from so many angles that I don't know if I have received an overall theory of development. Do I understand lean development in a holistic Gestalt? I don't think so. The book contains a list of 175 takeaways, almost its section headings. There are big themes, but the book tends to flatten them where it could have highlighted the most important. I would have liked a final chapter putting it all together, perhaps a case study.
All in all though, I think there are too many gold nuggets on the ground to give this less than full marks.
June 15, 2019
Weirdly good. It talks about processes that have existed forever manufacturing that we're only now discovering in Software Development. And it goes *really* in-depth into them, including ideas like queueing theory which was very new to me. It *is* written like a textbook though, which makes some of the information less accessible than it should be.
July 1, 2020
Феноменальная книга. Основополагающая для руководителей желающих продвинуться от слов-ярлыков для методологий, к пониманию экономики разработки. Даются фундаментальные принципы, практически "физика разработки".
February 3, 2023
Good content that provides additional depth to many aspects you have probably already been exposed to. As well as challenging some common beliefs and adding new dimensions. The content is heavy but explained well. It took a bit longer to read but I recommend it.
September 9, 2013
I was told already about three years ago, that I should read some of Reinertsen books to understand much more about product development. Finally I read The Principles of Product Development Flow. I'm actually happy that I didn't read it earlier. It is a great book, but I have learned so much about product development during past years, that I was myself much more ready to understand the book, that I would have been earlier.
This book is not normal SW development book. I'm not sure if Agile or Scrum was even mentioned in this book. There is lot of talks about Kanban, but mainly because of queue's and because Kanban is great tool for better queue handling. This book dives in understanding where the value really is in Product Development.
One important part of this book is that it goes through why Lean is different for SW than it is for manufacturing. There are different economical factors affecting SW than normal factory. In both handling queues are important, but for example variation might even be valuable in SW, when in manufacturing it mainly waste.
I have to admit, that even with my economical background and interest in theories, still sometimes book got bit too technical to me. It really digs in deep to all subjects and make sure it has enough scientific or case study based evidence for the presented principles.
It is really important book for product development professionals. The ideas as such are valuable to everyone, but this book isn't the easiest to read. I recommend it to everyone who really want to understand how the whole product organization should work.
To be honest, I believe many of the readers of this book, will not understand how important this book is. If I will ever get to the level of understanding Reinertsen has for Product development economics, I'll be really happy. Be brave and take the challenge.
This review was originally published in my blog -
May 2, 2016
I didn't finish this the first time I read it and gave it two stars. That was unfair.
I gave it a second chance and found it chock full of valuable advice on managing product development. If I had to summarise the book I'd say it's about taking all the complex interdependent components of designing and building things and making them understandable and manageable through the use of economic frameworks.
Just because "Product" is in the title, don't think it's just for product managers, if you're an engineer or engineering manager I think it's just as valuable.
I'd have given it five stars but for two criticisms. The main is that it's just too dry. It's hard to read. Most of these ideas are only applicable in the context of a team, but the book gives you very few tools to help communicate and sell the change in approach. I also think the economic case for the problems with queues isn't particularly strong, everything else is very nuanced, but felt like I just had to agree with that premise.
Anyhow. Minor gripes. It's a slog but a valuable one. Read it.
I gave it a second chance and found it chock full of valuable advice on managing product development. If I had to summarise the book I'd say it's about taking all the complex interdependent components of designing and building things and making them understandable and manageable through the use of economic frameworks.
Just because "Product" is in the title, don't think it's just for product managers, if you're an engineer or engineering manager I think it's just as valuable.
I'd have given it five stars but for two criticisms. The main is that it's just too dry. It's hard to read. Most of these ideas are only applicable in the context of a team, but the book gives you very few tools to help communicate and sell the change in approach. I also think the economic case for the problems with queues isn't particularly strong, everything else is very nuanced, but felt like I just had to agree with that premise.
Anyhow. Minor gripes. It's a slog but a valuable one. Read it.
June 23, 2014
The Principles of Product Development Flow is an important and thought-provoking book. It's also a frustrating, condescending, and self-important book. Donald Reinertsen has some vital knowledge to pass on. He wants us to know why the rules of product manufacturing don't work for product development. He also wants us to know that he's a very clever man, and you're probably not. But he has a treasure trove of solutions, based on the simple and elegant practices of computing costs of delay, and taking into account the impact of queues. For all my frustrations with the writing and tone, the content of this book is irresistible, and I will probably be referring to a well-thumbed copy for many years to come.
April 26, 2020
A treat to read this book which is a distillation and a validation of knowledge I picked up from a bunch of other books and during years of painstaking work.
I'm a big proponent of the mathematical treatment of agile product development he puts together here with some dollops of critical chain project management thrown in. Living in Germany it is funny to read so many principles that are in direct opposition to local business practices.
Halfway through it becomes a bit of a slog but I feel I need to have read all of it at least once to be able to use it as the indispensable reference that it is. Thankfully the book did end with a chapter on manoeuvre warfare as a cherry on top.
I'm a big proponent of the mathematical treatment of agile product development he puts together here with some dollops of critical chain project management thrown in. Living in Germany it is funny to read so many principles that are in direct opposition to local business practices.
Halfway through it becomes a bit of a slog but I feel I need to have read all of it at least once to be able to use it as the indispensable reference that it is. Thankfully the book did end with a chapter on manoeuvre warfare as a cherry on top.
November 1, 2014
I cannot recommend this book highly enough to anyone who works on projects, products, or services. Reinertsen is masterful in building a comprehensive approach to product development from manufacturing, networks, computer operating systems, and the military. His insights overturn conventional thinking and even much of the guidance in Agile/Lean thinking.
The author uses 175 principles to structure the book. He provides clear examples, inspiring charts, and practical advice throughout the book. You'll never look at the development cycle the same way again once you finish this book.
The author uses 175 principles to structure the book. He provides clear examples, inspiring charts, and practical advice throughout the book. You'll never look at the development cycle the same way again once you finish this book.
October 17, 2020
What an excellent gem of a book!
Exactly what I like. I learned a lot from this book despite the fact that I recently read a different book on product management as well as Goldratt's "The Goal" and I also heard lectures titled Operations Research 1 and 2 at university which extensively dealt with queuing theory; I never grasped the importance/relevance of that for product development.
This book gives actionable principles built on top if a solid theoretical/academic framework that was generated from practical experience
As the book was written in 2010, it does lack mention of devops
Exactly what I like. I learned a lot from this book despite the fact that I recently read a different book on product management as well as Goldratt's "The Goal" and I also heard lectures titled Operations Research 1 and 2 at university which extensively dealt with queuing theory; I never grasped the importance/relevance of that for product development.
This book gives actionable principles built on top if a solid theoretical/academic framework that was generated from practical experience
As the book was written in 2010, it does lack mention of devops
October 7, 2020
I have no idea why this book is less popular in software development than any other Agile related literature.
It presents the principles behind many of the methodologies in vogue today: Scrum, Kanban, Agile, A/B testing, TDD, CI/CD, etc.
While the book Accelerate presents some of outside practices as the reasons for companies successes, Don's book presents the economical thinking behind them, also mixing up with information theory, computer science and warfare.
It presents the principles behind many of the methodologies in vogue today: Scrum, Kanban, Agile, A/B testing, TDD, CI/CD, etc.
While the book Accelerate presents some of outside practices as the reasons for companies successes, Don's book presents the economical thinking behind them, also mixing up with information theory, computer science and warfare.
November 2, 2017
Other reviewers have written great reviews about the power behind this book's premise. This is a fantastic treatise on how product development could (and arguably should) be. I'll simply say that I am happy join in and applaud Reinertsen for exposing many of us who are in the dark to these core concepts that are blindingly obvious in other industries. Reinertsen's 175 principles together are truly more than just the sum of their parts. Really Reinertsen is pointing to a completely different way of thinking about product development, and I'm looking forward to applying his proposed framework the next chance I get.
My only critique is that Reinertsen can be terse at times and more time is required to reflect on what he says that you might originally have anticipated. This seems to be especially true any time Math is involved. I have a bachelors in Mathematics, and much of what Reinertsen discusses is mathematically accurate, but he typically only lays out conclusions and doesn't really try to help the reader reach the conclusions from the premises. You sort of have to trust him on this if you can't do the proofs yourself. He also readily uses terminology from disparate fields that the reader might not have exposure to such as probability and statistics, control theory, and economics. Some of the terms used have very specific meanings, like transfer functions, transients, and step functions from the world of control theory.
Still, this is a fascinating approach to product development, and I sincerely hope that this way of thinking leads us to the next great leap of innovation in honing our product development processes.
Thanks Donald!
My only critique is that Reinertsen can be terse at times and more time is required to reflect on what he says that you might originally have anticipated. This seems to be especially true any time Math is involved. I have a bachelors in Mathematics, and much of what Reinertsen discusses is mathematically accurate, but he typically only lays out conclusions and doesn't really try to help the reader reach the conclusions from the premises. You sort of have to trust him on this if you can't do the proofs yourself. He also readily uses terminology from disparate fields that the reader might not have exposure to such as probability and statistics, control theory, and economics. Some of the terms used have very specific meanings, like transfer functions, transients, and step functions from the world of control theory.
Still, this is a fascinating approach to product development, and I sincerely hope that this way of thinking leads us to the next great leap of innovation in honing our product development processes.
Thanks Donald!
March 20, 2025
The book contains some pretty good insights about product development and practices that you can apply to your team as a software engineer (like WIP controls and batch size). Nonetheless, the bullet point format has not worked for me. The book has over 175 principles, around one or two pages long. This is intended to work as a reference, but I think it's made more damage than benefit. Some principles feel too short, others are just repeating other principles but with a different wording.
One thing I have liked about the book though, is the metaphors. I think they are top notch to illustrate what some of the principles. Even to the point where I was unable to understand some of them without first reading the associated metaphor.
To be honest I have also not been able to fully relate to the book because it seems oriented to companies quite bigger than the one where I currently work for (and I have only worked on that one so). Layers upon layers of management, different departments, lot of processes. I guess for people used to work in bigger companies with more processes this book makes more sense.
So in general, a normal read we have made in our company's book club, but I would probably never re-read it again. At least I can take with me 5 o 6 new things that I can apply to my daily job, so only for that it's been worth it.
One thing I have liked about the book though, is the metaphors. I think they are top notch to illustrate what some of the principles. Even to the point where I was unable to understand some of them without first reading the associated metaphor.
To be honest I have also not been able to fully relate to the book because it seems oriented to companies quite bigger than the one where I currently work for (and I have only worked on that one so). Layers upon layers of management, different departments, lot of processes. I guess for people used to work in bigger companies with more processes this book makes more sense.
So in general, a normal read we have made in our company's book club, but I would probably never re-read it again. At least I can take with me 5 o 6 new things that I can apply to my daily job, so only for that it's been worth it.
May 31, 2021
Fundamental insight into why DevOps works
Instead of anecdotes and compelling stories, this book focuses on product development as an example of systematic processes we can model and improve. By viewing development as queues and feedback systems, models from control theory and recommendations can be applied to our work processes. By casting our metrics as economic values, the book keeps our focus on value rather than theoretical ideals.
If you want to take your decisions out of the realm of personality and into a world where we actually change the variables that increase the value of your work, this book is worth reading. Beyond the value of the specific techniques, it's organization into specific principles lends itself to small conversations that can help create alignment in you teams. I can't wait to begin those conversations with my peers.
Instead of anecdotes and compelling stories, this book focuses on product development as an example of systematic processes we can model and improve. By viewing development as queues and feedback systems, models from control theory and recommendations can be applied to our work processes. By casting our metrics as economic values, the book keeps our focus on value rather than theoretical ideals.
If you want to take your decisions out of the realm of personality and into a world where we actually change the variables that increase the value of your work, this book is worth reading. Beyond the value of the specific techniques, it's organization into specific principles lends itself to small conversations that can help create alignment in you teams. I can't wait to begin those conversations with my peers.
January 17, 2023
This was a hard book for me to get through. I’m not a product designer, which doesn’t help.
I stumbled across references to this book while researching task management and prioritization. Namely, that he came up with the concept WSJF.
“What the hell,� I said. “I’ll try reading the book to see if he has other worthwhile ideas.�
The book was so dense and poorly written I had quite the slog getting through it. This appears to be by design. He wrote: “None of us have time to read everything we would like to read. Increasing density helps reduce this problem. I aspire to write books with more content than fluff, and I hope this book will achieve that goal.�
I kept feeling like this book could have been something great, but it was so stripped of its humanity that no one will be left to appreciate it.
I stumbled across references to this book while researching task management and prioritization. Namely, that he came up with the concept WSJF.
“What the hell,� I said. “I’ll try reading the book to see if he has other worthwhile ideas.�
The book was so dense and poorly written I had quite the slog getting through it. This appears to be by design. He wrote: “None of us have time to read everything we would like to read. Increasing density helps reduce this problem. I aspire to write books with more content than fluff, and I hope this book will achieve that goal.�
I kept feeling like this book could have been something great, but it was so stripped of its humanity that no one will be left to appreciate it.
March 7, 2018
The insights contained in this book are revelatory, and should be required reading for anyone involved in leading an R&D organisation. That being said it isn't easy required reading. Reinertsen does attempt, in his principles-led structure, to make this logical and easy to follow. However there is a lot of looping back and forth and internal cross-referencing that can be distracting. This book can probably be boiled down to a smaller number of key principles with less elaboration in the body of the text. The key learning though, is that this book looks at the challenges of product development in a different way to what we're all brought up to understand, and the insights that it offers have the potential to massively improve how we do things. Hugely valuable.
December 24, 2022
The smartest book on project task management I have ever read
I’ve read a few books on project management, Agile/Scrum, and Kanban, but this is hands down the smartest book I have read on the topic of task management. The author focuses on the economic principles behind the theory of constraints and Kanban. The author uses “queuing theory� to give the reader a fundamental understanding of why the authors recommended approach works best. After reading this book I now understand the foundations behind the recommendations of Kanban, which lets me adapt and adjust those recommendations while being aware of what effect theory says that will have on the process, which I’ll need to account for. Highly informative. 👌🏽
I’ve read a few books on project management, Agile/Scrum, and Kanban, but this is hands down the smartest book I have read on the topic of task management. The author focuses on the economic principles behind the theory of constraints and Kanban. The author uses “queuing theory� to give the reader a fundamental understanding of why the authors recommended approach works best. After reading this book I now understand the foundations behind the recommendations of Kanban, which lets me adapt and adjust those recommendations while being aware of what effect theory says that will have on the process, which I’ll need to account for. Highly informative. 👌🏽
April 12, 2020
This book is one of a kind.
I just don't have enough words of praise for such authoritative work in Product Development. Principles of Product Development Flow delivers a set of 150 principles, most of them backed with sound mathematics and statistics models, that can help you attain the desired effectiveness in your Development organization.
Starting from the premise that a business is a system whose raison d'etre is to make profits; it follows the logic that all decisions made in the development organization should take the economic view into consideration.
This book has become an instant classic, a must-read in my opinion.
I just don't have enough words of praise for such authoritative work in Product Development. Principles of Product Development Flow delivers a set of 150 principles, most of them backed with sound mathematics and statistics models, that can help you attain the desired effectiveness in your Development organization.
Starting from the premise that a business is a system whose raison d'etre is to make profits; it follows the logic that all decisions made in the development organization should take the economic view into consideration.
This book has become an instant classic, a must-read in my opinion.
December 10, 2020
If you are working in large organizations using SAFe, this book is required reading. You can see how SAFe derived many of its principles from this book, only that here you have the time and space to go to much more detail and breadth. While I wouldn’t call it an easy read, it’s full of examples that make the often very technical sounding principles come to life. I also liked how Reinertsen borrows ideas from concepts seemingl outside the industry, such as computer processors, the Internet, or military warfare. A classic textbook for modern Product Development teams.
Read
January 21, 2021Reading note: The first time I tried this book, I successfully read about five pages before bouncing off and selling it. I think the biggest problem I had was expecting this to be a book about how to design better products, when it's actually about process.
What was especially helpful for me the second time around was watching on queues in software development beforehand; it gave me a much more accurate sense of what to expect.
What was especially helpful for me the second time around was watching on queues in software development beforehand; it gave me a much more accurate sense of what to expect.
December 26, 2021
I started reading this but stalled partway through since it wasn't as engaging as the other books in my queue, but revisited it after reading The Phoenix Project and Team of Teams and found it much more engaging with that framing.
It's an excellent book that added support for things I already believed, provided analysis around things that were more gut feeling before, and also made me rethink some of my beliefs and practices. I have a long list of changes to implement.
My recommended order is Phoenix Project, Team of Teams, then the three Idealcast episodes with one of the authors of Team of Teams, then this.
It's an excellent book that added support for things I already believed, provided analysis around things that were more gut feeling before, and also made me rethink some of my beliefs and practices. I have a long list of changes to implement.
My recommended order is Phoenix Project, Team of Teams, then the three Idealcast episodes with one of the authors of Team of Teams, then this.
March 4, 2018
This is a book of three different ideas speed, quality, cost . Hands down the best book on Product Management I’ve read so far. Donald Reinertsen clearly explains the challenges in developing software products and offers pragmatic solutions to drastically improve time-to-market, economic value & product quality in a refreshingly down-to-earth manner.
The book busts traditional product management myths and introduces well-known concepts from Lean methods.
The book busts traditional product management myths and introduces well-known concepts from Lean methods.
January 20, 2019
An excellent book thoroughly explaining the theories behind lean product development. Dense, to the point and well argued. I especially liked the economical arguments the book started with and kept gravitating towards, making this a great book for not just working with lean practices but also business-whispering the benefits of doing so. Slightly dry and required deliberate attention to understand, but I guess that happens when you minimize fluff.
Displaying 1 - 30 of 137 reviews
Can't find what you're looking for?
Get help and learn more about the design.