top of page
  • Toby Sinclair

Book Summary: Project to Product by Mik Kersten | Flow Framework

Updated: Jun 3, 2021

Project to Product Book Summary Banner

⭐ Toby's Rating: 6/10 - Recommended For: Senior Managers

3 Big Ideas

  1. Avoid the pitfalls of local optimization. Focus on the end to end value stream. In the context of a software value stream. The concept of end to end includes the entire process of value delivery to the customer. It encompasses functions ranging from business strategy and ideation, all the way to instrumentation of usage, to determine which values were most adopted by the customer base.

  2. Review your mental models. Comparing Software Development to Manufacturing leads to ineffective optimisations. Software Development is non-linear value steam, much like an Airline Routing Network rather than the more linear Manufacturing Value Streams.

  3. Alignment is critical between Organisation Structure, Software Architecture and Value Stream Architecture

2 Project to Product Quotes

Best quotes from Project to Product

The most important metric for each value stream is an objective measure of value. This should come directly from the financial metrics used by the organisation. For example for customer-facing products, the metric could be overall revenue from that product or monthly recurring revenue.
Software is more like routing aeroplanes than manufacturing cars.
Project to Product Book Summary Quote

Toby's Takeaways

Within Project to Product I really like the metaphor, Software is more like an Airline Network than a Manufacturing line. Companies like Toyota can give IT organisations some good ideas but they can't be directly copied to the software delivery context. The flow framework is an interesting way to visualise this network and measure it against real business outcomes.


Project to Product - The Flow Framework

A framework to visualise software delivery network enabling business decisions throughout all levels of the organisation.

Flow Framework by Mik Kersten in Project to Product
Ref: Project to Product by Mik Kersten

Flow Item Types

With a software value stream network there are typically 4 flow items:

Work Item Types from Flow Framework by Mik Kersten
Ref: Project to Product by Mik Kersten

Project to Product Comparisons

Project orientated management.


Funding of milestones predefined project scoping new budget requires the creation of a new project


Term of the project. Defined end. Not focused on the maintenance have after the project.


cost centre approach, measured to being on time and on budget capitalization of development results in large projects business incentivized to ask for everything they might need upfront.


Delivery risks such as product-market fit is maximised by forcing all learning specification and strategic decision making upfront


Bring people to the work, allocated upfront. People often span multiple projects frequent churn and reassignment


Project plan-driven focus on requirements delivery projects drives waterfall orientation


Technology is a black box, project managers create complex mapping and security.

Product orientated management.


Funding of product value streams based on business results, new budget allocation based on demand incentives to deliver incremental results


The lifecycle of the product, multiple years includes ongoing health maintenance activities through the end of life.


Profit centre approach, measured in business objectives and outcomes met to focus on incremental value delivery and regular checkpoint


Risk is spread across the timeframe and iterations of the project. This creates option values such as terminating the project if delivery assumptions were incorrect or pivoting if strategic opportunities arise.


Bring work to the people stable incrementally adjusted cross-functional teams assigned to one value stream


Roadmap and hypothesis testing driven focus on feature and business value delivery products drive agile orientation.


Direct mapping to business outcomes, enabling transparency.

Mik Kersten's Three epiphanies

  1. Productivity declines, and waste increases as software scales due to disconnects between the architecture and the value stream.

  2. Disconnected software value streams are the bottleneck to software productivity at scale. These value stream disconnects are caused by the misapplication of the project management model.

  3. Software value streams are not linear manufacturing processes complex collaboration networks that need to be aligned to products.


Value Stream: the end to end set of activities performed to deliver value to a customer through a product or service.

Lean thinking principles:

  1. Precisely specify value by specific product.

  2. Identify the value stream for each product.

  3. Make value flow without interruptions

  4. Let the customer pull value from the producer

  5. Pursue perfection.

Flow distribution: the proportion of each flow item within a value stream adjusted depending on the needs of each stream to maximise business value.

Flow Time: the duration that it takes for a flow item to go from being accepted for work into the value stream to completion including both active and wait time.

Tool repositories, for example, JIRA, are the most directly observable information that defines software delivery.

Moving from Project to Product Includes:

  • Putting software delivery at the core of the organisation, not an isolated department

  • Measuring to outcomes, instead of activities.

  • Automating the entire deployment pipeline and delivering in small batch sizes.

  • Avoiding Proxies. Don't believe that if you're doing the process right customer outcomes will automatically get met.

Management Challenges

Management often lacks visibility into what is going on in a value stream.

Fundamental Questions Management struggle to answer:

  • Who is the customer?

  • What value is the customer pulling?

  • What are the value streams?

  • Where is the bottleneck?

Just as we need tools to see how electricity flows for a grid or factory rules management need a new approach to see how knowledge workflows through the tools on which software collaboration and knowledge creation are tracked.

Management often measures transformations for cost reduction but this will often reduce productivity.

Technologists tend to create software architectures around technology boundaries instead of value stream boundaries. The result is a lack of alignment between the three key structures involved with software delivery:

  • The organisation and team structure

  • The software architecture

  • The value stream architecture

Functional specialisation and tool proliferation creates a lack of transparency in the value stream network.

Measuring Value Stream Networks:

The most important metric for each value stream is an objective measure of value. This should come directly from the financial metrics used by the organisation. For example for customer-facing products, the metric could be overall revenue from that product or monthly recurring revenue.

Measuring business results

  • Value - the benefit to the business produced by the value stream

  • Cost - the cost of the value stream to the business

  • Quality - the quality of the product produced by the value stream as perceived by a customer.

  • Happiness - engagement of the staff working on the value stream.

Software vs Manufacturing


Manufacturing has a fixed well-defined set of variations for what will emerge from the end of the line, whereas the design of software features is open-ended manufacturing needs to minimise variability software development needs to embrace it.


Manufacturing is about maximising throughput at the same widget software is about maximising the iteration of feedback loops that continually reshape the widget. We need repeatability at each stage of the software delivery, such as reliable automated deployment, for each end to end process needs to be optimised for flow feedback and continual learning, not just repeatability.

Design Frequency

Manufactured products like cars are designed upfront in Project-oriented cycles spanning years, changes in design are infrequent and require altering the production lines so with software the shift to product orientated features increases the frequency of design to match the rate of flow items passing through the value stream to design happens inside and outside the production system.


Manufacturing processes, aim to achieve the highest feasible level of automation, which is facilitated by removing any creative and non-deterministic work from the production process. In contrast software delivery focuses on enabling creativity and collaboration at each step using automation to support creativity.

5 sources of Waste

  1. Too much work in progress

  2. Unknown dependencies

  3. Unplanned work

  4. Conflicting priorities

  5. Neglected work.

Blinkist Wide


bottom of page