The 175 flow principles: Why product development is often slower than necessary
Flow describes the flow of work through an organization: requirements, specifications, designs, tests, approvals, etc. In mechanics, this can be a screw, in electronics a circuit board re-spin, in software a feature, in business a budget approval. As long as a flow item has not been released, the company does not earn any money from it.
The idea behind flow is an old one: Taylor and Gilbreth were already investigating movements and bottlenecks in factories in the early industrial age. Henry Ford used the assembly line to show how a continuous flow of work could be translated into productivity and profit. Toyota later refined the flow-based concept under the name of lean manufacturing.
As the importance of services and software grew, these ideas migrated to knowledge work. Today, we talk about flow in support tickets, change requests, deployments and design documents. Donald G. Reinertsen has transferred the idea of flow into the 21st century for product development. His book The Principles of Product Development Flow combines lean, economics, queueing theory and modern network technology into a consistent model for faster, more economical development. These ideas and the 175 flow principles are the subject of the following article.
The story of Flow
On this basis, Flow has developed from a production concept into a universal model for knowledge work. In product development, work items are tickets, requirements, architectures or test cases. Agile methods and DevOps make this flow visible and measurable. Kanban boards, lead times, cumulative flow diagrams and telemetry in operating systems show the flow of work.
However, classic systems engineering and flow do not really go together without adaptation: Phase gates, for example, block the flow.
Quality Gates: Don't ask, don't tell
When I ask managers in my product development courses, 95 percent admit that they start designing before they know all the requirements. In fact, the average product developer starts designing when 50 percent of the requirements are known. However, they do not disclose this to management. Instead, they perform the time-honored ritual of asking permission to proceed. There is a tacit „don't ask, don't tell” policy. Managers politely avoid asking if next phase activities have already started, and developers discreetly avoid mentioning that they have already moved on. In practice, despite the existence of a dysfunctional formal procedure, sensible behavior prevails.
Donald G. Reinertsen, in The Principles of Product Development Flow: Second Generation Lean Product Development
The book
The Principles of Product Development Flow by Donald G. Reinertsen was published in 2009 and is now regarded as the standard work for flow in product development.
The subtitle of the book is: „Second generation lean product development“. Why second generation? The first generation of lean approaches mainly transferred practices from production: reduce waste, standardize processes, „do it right the first time“. Reinertsen argues that product development runs in a completely different way to production: high uncertainty, high variability, non-repeatable tasks, unevenly distributed delay costs. A second generation of lean must therefore be economically based, statistically sound, tolerant of variability and consistently optimized for flow, not local efficiency.
The heart of the book is a structured collection of 175 flow principles, divided into eight groups. On the Companion website lpd2.com all the principles are listed, so I won't repeat them here. The book itself is an excellent reference work and checklist.
The theory: errors in thinking in product development
Reinertsen's starting point is brutally honest: the dominant paradigm for product development is wrong in its basic assumptions. Not a little, but fundamentally.
The dominant paradigm for product development is fundamentally wrong in its basic assumptions.
Donald G. Reinertsen, in The Principles of Product Development Flow: Second Generation Lean Product Development
A central error in thinking is the Dealing with added value. Many organizations optimize proxy metrics: Utilization, on-time delivery, „% value-added time“. What is almost always missing is an explicit quantification of profitability, especially the Cost of Delay. If you don't know what a week's delay costs, you can neither set priorities sensibly nor assess queues. The result is decisions that are made on the basis of gut feeling, political assertiveness or local optimization, but not on the basis of overall economic benefit.
The second major blind spot is Queues. In development, there are huge stocks of work that has been started but not completed: Specs in Review, Designs „Almost Done“, Tickets „In Progress“. These work-in-process inventories are financially invisible (they are not in any warehouse account) and physically inconspicuous (bits on hard disks instead of pallets in the hall). High capacity utilization and large WIP inventories initially appear efficient, but extend the throughput time via queues and drive up risks and context switching costs.
Third point: Variability is almost always seen as a problem. Standard responses are checklists, stage-gate processes, best practices and, in extreme cases Six Sigma-thinking in development (and not production, where it makes perfect sense). Reinertsen turns this around: Without variability, there is no innovation. The decisive factor is not to minimize all variance, but rather to economic consequences for example through fast feedback loops, experimenting with small batch sizes or deliberately shifting variability to early, cheaper phases.
There is no innovation without variability!
Donald G. Reinertsen, in The Principles of Product Development Flow: Second Generation Lean Product Development
Fourth mistake: We manage Timelines instead of queues. Traditional project plans break work down into the finest subtasks with fixed deadlines. Every uncertainty leads to buffers, every buffer further inflates the plan. Reinertsen argues that it is much more effective to control WIP limits and queues than to maintain exact Gantt charts. If you have your queues under control, you get throughput times under control for practically nothing.
The principles: What does „principle“ mean?
Reinertsen's „principles“ differ fundamentally from the few guiding principles that set the tone, as I described them in Product Velocity use. They do not provide normative orientation, but describe recurring mechanisms. Essentially, they are systemic regularities or patterns that become visible again and again in product development and that need to be understood in order to make well-founded decisions.
Such statements are, for example: „High capacity utilization generates disproportionately growing queues“ or „Small batches accelerate feedback“. These are not compass principles, but decision modules that make typical cause-and-effect relationships transparent.
In practice, these laws are used as diagnostic tools. In the event of a bottleneck, the capacity is not examined reflexively, but known influencing variables such as queues, variance, batch sizes, WIP limits or feedback cycles are checked. The patterns make visible what is actually happening in the system and enable targeted interventions. They do not replace the guiding principles, but they sharpen the focus on the mechanics of the flow and help to analyze problems in a structured way.
Below is an overview of the eight groups of principles and an example of each principle.
1. economic principles (21 principles)
This group ensures that decisions are consistently geared towards overall economic benefits instead of local optima such as „maximum utilization“ or „minimum budget“. Typical problems in practice: nobody knows the cost of delay of a project, roadmaps are prioritized according to „political importance“, late acceleration actions are extremely expensive, although early speed gains would be much cheaper.
A central principle is: „If you only quantify one thing, quantify the cost of delay.“ Anyone who knows what a week's delay costs can suddenly make a very sober assessment of backlogs, conflicts over resources and escalations. In practice, this means calculating scenarios together with product management and controlling (market window, price collapse, contractual penalties), deriving simple decision rules from this and making these rules available in a decentralized manner.
2. queuing principles (16 principles)
The aim here is to make queues visible and control them in a targeted manner. Typical problems: Overloaded specialists, mountains of „work in progress“, projects that seem to be „in progress“ forever. Many organizations measure throughput times, but not the underlying queue sizes and workloads.
A representative principle: „Waiting time = queue size / processing rate“ (Little's Law). It's frighteningly simple: if the pile of work in front of a team doubles, the waiting time doubles on average. In practice, this can be exploited by introducing explicit WIP limits and visualizing how many elements are in front of a process step. Instead of driving the workload back up to 99 %, you consciously reduce WIP and accept apparent „idle time“ in order to significantly reduce the overall throughput time.
Incidentally, this is a topic that Joachim Pfeffer knows extremely well.
3. variability principles (16 principles)
This group addresses the handling of uncertainty and variability: fluctuating ticket sizes, unreliable suppliers, fluctuating quality of requirements. Classic: You try, all variability instead of reducing the economically relevant one.
A typical principle: „Variability can create economic value.“ If the positive surprise (e.g. a successful prototype) is worth significantly more than the negative one (a rejected attempt), then an experimental approach with many small trials is worthwhile. In practical terms, this means smaller, cheaper experiments, deliberately higher „failure rates“ in early phases, reuse where variance brings no added value, and buffers where the consequences of variance are really expensive.
4. batch size principles (22 principles)
This is all about batch size: how much work do we bundle before we pass it on or release it? Classic patterns are huge requirements documents, large design packages or rare, risky releases. At first glance, large batches seem efficient, but they slow down feedback and increase risk.
A representative principle: „If you reduce the batch size, you shorten the lead time and accelerate feedback.“ In practice, this means: smaller requirements packages, more frequent, automated builds, continuous integration even in hardware-related areas (e.g. early prototypes), more „slice of system“ instead of „specify everything first, then design everything“.
5 WIP limitation principles (23 principles)
These principles describe how to actively limit work-in-process in order to control lead time and flow. Typical problems: too many projects running in parallel, „start-stop-start“ context switches, technical debt that is never reduced.
An exemplary principle: „Limit WIP to control lead time.“ Instead of starting another project even though the existing ones are already struggling, the number of parallel initiatives is capped. At team level, this means Kanban with clear WIP limits, at portfolio level a hard limit for active projects. It is often enough to pause or kill projects that are economically weak in order to gain massive speed on the important streams.
6. flow control, timing and synchronization principles (30 principles)
This group deals with how work is prioritized, timed and synchronized: Which task comes next? How do we avoid overload? How do we coordinate many teams? Classic problems: too many ad hoc priorities, unpredictable meetings, queues explode when „everything is urgent at the same time“.
An important principle: „If duration and cost of delay are not homogeneous, use Weighted Shortest Job First (WSJF).“ Instead of simply serving „biggest project first“ or „loudest voice first“, work is sorted according to (cost of delay / duration). Smaller, economically important jobs go to the front, large, less valuable ones to the back. In conjunction with fixed cycles (e.g. bi-weekly planning cycles, regular synchronization events), a system is created that can handle variability without tipping over into chaos.
7. quick feedback principles (24 principles)
This is about feedback loops: How quickly do we realize we're wrong? How early do customers see something? How quickly does a problem in the field affect development? Typical problems: long review cycles, late tests, metrics that are only evaluated „after the project“.
A representative principle: „Fast feedback enables faster learning.“ In practical terms, this means early tests at prototype level, regular demos, telemetry in the field, A/B tests, short build and test cycles. It is important to get feedback economic to consider: It is worth testing once more if it avoids costly mistakes, but not dogmatically correcting every deviation if the economic impact is low.
8 Decentralization principles (23 principles)
The last group deals with the question of who actually decides. Complete centralization may create formal consistency, but it is slow and blind to local information. Complete decentralization leads to chaos. Reinertsen draws heavily on modern military doctrine here: clear direction, decentralized initiative.
An important principle: „Describe the mission and boundary conditions, not the detailed plan.“ Instead of defining, like The management determines how the teams have to implement every detail, Why what is important, what result is expected and what limits apply (budget, time, regulatory requirements). Teams then decide locally which measures make sense in terms of flow and economy. This requires trust, transparency and simple decision-making rules, but pays off massively in terms of reaction speed and adaptability.
Conclusion: How to use the 175 flow principles
Reinertsen's book is not for a quick evening read, but it is an extremely productive toolbox. It is best to use the 175 flow principles not as a collection of theory, but as a practical checklist: Where do we break flow principles? Where do we ignore queues? Where do we optimize local efficiency instead of overall economic benefit?
The Companion website gives a quick overview of the principles, but if you want to delve deeper, there is no getting around the book itself. The Principles of Product Development Flow provides not only the 175 principles, but also the underlying economics, examples and typical pitfalls. For organizations serious about working on their product development velocity, it is a reference work and an invitation to fundamentally revise their own thinking about flow.
Image: Vivek Gupta
