Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework

Lean concepts and flow can either tremendously improve software development and delivery or be horribly misapplied and wreak havoc. Most misapplication tends to come when project and mechanistic thinkers refuse to change their models of efficiency and production. This takes the rather obtuse work of Reinertsen in Product Development Flow and makes it much more approachable, applicable, and measurable. I would read Lean Enterprise first to get context; I would also suggest reading Escaping the Build Trap to get a more holistic understanding of "features" and product thinking. While the Flow framework itself is fairly straightforward, the potential for project and manufacturing thinkers to misapply the model to the detriment of the company and customer is very real; I have experienced this first hand in my current company.

I was super excited to see Project to Product. This is such an important topic and such a big change within large organizations. In my opinion, there is still a lot to be written on this topic and I hoped Mik Kersten's book would do this! I kept my excitement for a while although felt that the book lacked thorough research at times. It did cover the topic I had been waiting for in chapter 2. It was shallow, but hey, it is only chapter 2, so the rest of the book will dive in all the details, give examples and stories of companies that made that change, right? Not so. The rest of the book was about metrics... and then about tools. I had not properly checked the background of the author, but the focus on tools made me suspicious. Checking it further, the author works in a company that builds a tool to integrate tools together. After discovering that, it became harder and harder to seriously read the book and not see it as a massive sales pitch. I was disappointed and felt it was unfortunate as there is so much to be said about changing from project-management to product-management.Anyways. The book consists of three parts: (1) the flow framework, (2) value stream metrics, and (3) value stream networks. The book starts with an introduction in which it introduces a thinking model which is referred to in the rest of the book, which is structures of technological revolutions. According to the model, these consist of an "installation period" in which the new technology rapidly develops and the "deployment period" in which is the new technology becomes widespread. In between these is "the turning point" and the author claims we are in at that point.The first part consist of an introduction and then chapter 2 which talks about the difference between project-based management and product-based management. I enjoyed this chapter, although I felt it confused some concepts and was short on details. For example, looking at projects as having a cost-center approach vs products having a profit-center approach. While they do often come hand in hand, they are not directly related. Also, the author missed the topic of pretending projects to be independent and the long-term effect of that which was curious even though he later talks about problems of technical debt at length. Here, our backgrounds seem to be related. He had spent some time in Nokia and shared his opinion on the reason why they failed (not the company, but the phone business, unfortunately, the author seems unaware they are separate things). Having worked in Nokia myself and seen the development up close, I felt his analysis was superficial. But that is a discussion for over a beer and not in a book review. The last chapter in this part introduces the flow framework, which the author presents as some kind of meta-framework for managing product development.The second part is about metrics. The first chapter defines several product development metrics which the author refers to as flow metrics. These metrics were not bad just not sure where the author was going with this and there the project to product would come back. After attempting to convince the reader that these metrics are the ones for managing the development, the next chapter attempts to link them to business results. The last chapter described measuring and handling failures in development. The content was dry and theoretical. There were no examples of companies that adopted these metrics and neither examples of how they were used. The few examples throughout the book are either general stories that were read or examples of the author's own company. A lot more detailed examples and stories might have made these come to life.The last part was about value stream networks (I gave up being irritated about the hijacking of the word value stream and giving it a different meaning). In this part, the author expands the flow framework with two more layers. This happens because the author attempts to make the flow metrics a reality in the current complex tool landscape in most enterprises. The author doesn't challenge whether the current complex organizations need to be that complex (and seems to forget about the project to product simplification for a moment). The author also doesn't wonder whether all these tools in organizations are necessary. He does interestingly conclude that the increase in specialization will continue... even though the lean thinking movement (which he refers to at times) actively encourages multi-skilled workers and less specialization. Therefore, the solution to this is to integrate all the enterprise tools together.... At this point, I have some trouble not getting angry as that has been the promised solution for all my working life and it has never actually worked or provided benefits. Instead, it usually led to management being further away from the development as they can just look at the dashboards, leading to less understanding of the actual work, leading to much worst development. It was really hard to follow the reasoning of the author. Anyways, when you decided that the answer is to connect all tools together, then you need two additional layers, the activity model that generalizes the concepts used in the tools and the integration model that explains how the tools are connected. The rest of the part tries to explain these, although it was hard to finish the book at this point.I wanted to like this book so much! Unfortunately, I didn't. It made me angry at times when the author states that the data in the tools is the reality (gemba) of software development. There is nothing about development, teams, team work, or anything that I would consider the reality of software development. There was only the assumption that the tools reflect accurately what goes on in development, not an experience I have. Perhaps the disappointment wouldn't have been so big if the book was simply titled "The flow framework: flow metrics and linking tools in development." It would be a more valid title, though I would not have read the book then at all. Unfortunately, to me, the book did not follow what the title promised and I do not recommend anyone to read this book. That said, I did learn some new models and ways of thinking, so I'll leave this with 2 stars.

