Contents:
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. Jul 02, Bjoern Rochel rated it really liked it Shelves: Marvelous 5 star content obscured by sub-par organization and style choices. Sep 11, John rated it really liked it. I didn't finish this the first time I read it and gave it two stars. 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 I didn't finish this the first time I read it and gave it two stars.
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.
It's a slog but a valuable one. Jun 10, Charles Eliot rated it really liked it. 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 ta The Principles of Product Development Flow is an important and thought-provoking book.
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. Nov 01, Roger K. 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.
The author uses principles to structure the book. He provides clear examples, inspiring charts, and practical advice throughout the book. Yo I cannot recommend this book highly enough to anyone who works on projects, products, or services. You'll never look at the development cycle the same way again once you finish this book. May 11, Dan Lewis rated it it was amazing.
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 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. Nov 02, Nicholas rated it it was amazing Shelves: 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 principles together are truly more than just the sum of their parts. Really Reinertsen is pointing to a completely different way Other reviewers have written great reviews about the power behind this book's premise. 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.
Mar 07, Richard Mullahy rated it really liked it. 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. 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 outs 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 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. 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.
Mar 04, Hunter Hart rated it really liked it. This is a book of three different ideas speed, quality, cost. The book busts traditional product management myths and introduces well-known concepts from Lean methods. Mar 21, Eric Bowman rated it it was amazing. A deep book which exposes the systematic flaws arising from a naive application of agile principles at scale. In particular, though not mentioned, this book provides the foundation for why feature teams and Inner Source are so important for realizing global efficiency in turning ideas into products.
As a software development manager, it reinforces a lot of the concepts and practices I've adopted over the years using scrum. Yet there are still some surprises and lessons and important changes I discovered that I've already started applying to positive effect.
The most important moment in the book is probably Figure 8. Metrics for Flow-based Product Development. Really good book but very hard to read. Along with a lot of deep queue theory and serious mathematical theory interpolation, the advice are often very abstract and hard to understand how to put in practice. Generally the ideas are great and it is worth the effort to read but it is definitively not a light read and requires a lot of work to try to put in practice. I liked the mathematical explanations and some of the principles are useful.
The book is condensed in some parts where more examples and explanations would be useful, and repeats itself in other parts. It you work in software development you need to read this book. It is critical to think not only about your craft of design but the methods we use to endure that what we build is delivered quickly and has the highest value. Incredible This is a remarkable book that spans numerous disciplines in its mission of applying principles of flow to product dev't. I found many insights in further extending them to knowledge work productivity.
Dec 07, Michael rated it it was amazing. Love the principles and the lack of zealotry in the writing. Oct 09, Anton Kotov rated it liked it. Insights - 5 stars, storytelling - 1 star.
Apr 21, Ben rated it really liked it. I highlighted a lot.
All interesting, if a bit abstract. Feb 04, Damien rated it it was amazing. I do not even know where to begin. And when finished, reread it. Great book as for the content, but super hard to read. Aug 28, Maria Cerase rated it liked it. Economically sound and brilliant read. Just too presumptuous in tone. Apr 11, Laura rated it liked it. This book contained some good ideas, though nothing that hasn't been incorporated into more contemporary methodologies like Agile.
Aug 04, Cory rated it it was amazing. Fantastic economic and flow descriptions. Aug 16, Ray Angelone rated it it was amazing.
This book is packed with principles that range from queue theory to batch size management to explain how "flow" works best in product development. It's not a light read, yet worth the effort. Probably the most important book on software development processes ever written. Would have benefited from a better editor and different format but still such a goldmine of important information. Nov 22, Jeff rated it it was amazing. If you want to understand the theory behind agile practices, this is the place to look. This is a deep and heavy book describing the principles of any flow-based system, how to identify constraints, and how to optimize throughput.
It's not light reading by any means. There are no discussion topics on this book yet. Under such conditions, management will almost automatically support anything that appears to help the "golden" project. After all, they want to do everything in their power to eliminate all excuses for failure. Have you had trouble buying a new piece of test equipment?
Just show it will benefit the "golden" project and you will get approval. Have a feature that nobody would let you implement? Find a way to get it into the requirements of the "golden" projec. These large projects act as magnets attracting additional cost, scope, and risk At the same time, large batches encourage even larger batches. For example, large test packages bundle many tests together and grow in importance with increasing size.
As importance grows, such test packages get even higher priority. If engineers want their personal tests to get high priority, their best strategy is to add them to this large, high-priority test package. Of course, this then makes the package even larger and of higher priority. This snippet is characteristic of Reinertsen's writing style and reasoning. He shows how the actions of people inside traditional systems are motivated by their rational assessment of their own economics. By setting up the wrong incentives, we are rewarding the very behaviors that we seek to prevent.
Reinertsen has a visceral anger about all that waste, and his stories are crackling with disdain for the people who manage such systems - especially when their actions are motivated by intuition, voodoo, or blindness. Startups are frequently guilty as charged - the 4-year death march example above could be written about dozens of venture-backed companies slogging it out in the land of the living dead. Reinertsen does not speak about startups specifically - his book is meant to speak broadly to product development teams across industries and sectors.
Yet his analysis of the sources of waste in development and the remedies that allow us to iterate faster are especially useful for startups. There is an important caveat, however. Product development in established companies and markets has a clear economic rationale to judge effectiveness and productivity.
The goal is to increase profitability by making high-ROI investments in new products. To give one example, Reinertsen emphasizes the power of measuring the cost of delay COD of a new product. That is, in order to make economically rational decisions about cycle time for a given process, we should understand what it costs the company if the products produced by that process are delayed by, say, one day.
Armed with that information, we can make rational trade-offs. Take one of Reinertsen's example: Unhappy with late deliveries, a project manager decides he can reduce variability by inserting a safety margin or buffer in his schedule. He reduces uncertainty in the schedule by committing to an 80 percent confidence schedule. But, what is the cost of this buffer? The project manager is actually trading cycle time for variability. We can only know if this is a good trade-off if we quantify both the value of the cycle time and the economic benefit of reduced variability.
Does this sound familiar? Many of the startups I talk to - and their boards - seem to equate ability to "hit the schedule" with competence and productivity. Yet timely delivery of new features often comes at the expense of agility, especially if cycle times are long. That is often a bad trade although, as I'm sure Reinertsen would hasten to add, not always! For example, many startups would do better by removing buffers from their schedules, embracing the variability of their delivery times, and reducing their cycle times.
Even worse, and unlike their established counterparts, startups often experience a non-quantifiable cost of delay. In a truly new market, we face no meaningful competition, there are no tradeshows to present at, and customers are not clamoring for our product. This means that there are no external factors that argue for shipping product on any given day.
A day delay has almost no cost, as far as profitability is concerned.
Remember that startups operate by a different unit of progress: Any activity that promotes learning is progress, and productivity needs to be measured with respect to that. And that's also where we need to modify some of the specific practices Reinertsen recommends. If the product development team can be engaged in activities that promote business learning at the expense of shipping - or even selling - product, that's a good trade.
Hence the need for partitioning our resources into a separate problem team and solution team. As with any methodology, applying the principles faithfully may require modifying the practices to fit a specific context. Let me close with an excerpt of Reinertsen at his best, using an unexpected example to illustrate the power of fast feedback to make learning more efficient: It should be obvious that fast feedback improves the speed of learning. What may be less obvious is that fast feedback also increases the efficiency with which we generate information and learn new things.
It does this by compressing the time between cause and effect. When this time is short, there are fewer extraneous signals that can introduce noise into our experiment. Team New Zealand designed the yacht that won the America's Cup. When they tested improvements in keel designs, they used two virtually identical boats.
The unimproved boat would sail against the improved boat to determine the effect of a design change. By sailing one boat against the other, they were able to discriminate small changes in performance very quickly. In contrast, the competing American design team used a single boat supplemented by computer models and NASA wind tunnels.
The Americans could never do comparison runs under truly identical conditions because the runs were separated in time Team New Zealand completed many more cycles of learning, and they generated more information in each cycle. This ultimately enabled them to triumph over a much better funded American team. It is worth noting that Team New Zealand explicitly invested in a second boat to create this superior test environment. It is common that we must invest in creating a superior development environment in order to extract the smaller signals that come with fast feedback.
There's far more material in this book that I would love to be able to excerpt. Unfortunately, each principle builds on the previous ones so tightly that it's hard to form coherent excerpts without quoting the whole thing. And that's exactly my point. When we're ready, this book has a tremendous amount to teach all of us.
It's not a beginner's guide, and it doesn't hold your hand. Instead, it tackles the hard questions head-on. I've read it and re-read it; for a process junkie like me, I just can't put it down. I hope you'll enjoy it as much as I have. The Principles of Product Development Flow: Second Generation Lean Product Development. Anonymous July 13, at 7: George July 13, at Anonymous July 13, at Anonymous July 13, at 1: DSarathy July 14, at 3: Chris Waldron July 15, at 5: Nancy Grossbart July 27, at 7: Newer Post Older Post Home.
User Experience Design Company. One of the most important lean startup techniques is called the minimum viable product. Its power is matched only by the amount of confusi What is customer development?
The Principles of Product Development Flow: Second Generation Lean Product Development [Donald G. Reinertsen] on www.farmersmarketmusic.com *FREE* shipping on. Second Generation Lean Product Development. By Donald G series of principles that have been categorized into eight major groups with several sub-.
When we build products, we use a methodology. For software, we have many - you can enjoy a nice long list on Wikipedia.