![](https://webcf.waybackmachine.org/web/20210727185029im_/https://images-na.ssl-images-amazon.com/images/G/01/digital/sitb/sticker/sitb-sticker-v3-small._CB485933792_.png)
![](https://webcf.waybackmachine.org/web/20210727185029im_/https://images-na.ssl-images-amazon.com/images/I/51PdVCFcp3L._SY291_BO1,204,203,200_QL40_ML2_.jpg)
Follow the Author
OK
The Principles of Product Development Flow: Second Generation Lean Product Development Hardcover – January 1, 2009
Donald G. Reinertsen
(Author)
Find all the books, read about the author, and more.
See search results for this author
|
-
Print length304 pages
-
LanguageEnglish
-
PublisherCeleritas Publishing
-
Publication dateJanuary 1, 2009
-
Dimensions6.25 x 1.25 x 9 inches
-
ISBN-101935401009
-
ISBN-13978-1935401001
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
Download to your computer
|
Kindle Cloud Reader
|
Customers who viewed this item also viewed
What other items do customers buy after viewing this item?
Customers who bought this item also bought
Editorial Reviews
Review
This book challenges an awful lot of fashionable ideas on improving product development processes. It provides a vast number of very solid principles that could make a big difference for almost any product development organization, from beginners to the most advanced. It offers a fundamentally different way of thinking about product development processes. Don't read it if you are content with business as usual! ----Andrew Flint, Microsoft Hardware
From the Inside Flap
From the Back Cover
About the Author
For 30 years, Don Reinertsen has been a thought leader in the field of product development. In 1983, while a consultant at McKinsey & Co., he wrote the landmark article in Electronic Business magazine that first quantified the financial value of development speed. In 1985, he coined the term Fuzzy Front End to describe the earliest stage of product development. In 1991, he wrote the first article showing how queueing theory could be practically applied to product development.
His 1991 book, Developing Products in Half the Time, coauthored with Preston Smith, is a product development classic. His 1997 book, Managing the Design Factory, was the first book to describe how the principles of Just-in-Time manufacturing could be applied to product development. In the 12 years since this book appeared, this approach has become known as lean product development. For 15 years, Don taught executive courses on product development at California Institute of Technology. He currently teaches public seminars throughout the world.
Product details
- Publisher : Celeritas Publishing; 1st edition (January 1, 2009)
- Language : English
- Hardcover : 304 pages
- ISBN-10 : 1935401009
- ISBN-13 : 978-1935401001
- Item Weight : 1.4 pounds
- Dimensions : 6.25 x 1.25 x 9 inches
-
Best Sellers Rank:
#107,284 in Books (See Top 100 in Books)
- #4 in Industrial Production & Management
- #31 in Industrial Management & Leadership
- #39 in Product Management
- Customer Reviews:
Customer reviews
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
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.
Chapter 1 is somewhat different from the other chapters in that rather than being a series of principles, it provides an overall view of practice orthodoxy and how many of these closely held beliefs are based on secondary or proxy variables. The chapter continues with an overview of several examples and then summarizes and discusses where things are going in the rest of the book as well as the layout. The first chapter is great. I did expect it to end a bit sooner than it did (I was thinking in terms of self-referential, small batch sizes), but I'm not sure a shorter chapter would have been better.
The second chapter introduces the approach for the rest of the book as well as the model underpinning the principles. The approach works for me. I imagine myself reading this book, going back and creating queue cards for each of the principles, then periodically looking up individual ones and refreshing my memory. It seems like a book I can keep going back to and reading just because I want 5 minutes of good reading.
For some context, I'm a software developer. I learned about the Theory of Constraints (ToC) before I really learned software development processes in depth. When I did being the software process journey, it was under the OO umbrella, so incremental and iterative, feedback, etc. This learning, however, I've recently realized (by first reading Kanban and now this book) was heavily influenced by the ToC. At the beginning of this century, I jumped on the XP and Scrum bandwagons, even working with a few of the original signatories on the manifesto for agile development.
ToC came up a number of times while coaching. Moving from ToC to thinking in terms of Kanban isn't much of a leap to me. However, since I was applying things I learned and internalized, things that seem obvious to me are often not obvious to my customers or even my colleagues (yes, sometimes I'm wrong, but often I'm not). For example, at many, many places I've been, companies claim they are practicing continuous integration or even continuous delivery, but then their builds are broken (red) 80+ % of the time. This is a huge cost to productivity, morale, feedback, etc. This is one example of many such examples that, in in the context of ToC are obvious bottlenecks, which cause queueing. If I look with lean glasses, many of these are worthy of stopping the line, but people march on, building up queues of work to be committed, which lead to more broken builds, integration problems, demoralization, etc.
However, what seems obvious to me doesn't seem obvious to others. More importantly, many people don't even see that there's a problem at all! They think, for example, when developers complain about being blocked due to the build being broken, it's just developers complaining about a minor glitch, but it is more typically a systemic problem.
This books presents a model based on economics. One thing that I observed myself observing about the book was that I thought it might be over emphasizing one dimension, cost of delay, or one approach, economics. However, "all models are wrong, some are valuable." While I had this observation, I didn't find anything wrong about the conclusions, and in fact find my self thinking "yes and," so I've kept reading. So while this model may be wrong in some ways (I'm not aware of any), I clearly see immediate and near-term value for me with its use.
What this model does is allow me to speak to upper management, and maybe middle management using a language they are likely to appreciate. I'm able to justify things like slack using economic models, so that I might be better able to communicate with them. So rather than talking about the flexibility and agility that well under 100% utilization might offer, instead I can discuss the cost of delivery related to high utilization (lack of slack). My primary failing up until now is not being able to explain what seems intuitive to me in a way that bridges the communication gap. This model seems to give me another way to both think about it and communicate it.
I have not finished reading the book, but in the the spirit of small batch sizes, this is my first delivery. I'll be making updates as I read the book. I am already confident that I'll finish this book and that I can recommend it to people. It'll have to really work hard to go under a 5 star review.
Finally (so far): my impression so far reading the book is that it seems well researched, brings together a number of disciplines in a non-trivial manner and seems to come form someone who legitimately has many good years of experience, not just the same 1 year of experience repeated over and over.
For the traditionalist, add to cart if you want to learn:
- Why prioritizing work "on the basis of project profitability measures like return on investment (ROI)" is a mistake
- Why we should manage queues instead of timelines
- Why "trying to estimate the amount of work in queue" is a waste of time
- Why our focus on efficiency, capacity utilization, and preventing and correcting deviations from the plan "are fundamentally wrong"
- Why "systematic top-down design of the entire system" is risky
- Why bottom-up estimating is flawed
- Why reducing defects may be costing us money
- Why we should "watch the work product, not the worker"
- Why rewarding specialization is a bad idea
- Why centralizing control in project management offices and information systems is dangerous
- Why a bad decision made rapidly "is far better" than the right decision made late and "one of the biggest mistakes a leader could make is to stifle initiative"
- Why communicating failures is more important than communicating successes
For the Agilist, add to cart if you want to learn:
- Why command-and-control is essential to prevent misalignment, local optimization, chaos, even disaster
- Why traditional conformance to a plan and strong change control and risk management is sometimes preferable to adaptive management
- Why the economies of scale from centralized, shared resources are sometimes preferable to dedicated teams
- Why clear roles and boundaries are sometimes preferable to swarming "the way five-year-olds approach soccer"
- Why predictable behavior is more important than shared values for building trust and teamwork
- Why even professionals should have synchronized coffee breaks
And the list goes on and on and on.
My favorite sections are Reducing Batch Size, which I use in my Agile courses, The Human Side of Feedback, and Achieving Decentralized Control, on "what we can learn from military doctrine."
Mind-expanding! Bonus: the author includes his email address and promptly responds to inquiries.
Top reviews from other countries
![](https://webcf.waybackmachine.org/web/20210727185029/https://images-eu.ssl-images-amazon.com/images/S/amazon-avatars-global/default._CR0,0,1024,1024_SX48_.png)
175 principles to establish or boost the flow of product development by focussing decision-making on economic benefit. Each principle is defined in clear language and then practical examples are used to demonstrate how to apply in your workplace.
As an engineering manager and director, this book has become a guiding light that I return to on a regular basis to mine the gems that Mr. Reinertsen has gathered together.
If you are involved in the management of Product Development teams, this book should be bought, devoured and absorbed into your DNA. Anything less is irresponsible.
![](https://webcf.waybackmachine.org/web/20210727185029/https://images-eu.ssl-images-amazon.com/images/S/amazon-avatars-global/default._CR0,0,1024,1024_SX48_.png)
However, I found it pretty heavy going. Also I have quite a lot of Agile, Scaled Agile and Program Management experience. (I bought this and several other books to review practices and theories prior to designing training and deployment of Agile to a global team). Whilst I found the theory from this book to be correct, in my experience the models are over-simplistic and cannot be used in real world effectively.
![](https://webcf.waybackmachine.org/web/20210727185029/https://images-eu.ssl-images-amazon.com/images/S/amazon-avatars-global/default._CR0,0,1024,1024_SX48_.png)
![](https://webcf.waybackmachine.org/web/20210727185029/https://images-eu.ssl-images-amazon.com/images/S/amazon-avatars-global/default._CR0,0,1024,1024_SX48_.png)
I did find it a challenge to read, and many parts I had to read twice or more. Had it not been for the group I may have struggled to finish it. There is quite a lot of mathematics in it, which can be difficult for some.
However, the book conveys some very good ideas. The economics give you a common value for making choices between different product development options. The parts on design in process inventory, cost of delay and life cycle profits will help our agile teams to give the best value to the customer.
I really appreciated the differentiation made throughout the book between manufacturing (the basis of a lot of lean thinking) and product development, which has variability, is non repetitive and non-homogeneous.
The chapters on managing queues, exploiting variability, reduced batch size, fast feedback and decentralised control were really informative.
I am really pleased that I have read this book. At times I struggled, but the journey was worth it. I will keep this book on my desk and refer to it often.
![](https://webcf.waybackmachine.org/web/20210727185029/https://images-eu.ssl-images-amazon.com/images/S/amazon-avatars-global/default._CR0,0,1024,1024_SX48_.png)
We all "know" that short releases cycles, quick feedback, prioritised feature sets etc all make sense but do we all know why that is the case? We all "know" how to manage full queues but do we all know that alternatives exists and that they could perhaps help with managing the flow of the delivery stream even better? What about critical chain project management? Why does it work? How about Theory of Constraints? Is it as good as some people think? This book covers it all. Everything you wanted to know about, well, product development flow but were afraid to ask.