DevOps guru Gene Kim rightly introduced this book with, "Every decade there are a couple of books that genuinely change my worldview. ... This is one such book."Mik Kersten provides ample evidence that the project and cost center orientation of so many software producing companies doesn't fit the Age of Software, and suggests a way becoming product-centric via a focus on value flow. The book is a an appealing combination of real-world examples of those who got it right (and who didn't) and practical explanations of what needs to be done to build measurable value networks.Net effect for me? A mind that is racing on how best to distill it into something I can evangelize in my workplace. This isn't a "single read" type of work, and extra kudos to Kersten for the useful glossary and extensive index.Get the book. Your company's future may depend on what it'll bring to light.

This book has good content and very interesting when author used BMW plant as the reality and realize technology and DevOps/Agile methodology that are integrated in manufacture. Real scenarios/cases in this book very clear and author used fair-way (not criticize) to CIO/CTO or C-levels that were not aligned tendency.In this book, Flow Framework and 3 zones of Moore are the main contents, however, at last I don't find the mapping or anyway to integrated project to product in software (author said it can't) but this book is very useful for DevOps and any company applied Agile/Scrum to operations.One-size-does-not-fit-all, this book only show some cases in (digital) transformation and sometime making disruption such as Telsa or Uber.Note: if you had Make work Visible, A seat at the table, Phoenix Project...you have got a little as desired.

The writing devolves over time but is solidly engaging for the first few chapters. The ending content is dry and a little to much of a sales pitch. That said, the ideas and methods discussed are valid and worth reading if you’re into unrealistic business ideals.

Mik has written a book that should be read by every leader and executive of every established incumbent company in the world. Disruption is real, and those who cling to yesterday's way of leveraging technology for business enablement are at risk of going the way of Kodak, Blockbuster, Toys 'R Us, etc. It's a concise read but very dense with really vital guidance today's corporate leaders.

This book is extremely important for anyone playing a role in transforming how your organization works. We are moving beyond the industrial and manufacturing age into a world that is powered by technology. Understanding how to restructure an organization around business value and create visible links to where business activity links to that value is critical. And it has to be done with a specific focus on how technology and software development drives business value.

This is a must read book for any software manager. Mik talks about his epiphany moments on his journey to creating the Flow Framework. My epiphany came while reading this book when I realised how poorly we currently manage software delivery. Mik talks about us being in the Installation Period (the early days) of the Age of Software. I might call it something different - the amateur period. Software managers today are mostly just amateurs doing the best we can based on our own experiences. We do not have the information that would truly allow us to manage in a professional manner.Kim's Flow Framework is designed to address this issue. Unfortunately, this is where the book's one most massive flaw hits. He spends 8 out of the 9 chapters explaining why we need a flow framework in a beautifully clear manner. Unfortunately the 9th, and most critical chapter, that is meant to explain the Flow Framework is a rushed and unclear explanation.Let's hope he does a follow up.

This is really a discussion on how to do Enterprise Architecture for an isolated "slice" of a business, rather than the more traditional (and much-maligned) big-bang approach (specifically software product development, although many of the principles could be applied to other functions/fields too). There are some good insights here, and it did get me thinking about how to approach parts of this problem where I work, but towards the end of the book i was left wondering where the "how to" section was: practical guidance on how to actually execute the ideas seems to have been left out of the book. Still an interesting read, though.

I must start by saying there is a lot of solid information in this book. The author does a fantastic job of explaining some of the challenges that come along with organisations that have a project focus.However, the book does a very good job of keeping you in suspense for "the framework" (Chapter 9), but much like Game of Thrones, the ending is very disappointing. The explanation is vague and the diagrams lack detail. I wasn't happy about this and I wanted more..... only to find all internet searches leading to the same place; Tasktops marketing page (the author's company).So, if like me, you want a thorough example of the flow framework, sorry but you won't find it here.

Interesting concept! Can you visualise your decisions such that work can flow thru your organisation augmented by software? Can you really use software to help make your organisation better at doing things, faster at finding out if it matters and sustainably able to improve? Can you help your staff and suppliers help the consumers of your services?I wish the book had more of a normal IT organisation and their journey of benefiting from the Flow Framework instead of BMW, but the ideas were quite thought-provoking.

some great stories to tell and concepts here, but you need to filter it with, 'this guy has a tool he wants to sell you to do this stuff'. however if you filter that and think about the concepts it's pretty good.