I have spent the last few months with my latest start-up, Artfox, where I have been trying to push home some of the lean start-up advice expounded by Eric Ries and Steve Blank. I was hoping that "The Principles of Product Development Flow", by Donald Reinertsen, might help me in making a persuasive argument for some of the more troublesome concepts around minimum viable product and ensuring that feedback loops are in place with your customers as soon as possible. Unfortunately, I don't think that this is the book if you are looking for immediate, practical prescription, but it is a thought provoking, rigorous view of the product development process, that pulls together ideas from manufacturing, telecommunications and the Marines.
Perhaps Reinertsen's most accessible advice is that decisions in product development should be based on a strong economic foundation, pulled together by a concept of the "Cost of Delay". Rather than on relying on prescriptions for each of several interconnected metrics, such as efficiency and utilisation, Reinertsen suggests that economics will provide different targets for each of these metrics depending on the costs of the project at hand.
His proposition that product development organisations should measure "Design in Process", similar to the idea of "Intellectual Working In Process" proposed by Thomas Stewart in his book "Intellectual Capital", is what allows him to make the parallels to manufacturing and queueing theory and enables the application of the wide body of work in these fields to product development.
His practical advice, such as working in small batches and using a cadence for activities that require coordination, will come as no surprise to practitioners of agile development, and Reinertsen provides clear reasoning of why these practices work.
During my time at Alcan, and later Novelis, I gave a lot of thought to scheduling, queues and cycle times in a transformation based manufacturing environment, and I found that this had many parallels to his view of the product development process, and little in common with what Reinertsen describes as manufacturing, which seems to be limited to high volume assembly type operations. I found many ideas that could be usefully taken back to a manufacturing context.
If you look at this book as an introduction to scheduling, queueing theory and the reason's behind some of agile development practices, then you will not be disappointed.
Comments
Thanks for taking the time to contribute.
All comments are moderated and I reserve the right to remove comments for any reason, including abusiveness, illegality, and spam links.
Comments are plain text, with blank lines seperating paragraphs. Anything that looks like a URI will become a link. Any HTML will be escaped and appear as you type it in.
Don,
Thanks for your quick response. I agree that there is much in PPDF that could be used to address "minimum viable product". In addition to your suggestions, I think it would be import to consider the risk reduction assosciated with releasing something early, and iteratively.
I enjoyed your book, and it got me thinking again about flow and how it applies to product design! Many thanks.
I agree that PPDF does not explicitly address the issue of the "minimum viable product" but it does contain some principles that may provide some help. Principle E16 discusses the concept of marginal economics. Think of feature content as a function that could range from zero to infinite. Each feature you add to a product affects the value of the product as well as its cost.(Cost in the most general sense includes unit cost, cost of delay, and one-time expenses.) As you move further down this feature continuum where you reach a point where the total value of the product exceeds total cost. At this point the product is economically viable. If you wish to maximize economic returns you should consider going past this point until you reach the point where the incremental cost added by a feature rises to be equal to its value. If you go past this point you are destroying economic value.
The second important issue is deciding which bundle of features you will select to achieve this minimum viable product. There may be an almost infinite number of sets that will achieve this. The minimum set of features that will achieve this objective is the one that prioritizes features with the best ratio of benefit to cost. This problem is isomorphic with the issue discussed in Principle B20 discussing batch content. (In this case batch=feature.)
Of course, this total of four pages does do not do justice to this issue, but I hope they may be helpful.
Feel free to contact me by Email if I can elaborate on this.