The Principles of Product Development Flow

🧠 Free Recall ❓ Quiz 🔍 Cues 🔮 Simulation 🥷 ShadowBox 📐 Encode Cards

Author: Donald G Reinersten

Most Important Ideas
(1) Make decisions by their economics
(2) Understand queues, make them visible
(6) Reduce Batch Sizes - Size of the tasks in queues, like user stories v. large reqs
(4) Find the right balance of variability (Don't try to prevent nor celebrate variability/randomness/failure)
(13) Use Fast Feedback
 (9) Place constraints and watch WIP like a hawk
(11) Understand the flow, the relation between queues, batchsizes, and throughput

Queues v. Batch

Queue of 3
X -- X -- X
Queue of 3 with Big Batches
100 -- 100 -- 100 (300)
Queue of 6 with split batches
50 -- 50 -- 50 -- 50 -- 50 -- 50 (300)
Two queues of 3 with split batches (desired)
50 -- 50 -- 50
50 -- 50 -- 50

95 percent will admit that they begin design before they know all requirements. In fact, the average product developer begins design when 50 percent of requirements are known. They simply do not publicize this to management. Instead, they engage in a time-honored ritual of asking for permission to proceed. There is a tacit “don’t ask, don’t tell” policy. Managers politely avoid asking if the next phase’s activities have already begun, and developers discreetly avoid mentioning that they have already moved on.

this paradigm emphasizes small batch transfers, rapid feedback, and limited work-in-process inventory (WIP). These three specific methods are actually broadly applicable throughout the development process. When we recognize why they work, we can adapt them to dozens of situations.

FIFO prioritization is almost never economically optimal in product development, because product development deals with high variability, nonrepetitive, nonhomogeneous flows. Different projects almost always have different delay costs, and they present different loads on our resources. As you shall see, these new challenges force us to go far beyond the ideas of lean manufacturing. If we are open to advanced ideas from other domains, we can do this. To distinguish this more advanced approach from the ideas of lean manufacturing, we call it Flow-Based Product Development.

At its heart, this new paradigm emphasizes achieving flow.

1.Failure to Correctly Quantify Economics
We don't have a way to quantify the business costs of the product lifecycle
We create proxy variables instead of variables that measure life cycle profits 
What is the cost of delay? If project is 60 days late, what would it cost our company in pretax profit?

Perhaps the single most important weakness of the current orthodoxy is its failure to correctly quantify economics.

Today, developers focus on what we call proxy variables. A proxy variable is a quantified measure that substitutes for the real economic objective: life-cycle profits. For example, developers measure development cycle time and seek to make it shorter. However, when you ask them how much life-cycle profit will decrease due to a week of delay, they don’t know.1 Cycle time is only a proxy variable.

Economic Framework
The Principle of Quantified Overall Economics: Select actions based on quantified overall economic impact.
The Principle of Interconnected Variables: We can’t just change one thing.
The Principle of Quantified Cost of Delay: If you only quantify one thing, quantify the cost of delay.
The Principle of Economic Value-Added: The value added by an activity is the change in the economic value of the work product. Value added = price economically rational buyer would pay before and after the activity is performed
The Inactivity Principle: Watch the work product, not the worker. In product development, our problem is virtually never motionless engineers. It is almost always motionless work products.
The U-Curve Principle: Important trade-offs are likely to have U-curve optimizations.
The Imperfection Principle: Even imperfect answers improve decision making.The other thing to realize about our economic decisions is that we are trying to improve them, not make them perfect.
The Principle of Small Decisions: Influence the many small decisions.
The Principle of Continuous Economic Trade-offs: Economic choices must be made continuously.
The First Perishability Principle: Many economic choices are more valuable when made quickly. Opportunities get smaller with time, and obstacles get larger. The longer we wait to exploit an opportunity or to deal with an obstacle, the less economic value is available. This, too, has important implications for our decision-making process. It means we must explicitly measure, and shorten, the time it takes to make a decision. if most opportunities and obstacles are first visible to people at the lowest level of the organization, then this level should be able to make these decisions. This suggests a strategy of decentralized control
The Subdivision Principle: Inside every bad choice lies a good choice. Most of our decisions can be decomposed into component parts that individually have distinct economics. This means that we can often isolate a good choice inside a bad one. It is always useful to look for a way to reshape a bad choice into a better one. Decompose the choice into its pieces and keep the good parts. How do we know what the good parts are? Our economic framework permits us to evaluate the components of a decision on the basis of cost and benefit. We can decide which parts to keep and which ones to discard. Decomposition and recombination are enabled by having a way to measure the economics of the individual pieces. This allows us to recombine these pieces in a more economically desirable configuration.
The Principle of Early Harvesting: Create systems to harvest the early cheap opportunities.
The First Decision Rule Principle: Use decision rules to decentralize economic control. The most important tool for influencing the many small decisions is economic decision rules. Such decision rules accomplish four things. First, they align all the economic choices on the entire project. Second, they ensure that these choices are optimum at the system level. Third, they enable us to push control down to low levels with limited risk. Finally, they streamline the process of making decisions. By dramatically reducing the marginal effort required to make good economic choices, they make it possible to control many more decisions. control the economic logic of the decision. Control without participation is control without decision-making delays.
The First Market Principle: Ensure decision makers feel both cost and benefit.
The Principle of Optimum Decision Timing: Every decision has its optimum economic timing. The general principle is that we should make each decision at the point where further delay no longer increases the expected economic outcome. (When are the economics of this decision cheap? When are they expensive?)
The Principle of Marginal Economics: Always compare marginal cost and marginal value. When we evaluate the economic impact of an incremental decision, we should compare marginal value and marginal cost. The term “marginal” refers to the amount by which parameters change when we make very small changes in other parameters. For example, the marginal cost of a feature is the increase in product cost (of delay) caused by adding that feature.
Example. Projects may achieve 95 percent of their performance objectives quite quickly, but they may struggle to attain the last 5 percent. Should they fully consume their allotted schedule or opt to deliver 95 percent of the value without further delay? The economic question is whether that last 5 percent is truly worth the expense and cycle time that will be consumed.
The Sunk Cost Principle: Do not consider money already spent. Money we have already spent is a “sunk cost” and should not enter into an economic choice. We should make the choice on marginal economics.
The Principle of Buying Information: The value of information is its expected economic value. Information reduces uncertainty. When we reduce the uncertainty of an economic outcome, we create economic value. But, what should we pay for this increased certainty? We should not pay more than the economic value that it creates.It is important to recognize that investments in product development can create economic value even when they do not lead to successful products. This is because they can create information that has economic value. Information makes economic outcomes clearer. It lets us make better economic choices. It reduces uncertainty and this reduction in uncertainty has a quantifiable economic value. Low-cost activities that remove a lot of risk should occur before high-cost activities that remove very little risk.
For example, the first version of Microsoft Windows, Windows 1.0, was a market failure. However, it generated valuable information that influenced later versions of the product.
The Insurance Principle: Don’t pay more for insurance than the expected loss. Parallel development of a backup solution is an insurance policy; we pay money to reduce risk. Whenever the economic benefit of this risk reduction is less than the cost of insurance, it is not a good investment.
The Show Me the Money Principle: To influence financial decisions, speak the language of money. Most corporations give control over financial resources to people who worry about the economics of their choices. To influence these people, we must speak the language of economics, not the language of proxy variables. In my experience, most managers make amazingly fast decisions when they are presented with compelling economic arguments.

2.Blindness to Queues

Few developers realize that queues are the single most important cause of poor product development performance.

Queues cause our development process to have too much design-in-process inventory (DIP). Developers are unaware of DIP, they do not measure it, and they do not manage it. They do not even realize that DIP is a problem. For example, product developers will say that they want to be more innovative and never realize that high levels of DIP undermine this objective. When DIP is high, cycle times are long. When cycle times are long, innovation occurs so late that it becomes imitation.

There are two important reasons why product developers are blind to DIP. First, inventory is financially invisible in product development. We do not carry partially completed designs as assets on our balance sheet; we expense R&D costs as they are incurred. If we ask the chief financial officer how much inventory we have in product development, the answer will be, “Zero.” Second, we are blind to product development inventory because it is usually physically invisible. DIP is information, not physical objects. We do not see piles of DIP when we walk through the engineering department. In product development, our inventory is bits on a disk drive, and we have very big disk drives in product development.

queues lie at the root of a large number of product development problems. They increase variability, risk, and cycle time. They decrease efficiency, quality, and motivation.

To understand the economic cost of queues, product developers must be able to answer two questions. First, how big are our queues? Today, only 2 percent of product developers measure queues. Second, what is the cost of these queues? To answer this second question, we must determine how queue size translates into delay cost, which requires knowing the cost of delay. Today, only 15 percent of product developers know their cost of delay. Since such few companies can answer both questions, it should be no surprise that queues are managed poorly today.

I must stress that the ultimate root cause of this queue blindness lies in the failure to correctly quantify our economics. We can learn to see whatever we consider to be important. Once we quantify the cost of delay, we become aware of the cost of queues. Once we recognize the cost of queues, we are motivated to measure and manage them. Without a cost of delay, queues appear to be free and therefore, unworthy of attention.

Queue Vocabulary
Queue - system of waiting work
server - resource performing the work
arrival process - the pattern with which work arrives
service process - time it takes the server to accomplish the work 
queueing discipline - FIFO, handling work first in first out
occupancy - number of items in a queue / number of items in service / items in entire system
cycle time - time spent in queue / time spent in service / total time spent in system

Queue Framework
The Principle of Invisible Inventory: Product development inventory is physically and financially invisible. just because this inventory is invisible doesn’t mean it doesn’t exist. Product development inventory is observable through its effects: increased cycle time, delayed feedback, constantly shifting priorities, and status reporting. All of these effects hurt economic performance.
The Principle of Queueing Waste: Queues are the root cause of the majority of economic waste in product development. queues are invisible, there are no natural predators keeping them under control. Companies do not measure queues, they do not manage queues, and most don’t even realize that queues are a problem. Queues produce six forms of waste
First, queues increase cycle time. It takes longer to reach the front of a large line than a small one. By quantifying cost of delay, we can attach a specific financial cost to this queue time. Usually, delay cost rises linearly with queue size.
Second, queues increase the riskiness of a product development process. Queues increase the transit time through the product development pipeline. When the transit time goes up, we are more vulnerable to changes in customer preference, preemption by competitor product introductions, and shifts in underlying
Third, queues increase the variability of our development process. When we load our development process to high levels of utilization, we are at an operating point that tends to amplify variability. As we shall see later in this chapter, this means that small deviations in loading will turn into very large deviations in cycle time.
Fourth, queues raise the costs of our process. The more projects we have in process, the more projects we have to track and report status on. Even worse, we will ask for more progress reports per project because queues lead to long transit times.
Fifth, queues reduce quality by delaying feedback from downstream processes. If a programmer makes a bad assumption about a protocol and gets feedback one day later, she stops making this bad assumption. If she must wait for 30 days to get this feedback, she will embed the bad assumption into 30 days’ worth of code. Queues delay feedback, and delayed feedback leads to higher costs. This feedback effect is orders of magnitude more important in product development than manufacturing because manufacturing work is inherently repetitive. In contrast, in product development, we are constantly trying new ideas and we rely on rapid feedback to truncate unproductive efforts. We cannot truncate a bad path quickly when feedback is slow. This is actually a more serious problem than most developers realize because the waste created by following a bad path typically increases exponentially, not linearly, as we progress down the path.
Sixth, queues have a negative psychological effect. They undermine motivation and initiative. When the next process will be ready to use our work product within an hour, we feel a sense of urgency. When the next process has a 4-week queue, we feel there is little value in hurrying to finish our work. After all, our work product will simply wait in queue. Widespread queues demotivate workers and undermine initiative.
The Principle of Queueing Capacity Utilization: Capacity utilization increases queues exponentially. The single most important factor that affects queue size is capacity utilization.
The Principle of High-Queue States: Most of the damage done by a queue is caused by high-queue states.
The Principle of Queueing Variability: Variability increases queues linearly.
The Principle of Variability Amplification: Operating at high levels of capacity utilization increases variability.
The Principle of Queueing Structure: Serve pooled demand with reliable high-capacity servers.
The Principle of Linked Queues: Adjacent queues see arrival or service variability depending on loading.flow through a bottleneck is affected strongly by the process that precedes the bottleneck. The upstream process determines the variation in the arrival rate at the bottleneck, and this affects the queue. Managing the process upstream of the bottleneck is a valuable tool for improving flow at the bottleneck.
The Principle of Queue Size Optimization: Optimum queue size is an economic trade-off.
The Principle of Queueing Discipline: Queue cost is affected by the sequence in which we handle the jobs in the queue. Jobs have different delay costs, and they block resources for differing amounts of time. As a result, we can create value with a thoughtful queueing discipline. For example, if two jobs take the same amount of time, it is better to service the one with the highest delay cost first. If two jobs have the same cost of delay, it is better to process the shortest job first. Two simple heuristics: high cost of delay before low cost of delay, and short jobs before long jobs.
The Cumulative Flow Principle: Use CFDs to monitor queues.
Little’s Formula: Wait Time = Queue Size/Processing Rate
The First Queue Size Control Principle: Don’t control capacity utilization, control queue size.
Many supermarkets cross-train check stand operators to perform other tasks. These stores monitor the size of queues at check stands. As soon as they have more than three customers in line, they open up a new check stand. When the queues are cleared, they close the extra check stand. This is a highly effective way to provide quality of service in the face of uncertain demand.
I saw this at Las Vegas, I was at a CVS, and the line starting piling up, and then I saw 5 cashiers mobilize and then they cleared the queue very quickly
The Second Queue Size Control Principle: Don’t control cycle time, control queue size.
The Diffusion Principle: Over time, queues will randomly spin seriously out of control and will remain in this state for long periods.
The Intervention Principle: We cannot rely on randomness to correct a random queue.

Specialists Finally, we should point out that almost any specialist can become a queue. This occurs because specialists are scarce resources and they are typically managed for efficiency. Furthermore, the pressure for efficiency leads to late involvement, which can raise costs even more.

This is exactly what is happening at Confluent using specialist SEs to help on calls. We're creating a scare resource for efficiency and that pressure for efficiency leads to suboptimal involvement and experience for those requesting the specialists May 23, 2024 @ 7:59 AM

3.Worship of Efficiency

In reality, the misguided pursuit of efficiency creates enormous costs in the unmeasured, invisible portion of the product development process, its queues.

operating a product development process near full utilization is an economic disaster.

4.Hostility to Variability

First, without variability, we cannot innovate. Product development produces the recipes for products, not the products themselves. If a design does not change, there can be no value-added. But, when we change a design, we introduce uncertainty and variability in outcomes. We cannot eliminate all variability without eliminating all value-added.

Second, variability is only a proxy variable. We are actually interested in influencing the economic cost of this variability. When we start viewing variability this way, we usually discover it is much easier to alter the payoff-function than it is to reduce the underlying amount of variability.

Third, with a little help from option pricing theory, we will discover that we can actually design development processes such that increases in variability will improve, rather than worsen, our economic performance.

Minimizing the economic impact of variability is a profoundly different goal than minimizing variability.

The Principle of Beneficial Variability: Variability can create economic value.
The Principle of Asymmetric Payoffs: Payoff asymmetries enable variability to create economic value.
The Principle of Optimum Variability: Variability should neither be minimized nor maximized. Variability is not intrinsically desirable or undesirable. Variability is only desirable when it increases economic value. This occurs when the positive tail of the probability distribution extends far enough into a high payoff region to overcome the cost of the negative tail.
The Principle of Optimum Failure Rate: Fifty percent failure rate is usually optimum for generating information. The point where there is a 50 percent chance of failure lies at the peak of this information curve. Unfortunately, most companies do a far better job of communicating their successes than their failures. They carefully document successes, but fail to document failures. This can cause them to repeat the same failures. Repeating the same failures is waste, because it generates no new information. Only new failures generate information.
The Principle of Variability Pooling: Overall variation decreases when uncorrelated random tasks are combined. aggregate many small tasks and to schedule them as a group. Aggregation pools variability and improves the signal-to-noise ratio of our estimates.
The Principle of Short-Term Forecasting: Forecasting becomes exponentially easier at short time-horizons. The most powerful way to reduce variability in forecasts is to shorten our planning horizons. Smaller scope leads to faster development, which shortens time-horizons. Reduced scope and shorter time-horizons combine to reduce risk. Lower risk means we don’t need high levels of management involved. This further reduces decision-making delays.
The Principle of Small Experiments: Many small experiments produce less variation than one big one.
The Repetition Principle: Repetition reduces variation. The effect of breaking large tasks into many smaller tasks is more than statistical. When we have many similar small tasks, we have an economic incentive to systematize the accomplishment of these tasks. This systemization further reduces variation. We uncover a superior approach and standardize around it. This reduces variability even further.
The Reuse Principle: Reuse reduces variability. Reuse is powerful for two reasons. First, reuse eliminates variability in completion time. Second, reuse reduces capacity utilization.
The Principle of Negative Covariance: We can reduce variance by applying a counterbalancing effect.
The Buffer Principle: Buffers trade money for variability reduction.
The Principle of Variability Consequence: Reducing consequences is usually the best way to reduce the cost of variability.
The Nonlinearity Principle: Operate in the linear range of system performance.
The Principle of Variability Substitution: Substitute cheap variability for expensive variability.
we are willing to pay expedite charges to ensure that the arrival of a part does not delay a project. We do this because we recognize that overspending our expense budget does less economic damage than missing our schedule.
The Principle of Iteration Speed: It is usually better to improve iteration speed than defect rate. Improving iteration speed is particularly attractive because it is usually cheaper to improve than iteration success rate. In most product development processes, iteration time is dominated by queue time, so our emphasis on reducing queues creates enormous payoff.
The Principle of Variability Displacement: Move variability to the process stage where its cost is lowest.

5.Worship of Conformance

They assume that the benefit of correcting a deviation from the plan will always exceed the cost of doing so. This places completely unwarranted trust in the original plan, and it blocks companies from exploiting emergent opportunities. Such behavior makes no economic sense. We live in an uncertain world. We must recognize that our original plan was based on noisy data, viewed from a long time-horizon. For example, we may have started development believing a feature would take 1 week of effort and it would be valued by 50 percent of our customers. As we progressed through development, we may have discovered that this feature will require 10 weeks of effort and it will only be valued by 5 percent of our customers. This is a factor of 100 change in its cost-to-benefit ratio. This emergent information completely changes the economics of our original choice. In such cases, blindly insisting on conformance to the original plan destroys economic value.

To manage product development effectively, we must recognize that valuable new information is constantly arriving throughout the development cycle. Rather than remaining frozen in time, locked to our original plan, we must learn to make good economic choices using this emerging information.

Conformance to the original plan has become another obstacle blocking our ability to make good economic choices. Once again, we have a case of a proxy variable, conformance, obscuring the real issue, which is making good economic decisions.

6.Institutionalization of Large Batch Sizes

Our blindness toward queues and our focus on efficiency lead us to institutionalize large batch sizes. Large batches seem attractive because they appear to have scale economies that increase efficiency. Furthermore, large batches appear to reduce variability because they pool many activities together. However, this efficiency gain and variability reduction is only an illusion.

The Batch Size Queueing Principle: Reducing batch size reduces cycle time. Batch size reduction can enable us to shorten cycle time, often by an order of magnitude or more, without changing capacity utilization.
The Batch Size Variability Principle: Reducing batch sizes reduces variability in flow.
The Batch Size Feedback Principle: Reducing batch sizes accelerates feedback.
The Batch Size Risk Principle: Reducing batch size reduces risk.
The Batch Size Overhead Principle: Reducing batch size reduces overhead.
The Batch Size Efficiency Principle: Large batches reduce efficiency.
Another interesting example occurs in software. When programmers work in large batches, they change many lines of code in a single release. What does this do to debug complexity? The complexity of the debug task grows as 2n when we change n things simultaneously (due to the number of system level interactions created by multiple changes). It is much more expensive to debug large changes than small ones. Again, the local efficiency gains of uninterrupted coding and large batch testing have been completely wiped out by the system-level losses due to increased complexity.
The Psychology Principle of Batch Size: Large batches inherently lower motivation and urgency.
The seventh beneficial effect of small batches is their power to motivate people. Large batches demotivate people in two ways. First, large batches dilute responsibility. If I am responsible for delivering one module of code in the next 5 days, I have no place to hide. If I am responsible for one of the 100 modules that are required for the next integration point 100 days from now, I feel much less urgency. After all, even if I am behind schedule, there appears to be plenty of time left before the integration point, and there are many other people who are more likely to get in trouble than I am. With 100 modules traveling together in a large pack, it is highly probable that somebody else will delay the integration point. As a result, the person responsible for a single module, quite correctly, feels less responsible for the overall outcome. Second, large batch sizes demotivate by delaying feedback. When engineers are experimenting with a new idea, rapid feedback is enormously energizing. Rapid feedback quickly supplies the positive reinforcement of success, and fast positive reinforcement always increases motivation. Rapid feedback causes us to subconsciously associate our delivery of a work product and the beginning of the next process step. This attribution of causality gives us a sense of control, instead of making us feel we are the victim of a massive bureaucratic system.
The Batch Size Slippage Principle: Large batches cause exponential cost and schedule growth.
The Batch Size Death Spiral Principle: Large batches lead to even larger batches.
The Least Common Denominator Principle of Batch Size: The entire batch is limited by its worst element.
The Principle of Batch Size Economics: Economic batch size is a U-curve optimization.
The Principle of Low Transaction Cost: Reducing transaction cost per batch lowers overall costs.
For example, huge improvements in software testing batch size are virtually always triggered by automation of testing. If it takes 24 hours to set up a test, we cannot test every 24 hours. We must invest in reducing transaction cost to enable the use of smaller batches.
The Principle of Batch Size Diseconomies: Batch size reduction saves much more than you think. A useful heuristic is to assume that the hidden costs of large batch size are about twice as high as you think. This would imply that optimum batch size is actually about 70 percent of whatever number you may calculate as optimum. Therefore, as a minimum, you should aim for a batch size that is 30 percent smaller than whatever you think is optimal. And what if you are wrong? The total cost equation would suggest that if you accidentally drop 33 percent below optimum batch size, you will only increase total cost by 8 percent. This is a risk worth taking.
The Batch Size Packing Principle: Small batches allow finer tuning of capacity utilization.
The Fluidity Principle: Loose coupling between product subsystems enables small batches.
The Principle of Transport Batches: The most important batch is the transport batch.
The Proximity Principle: Proximity enables small batch sizes.
The Run Length Principle: Short run lengths reduce queues.
While transport batches are our biggest opportunity, we can also gain benefits by reducing production lot sizes in product development processes. For example, we can avoid overloading a project with features, which results in infrequent product introductions and long development cycles. Instead, if we limit the number of new features and introduce products more frequently, we will get faster feedback from the market. A subtle advantage of shorter run lengths is that we can sequence tasks in such a way that variances do not accumulate. We can interleave hard jobs and easy jobs to prevent extended runs of hard jobs.
The Infrastructure Principle: Good infrastructure enables small batches. good infrastructure reduces transaction costs. good infrastructure permits different batches to be in different stages of completion.
The Principle of Batch Content: Sequence first that which adds value most cheaply. Shifting to smaller batch sizes in product development gives us the opportunity to use the work sequence to improve economics. We do this by carefully deciding which work content should go into each batch.
The Batch Size First Principle: Reduce batch size before you attack bottlenecks. Batch size reduction is cheaper than adding capacity, it is easy to sell to top management, and it massively reduces queues. It is always our weapon of choice for reducing queues.
The Principle of Dynamic Batch Size: Adjust batch size dynamically to respond to changing economics.the factors that lead to optimum batch size can be time-dependent. For example, the value of rapid feedback is high early in the project when risks are still high. During this stage, it makes sense to seek the fast feedback of small batch sizes. As we progress, the value of rapid feedback goes down and transaction costs can rise. At this point, it can make economic sense to move to a larger batch size.

On Scope

One of the most dangerous of all batch size problems is the tendency to pack more innovation in a single project than is truly necessary. Excessive project scope easily leads to the self-reinforcing death spiral

When schedules slip, it changes the competitive environment that the product will confront, so marketing requests additional features. The additional features require extra effort, further extending planning horizons and increasing technical complexity. This regeneratively escalates slippage. What is a small batch size approach? Don’t overload the project with excessive scope.

On Requirements

Most product development processes attempt to define 100 percent of requirements at the very beginning of the process.

Such an approach inherently leads to inferior designs because it breaks the feedback loop between design and specification. Design activities generate valuable information on the performance limits of our technologies and the cost impact of requested features. This information is vital for making optimal trade-offs between the cost and value of a feature. To get this information quickly, we must begin design before we finalize our specifications.

A practical approach for implementing smaller batches is to progressively lockdown requirements. Using this approach, some characteristics are frozen before others. In general, we freeze requirements that engineering needs first, before the ones that are needed later. We should never group all requirements into one large batch because this lets the slowest requirement hold up all of the work.

On Project Planning

It is common for people to try to prepare a complete and detailed plan for the project at the beginning of the project. This forces planning to be done at a long time-horizon, where forecasting is very difficult. This, in turn, leads to frequent and massive plan revisions.

A better alternative is to do high-level planning for the entire project, but to limit detailed planning to a short time-horizon. High-level planning has lower variability, because grouped tasks benefit from the variability pooling effect,

Some observers describe this approach as, “walking down the road in the fog.” We plan in detail what we can see clearly: the next several weeks. As we execute this plan, more of the road becomes visible. Now we can do more planning. Everything is done with a plan, but this is not a plan created in one large batch at the beginning of the project. It is plan created in small batches, with fresh information, and benefiting from knowledge acquired along the way.

Market Research

Market research is often done in large batch sizes. A single comprehensive test is created that answers many questions at the same time. After all, this allows us to exploit scale economies in doing research. But, such comprehensive tests often generate information late in development when the cost of reacting to it is high.

What is a better way to do this? Decompose the market research into a series of events. Start with small-scale tests focused on high-risk questions. As you progress, make the tests less frequent, larger scale, and more comprehensive. This enables rapid reduction of risk and generates information when it is cheapest to react to it.

7.Underutilization of Cadence

Today’s development processes typically deliver information asynchronously in large batches. A flow-based process delivers information on a regular cadence in small batches. In fact, cadence helps lower transaction costs and makes small batches more economically feasible.

But how do we prevent all these small review meetings from driving up overhead? We conduct these review meetings on a regular time-based cadence. Every Wednesday afternoon at 1:00 pm, we review all the drawings completed in the last week. There is no need for a meeting announcement and no need to coordinate schedules. Meetings that are synchronized to a regular and predictable cadence have very low set-up costs. They contribute very little excess overhead.

cadence helps to control the progressive accumulation of variability in development processes. Today’s orthodoxy constrains the scope of work and drives variability into timing. The new paradigm constrains timing and drives variability into the scope of work. These two approaches are fundamentally different.

8.Managing Timelines instead of Queues

Timelines. Today’s orthodoxy emphasizes managing timelines, rather than managing process queues. We train our project managers how to create these timelines and how to manage them. In fact, this was the same mistake we made in manufacturing before the arrival of the Toyota Production System (TPS). We created detailed timelines using our manufacturing planning systems. The more detailed we made our plans, the longer our cycle times became.

We favor highly granular planning because we don’t understand the statistics of variability.

Most product developers do not understand the statistics of granular schedules. A granular timeline subdivides time intervals into very small buckets. When we do this, the coefficient of variation for each of these buckets becomes very high. This makes variance very high and conformance unlikely. Even worse, if we incentivize conformance, people will insert contingency reserves to prevent their tasks from missing the schedule. The more granular the schedule, the larger the schedule reserves. And these reserves aggregate into even longer timelines. The more we increase planning detail and the harder we try to incentivize performance, the worse our problem becomes.

In contrast, when we emphasize flow, we focus on queues rather than timelines. Queues are a far better control variable than cycle time because, as you shall see, queues are leading indicators of future cycle-time problems. By controlling queue size, we automatically achieve control over timelines. Our blindness to queues and our misunderstanding of variability combine to hide this opportunity. The current orthodoxy focuses on planning and managing timelines, instead of the more powerful approach of managing queues.

9.Absense of WIP Constraints

WIP constraints are even more important in product development than manufacturing, because product development has higher inherent variability.

The Principle of WIP Constraints: Constrain WIP to control cycle time and flow. When we set a limit on WIP, we create one positive effect and two negative ones. The positive effect is to reduce average cycle time. The first negative effect is that we permanently reject potentially valuable demand. The second negative effect is that we ultimately reduce our capacity utilization, because we have permanently lost the demand that we rejected during periods of congestion.
The Principle of Rate-Matching: WIP constraints force rate-matching.
The Principle of Global Constraints: Use global constraints for predictable and permanent bottlenecks.
The Principle of Local Constraints: If possible, constrain local WIP pools.
The Batch Size Decoupling Principle: Use WIP ranges to decouple the batch sizes of adjacent processes.
The Principle of Demand Blocking: Block all demand when WIP reaches its upper limit.
The Principle of WIP Purging: When WIP is high, purge low-value projects. Whenever WIP is high, queues are high. When queues are high, jobs that are in process are generating high delay costs because of the multiplier effect described in Principle Q15. This means that the economics of holding WIP has changed. Therefore, we must ask whether jobs which were appropriate to hold in queue when costs were low are still appropriate to keep active with the new, higher, holding costs. It is logical to purge jobs of low value from the queue whenever there is a surplus of high-value jobs. This ensures that we will continue to generate open slots for the other high-value jobs that are constantly arriving.
The Principle of Flexible Requirements: Control WIP by shedding requirements. A smaller batch size approach to WIP purging is to shed requirements during periods of congestion. The underlying logic is that the economic cost of retaining a requirement rises during periods of congestion. This occurs because the delay cost generated by a requirement rises when it blocks a larger queue of waiting work. During such periods, it makes economic sense to drop requirements that have marginal economic benefits. We get a high payoff from such requirement relief, because we are already operating on the steep section of the queueing curve, where a small decrease in loading leads to a large savings in cycle time. It is best to identify in advance which requirements we would consider eliminating or relaxing. First, we can make a more well-reasoned decision before the pressure of a congestion crisis occurs. Second, if we preplan which requirements might be jettisoned, we can structure our product architecture to make it easy to jettison them. We do so by loosely coupling these elements to the rest of the system, so that we can cut them loose quickly. One of the biggest advantages of these three demand-focused approaches, demand blocking, WIP purging, and flexible requirements, is the speed with which they can be executed. In contrast, supply-focused approaches, which reduce WIP by adding capacity, often have longer response times.
The Principle of Resource Pulling: Quickly apply extra resources to an emerging queue.
The Principle of Part-Time Resources: Use part-time resources for high variability tasks. Which project activities are most suited for part-time resources? Those that are most prone to expensive congestion. These are high-variability tasks on the critical path. Activities that are more predictable can be handled with full-time resources, since such activities experience less congestion.
The Big Gun Principle: Pull high-powered experts to emerging bottlenecks.
The Principle of T-Shaped Resources: Develop people who are deep in one area and broad in many.
The Principle of Skill Overlap: Cross-train resources at adjacent processes.
The Mix Change Principle: Use upstream mix changes to regulate queue size.One of the least obvious ways to control emergent queues is to selectively hold back work that will make the queue worse. One of the most compelling WIP constraints in product development is limiting the number of active projects in the pipeline. When we limit active projects, we create a shorter flow time for the entire pipeline.
The Aging Principle: Watch the outliers.
The Escalation Principle: Create a preplanned escalation process for outliers. The simplest escalation process is to raise jobs to the attention of higher organizational levels when they pass a certain time limit in the queue.
The Principle of Progressive Throttling: Increase throttling as you approach the queue limit.
The Principle of Differential Service: Differentiate quality of service by workstream.
The Principle of Adaptive WIP Constraints: Adjust WIP constraints as capacity changes.
The Expansion Control Principle: Prevent uncontrolled expansion of work. In product development, it is not sufficient to prevent uncontrolled arrivals; we must also control the expansion of work. Some work in product development can behave like the perfect gas of physics. It expands to fill the container, no matter what size of the container. prevent these poorly behaved jobs from locking up the system by setting a limit on how long any job can run. This time-out limit ensures that one poorly behaved job cannot block all other jobs. A second strategy for blocking task expansion is to terminate a task when we reach the point of diminishing returns. We can view this as establishing a minimum acceptable progress rate.
The Principle of the Critical Queue: Constrain WIP in the section of the system where the queue is most expensive.
The Cumulative Reduction Principle: Small WIP reductions accumulate. If we consistently complete more work than we start, our queue will progressively become smaller. The cumulative effect can be enormous.
The Principle of Visual WIP: Make WIP continuously visible. Inventory in product development is information, and information is usually invisible. To manage this information effectively, we must make it visible. We can do this by using physical artifacts as tokens to represent this invisible inventory.

10.Inflexibility

In pursuit of efficiency, product developers use specialized resources loaded to high levels of utilization. Our current orthodoxy accepts inflexibility in return for efficiency. But what happens when this inflexibility encounters variability? We get delays. So what do we do? The current orthodoxy suggests that we focus on the variability. We can reduce this variability directly, or we can build buffers and reserves to mask the variability.

11.Noneconomic Flow Control

In general, it is best to delay the project with a low cost of delay. This suggests that we should not prioritize on the basis of project profitability, but rather on how this profitability is affected by delay. Of course, this can only be done when we know the cost of delay, information that 85 percent of developers do not have.

WIP constraints are powerful, but they do not solve all our problems. WIP constraints do not ensure we have selected a high-throughput operating point. WIP constraints do not prevent the gradual accumulation of variances in concatenated process steps. WIP constraints don’t ensure we are processing work in the economically optimum sequence. We need additional tools to solve these problems.

Congestion is a system condition that combines high capacity utilization and low throughput. The onset of congestion can be gradual but it is more likely to be sudden and catostrophic

Flow = Speed X Density

Vehicles/hour = Miles/hour * Vehicles/mile

Flow is parabolic, meaning there is a peak flow for combination of throughput and speed.

Product developers also experience drops in throughput during periods of congestion. When we cram too many projects into the product development pipeline, we create queues. These queues create a frictional drag on throughput as developers spend more time expediting and less time adding value. The added load reduces output instead of increasing it.

Falling throughput leads to increased load, which then drops throughput even faster.

Cadence is the use of a regular, predictable rhythm within a process. This rhythm transforms unpredictable events into predictable events. It plays an important role in preventing variability from accumulating in a sequential process.

Synchronization is valuable when we gain economic advantages from processing multiple items at the same time. These advantages may arise from cost advantages, such as scale economies in processing, or from the situations where there is higher value in processing multiple items simultaneously.

Sequencing Work

sequencing matters most when queues are large. By operating with small queues, we minimize the payoff of sequencing and, thus, the need to do it.

In other words, when we have fewer things to do, the order in which we do them matter less. If we had 1 thing to do, it's not even a conversation. With two things you can't go too wrong... three and we begin needing to triage... 4, 5,6....

A good mental model for thinking about sequencing issues is a hospital emergency room. Hospital emergency rooms perform tasks with nonhomogeneous durations and nonhomogeneous costs of delay. They must deal with random arrivals. Their work flow has more in common with product development than the repetitive homogeneous flows found in a factory. For example, consider the point made in the last paragraph, that queueing discipline provides little payoff when queues are small. When emergency rooms are heavily loaded, they practice triage, the classification of incoming work into priority categories. However, triage is not necessary when waiting lines are very short. Under such conditions, all cases will be serviced quickly, so very little prioritization is required.

The Principle of Congestion Collapse: When loading becomes too high, we will see a sudden and catastrophic drop in output. When utilization reaches a certain critical level, there is a sharp and unexpected collapse in the throughput curve. Congestion collapse creates a sharp discontinuity in the throughput curve. At one moment, everything is fine; at the next, the system is incapacitated. When congestion occurs, performance is no longer a simple extrapolation of throughput at lower loads.
The Peak Throughput Principle: Control occupancy to sustain high throughput in systems prone to congestion. best to operate slightly below peak throughput on the stable side of the curve. Since the curve is quite flat near its peak, the shift off peak costs very little throughput, but it gives us sufficient margin to absorb variability in flow without triggering the degenerative feedback that causes congestion collapse. It is easiest to control occupancy.
The Principle of Visible Congestion: Use forecasts of expected flow time to make congestion visible. We cannot control congestion if we do not know it is there. Since only 2 percent of product developers measure queues, most developers are only vaguely aware of congestion in their processes. It is better to provide the user with a forecast of expected flow time. Expected flow time can be calculated using Little’s Formula, by dividing the WIP by the current processing rate. Flow-time forecasts allow users to make informed choices.
The Principle of Congestion Pricing: Use pricing to reduce demand during congested periods.
The Principle of Periodic Resynchronization: Use a regular cadence to limit the accumulation of variance.
The Cadence Capacity Margin Principle: Provide sufficient capacity margin to enable cadence. If we wish to meet a regular product launch schedule, then we need enough capacity margin to absorb schedule delays at intermediate milestones. This is an economic trade-off. We must compare the cost of the capacity margin to the economic damage done by the catastrophic accumulation of variances.
The Cadence Reliability Principle: Use cadence to make waiting times predictable.
The Cadence Batch Size Enabling Principle: Use a regular cadence to enable small batch sizes. Cadence is also an important tool for enabling small batch sizes. It enforces small batch size by forcing work products to move forward on a fixed rhythm. But cadence also has an important effect on transaction costs. A regular cadence enables small batch sizes by reducing coordination overhead. With a lower fixed transaction cost, we can use smaller batch sizes, processing drawings at more frequent intervals. Cadence inherently makes activities automatic and routine. This lowers transaction overhead and makes it economical to use smaller batches.
The Principle of Cadenced Meetings: Schedule frequent meetings using a predictable cadence. With more frequent opportunities for coordination and feedback, we simply can’t get very far off track. When we synchronize our meetings to a regular cadence, we can eliminate this unnecessary transaction overhead. When meetings take place at the same time every week or every day, coordination overhead is minimal.
The Synchronization Capacity Margin Principle: To enable synchronization, provide sufficient capacity margin.
The Principle of Multiproject Synchronization: Exploit scale economies by synchronizing work from multiple projects.
Let’s look at another example: project reviews. One company wanted to move to smaller, more frequent project reviews. Instead of reviewing projects every 8 weeks, they wanted to review them every 2 weeks. They were worried that this would increase overhead since it quadrupled the number of reviews. They prevented this by reviewing four projects in the same session, as shown in Figure 7-5. Instead of conducting a 4-hour review of each project once every 8 weeks, they conducted a 1-hour review for each of four projects every 2 weeks. They preserved the scale economies of their meetings by combining work from multiple projects. At the same time, they increased the meeting frequency and the speed of feedback.
The Principle of Cross-Functional Synchronization: Use synchronized events to facilitate cross function trade-offs.
The Synchronization Queueing Principle: To reduce queues, synchronize the batch size and timing of adjacent processes. If we synchronize both the batch size and the timing of adjacent processes, we can make capacity available at the moment the demand arrives. This leads to a dramatic reduction in queues.
When we synchronize arrivals to capacity, we are no longer dealing with random processes. This enables us to reduce the queue.
The Harmonic Principle: Make nested cadences harmonic multiples.
The SJF Scheduling Principle: When delay costs are homogeneous, do the shortest job first. When all jobs have the same delay cost, the preferred scheduling strategy is to do the shortest job first (SJF). If we did the longest job first, it would delay many short jobs. This is often called the “convoy effect,” since it resembles the way one slow car on a narrow road can delay all the cars behind it.
For example, many shoppers at a self checkout, every customer matters the same, but it's more beneficial to do the ones with small first to prevent work building up
The HDCF Scheduling Principle: When job durations are homogeneous, do the high cost-of-delay job first. When all job durations are the same but delay costs differ, it is best to do the high delay cost first (HDCF). We delay the jobs with a low cost of delay so that we can service those with a high cost of delay.
The WSJF Scheduling Principle: When job durations and delay costs are not homogeneous, use WSJF. When both task durations and delay costs are different, we have both the most complex situation and the most common one. In such cases, the best strategy is to do the weighted shortest job first (WSJF). In this case, we set priority based on a job’s duration and its cost of delay. We base priority on delay cost divided by task duration. This is a useful scheduling metric because it uses data from a single job to determine the job’s priority. It is critical to remember that we block a resource whenever we service a job. The benefit of giving immediate service to any job is its cost-of-delay savings, and the cost is the amount of time we block the resources. Both cost and benefit must enter into an economically correct sequencing.
The Local Priority Principle: Priorities are inherently local.
The Round-Robin Principle: When task duration is unknown, time-share capacity. Instead of giving all of the capacity of a processor to a single job until that job is complete, we time-share the processor between multiple jobs. Each job is given a fixed time slice, known as a quantum, on the processor. At the end of this quantum of time, the job is placed back in queue and the next waiting job is serviced. This clever approach ensures that short jobs will always be completed faster than long jobs, even when we have no prior knowledge of the length of the jobs.
The Preemption Principle: Only preempt when switching costs are low.
The Principle of Work Matching: Use sequence to match jobs to appropriate resources.
The Principle of Tailored Routing: Select and tailor the sequence of subprocesses to the task at hand. As a general rule, any inexpensive step that eliminates a lot of risk should occur early. When the greatest risk lies in different places on different programs, then the correct task sequence will differ.Instead of viewing product development as a linear sequence of steps, it will be viewed as a network.
The Principle of Flexible Routing: Route work based on the current most economic route. 
The Principle of Alternate Routes: Develop and maintain alternate routes around points of congestion.
The Principle of Flexible Resources: Use flexible resources to absorb variation.
The Principle of Late Binding: The later we bind demand to resources, the smoother the flow.
The Principle of Local Transparency: Make tasks and resources reciprocally visible at adjacent processes.
The Principle of Preplanned Flexibility: For fast responses, preplan and invest in flexibility. Flexibility is not simply a frame of mind that enables us to react to emerging circumstances. Flexibility is the result of advance choices and planning.
The Principle of Resource Centralization: Correctly managed, centralized resources can reduce queues.
The Principle of Flow Conditioning: Reduce variability before a bottleneck. Optimizing the economics of a process is very different than maximizing its throughput. The economics of a bottleneck process are usually dominated by the size of its queue. However, the size of this queue is affected by more than the operating rate of the bottleneck. This means that we can affect the size of the queue without changing throughput. We can reduce the size and cost of a queue by reducing the variability of the process immediately upstream of the bottleneck. The term we use for reducing the variability in the upstream process is flow conditioning.

12. Centralized Control

We create project management offices. We create centralized information systems. We centralize buffers to take advantage of the efficiency gains of this approach. Our focus on centralization arises because we value efficiency more than response time. We shall see that this is a mistake in Chapter 8, when we examine the role of fast feedback.

Product developers often avoid decentralized control because they are afraid decentralization will lead to chaos. I hope to offer a different view of decentralization. One of the most interesting examples of decentralizing control without losing alignment is the way the military deals with the uncertainty of warfare.

13. Not Using Fast Feedback

fast feedback can lower the expected loss on the left side of the payoff-function by truncating unproductive paths more quickly.

The Principle of Maximum Economic Influence: Focus control on project and process parameters with the highest economic influence.
The Principle of Efficient Control: Control parameters that are both influential and efficient.
The Principle of Leading Indicators: Select control variables that predict future system behavior.
The Principle of Balanced Set Points: Set tripwires at points of equal economic impact.
The Moving Target Principle: Know when to pursue a dynamic goal.
The Exploitation Principle: Exploit unplanned economic opportunities.
The Queue Reduction Principle of Feedback: Fast feedback enables smaller queues.One of the more subtle effects of fast feedback is its ability to shrink queues. Fast feedback loops enable a process to operate with less WIP.
The Fast-Learning Principle: Use fast feedback to make learning faster and more efficient. It is common that we must invest in creating a superior development environment in order to extract the smaller signals that come with fast feedback.
The Principle of Useless Measurement: What gets measured may not get done.
The First Agility Principle: We don’t need long planning horizons when we have a short turning radius. One way to make a control system more effective is to reduce the work it must do. We can do this by making our system more agile.
The Batch Size Principle of Feedback: Small batches yield fast feedback. Product development processes cannot innovate without taking risks. Fast feedback truncates unsuccessful paths quickly, and thereby reduces the cost of failure associated with risk-taking. Thus, as mentioned earlier, fast feedback is an attractive way to favorably alter the asymmetry of our economic payoff-function.
The Signal to Noise Principle: To detect a smaller signal, reduce the noise.
The Second Decision Rule Principle: Control the economic logic behind a decision, not the entire decision. We can make control systems both faster and more efficient by controlling decisions without participating in them. We can do this by controlling the underlying economic logic behind the decision. This controls outcomes without delaying decisions.
The Locality Principle of Feedback: Whenever possible, make feedback local.
The Relief Valve Principle: Have a clear, predetermined relief valve.
 The Principle of Multiple Control Loops: Embed fast control loops inside slow loops.
The Principle of Controlled Excursions: Keep deviations within the control range.
The Feedforward Principle: Provide advance notice of heavy arrival rates to minimize queues.
The Principle of Colocation: Colocation improves almost all aspects of communication.
The Empowerment Principle of Feedback: Fast feedback gives a sense of control.
The Hurry-Up-and-Wait Principle: Large queues make it hard to create urgency. Slow feedback produces the opposite effect, and large queues create slow feedback. When queues are large, it is very hard to create urgency. There is simply too long a time lag between when we arrive in the queue and when our job is serviced. With a long time lag, we only see a weak relationship between our completion of work and the start of the next activity.
The Amplification Principle: The human element tends to amplify large excursions.It is best to keep our system operating within a controlled range.
The Principle of Overlapping Measurement: To align behaviors, reward people for the work of others.
The Attention Principle: Time counts more than money.
──────────────────────
Q: If we define risk as quantifiable and uncertainty as unquantifiable… does this change this idea materially 
This is a genuinely sharp distinction to draw, and yes — it does change the idea materially, though perhaps not in the direction you might initially expect. Let me work through it carefully.

The Knight/Keynes Distinction
Frank Knight (and later Keynes) drew this line: risk is when you don't know the outcome but you know the probability distribution. Uncertainty is when you don't even know the distribution. Most of what Reinertsen calls "risk" in product development is actually Knightian uncertainty — you don't know what you don't know. You can't assign a probability to "we'll discover the technology doesn't work" because you don't yet know what "doesn't work" even means.

How This Changes the Principle
Reinertsen's heuristic — do inexpensive steps that eliminate a lot of risk early — implicitly assumes you can rank and compare risks ahead of time. That's a reasonable assumption for quantifiable risk. But under genuine uncertainty, you face a harder problem:
You don't know which early steps will reveal the most dangerous unknowns, because you don't know what the unknowns are.
This means the principle needs to be reframed. Instead of:
"Eliminate the highest-risk items first"
It becomes:
"Design early steps that are maximally revelatory — that expose the shape of the uncertainty landscape itself"
This is subtly but profoundly different. You're not eliminating known risks in priority order — you're running probes to discover what the risks even are. The goal of early work shifts from risk reduction to uncertainty mapping.

Practical Implications
1. The sequencing logic changes. With quantifiable risk, you can pre-sequence your work rationally before you start. With uncertainty, your sequence must be adaptive — each early step informs what the next step should be. The "network" framing Reinertsen gestures toward becomes not just descriptive but necessary. You literally cannot pre-plan the network; you discover it.
2. The cost calculus changes. Reinertsen says do "inexpensive steps that eliminate a lot of risk." But under uncertainty, you often don't know in advance whether a step will be high-yield or not. A cheap experiment might reveal nothing. A slightly more expensive one might collapse your entire architecture assumption. The expected value calculation is undefined. This pushes you toward option-like thinking — you want steps that are cheap to abandon and cheap to learn from, not necessarily cheap in absolute terms.
3. The "inexpensive" criterion becomes more important, not less. Paradoxically, under uncertainty the cost constraint becomes more critical. Since you can't rank-order by expected risk reduction, your best strategy is often to run many cheap probes in parallel — essentially buying information about the uncertainty landscape. This connects directly to Reinertsen's point about small batch sizes and fast feedback, but the reason shifts: it's not just about reducing delay cost, it's about sampling the uncertainty space efficiently.
4. The "network not sequence" insight deepens. Under quantifiable risk, the network structure is still somewhat pre-determinable — you know roughly which nodes matter. Under genuine uncertainty, the network is emergent. You don't know which paths exist until you start walking. This is actually closer to how real R&D works — the dependency structure of tasks is itself unknown at the outset.

A Concrete Example
Imagine you're building a new hardware product. You know (quantifiable risk) that supplier lead times vary by ±20%. You don't know (uncertainty) whether your core thermal management approach will work at scale.
Reinertsen's principle, taken literally, might have you sequence work by known risk probability. But the right move is to probe the thermal uncertainty first — even if you can't assign it a probability — because if it fails, it invalidates huge portions of the downstream work. The uncertainty, not the risk, should dominate your early sequencing.

The Deeper Implication
If you take the risk/uncertainty distinction seriously, it suggests that Reinertsen's framework — powerful as it is — is most applicable in domains where risks are somewhat enumerable. In genuinely novel product development (true R&D, breakthrough innovation), the uncertainty is so deep that even the economic framework he advocates becomes hard to apply, because you can't quantify cost of delay when you don't know what you're building or whether it's possible.
This is probably why agile and lean startup approaches emerged as complements to flow-based thinking — they're essentially heuristics for operating under deep uncertainty, where the goal is to convert uncertainty into risk as fast as possible through cheap experiments, before you commit to the more optimizable flow-management that Reinertsen describes.
In short: The principle still holds directionally, but the mechanism shifts from prioritized risk elimination to uncertainty discovery, and the sequencing logic becomes adaptive rather than pre-planned. The network metaphor becomes not just a better model but an epistemological necessity.
──────────────────────
Q: What are examples of low/high transaction costs that illustrate the economics of batch sizes

Transaction Costs and Batch Size Economics
Transaction cost is the fixed overhead you pay every time you process a batch, regardless of how big that batch is. This is the key insight: because transaction costs are fixed per batch (not per item), they create economic pressure toward larger batches. Understanding this helps you see both why large batches feel efficient and why reducing transaction costs is the lever that unlocks small batch economics.

The Core Logic
Think of it as a simple equation:
Total Cost = (Transaction Cost × Number of Batches) + (Holding/Delay Cost × Batch Size)
These two forces pull in opposite directions, creating the U-curve Reinertsen references. The optimum batch size sits at the bottom of that U. Critically, if you reduce transaction cost, you shift the entire curve leftward — the new optimum is a smaller batch size, and total costs fall.

High Transaction Cost Examples (Pressure Toward Large Batches)
Software Testing (Manual)
Setting up a test environment takes 24 hours
Running regression suites requires coordinating 5 people
Writing test scripts for each release is labor-intensive
Result: You batch up weeks or months of code changes before testing, because the setup cost is so high it would be wasteful to trigger it for small changes
The hidden cost: bugs compound, debug complexity grows as 2ⁿ with n simultaneous changes
Physical Hardware Fabrication
Setting up a CNC machine or PCB fabrication run has significant fixed costs
Minimum order quantities at suppliers force large batches
Tooling changes between runs are expensive
Result: Engineers batch all their design changes into infrequent prototype runs
The hidden cost: you discover fundamental design flaws late, after downstream work has already assumed the prototype would work
Regulatory/Compliance Reviews
Scheduling a review board meeting requires weeks of advance notice
Preparing documentation packages is a fixed overhead per submission
Legal review has high per-engagement costs
Result: Teams batch up every change they can before submitting, to amortize the overhead
The hidden cost: risk accumulates invisibly; small early issues become expensive late discoveries
Cross-Timezone Handoffs
Coordinating a working session between teams in different time zones requires scheduling overhead
Context-switching costs for both parties are high
Result: Teams batch up questions and decisions to handle in a single call rather than communicating continuously
The hidden cost: blockers sit unresolved for 24+ hours; misunderstandings compound
Requirements Sign-Off Processes
Formal sign-off requires executive availability, document preparation, meeting scheduling
Each approval cycle has significant overhead
Result: Teams bundle every requirement they can think of into one massive spec before seeking approval
The hidden cost: this is exactly the "100% requirements upfront" anti-pattern Reinertsen describes — design begins before requirements are stable, feedback loops break
Deployment to Production (Traditional)
Change advisory board meetings happen quarterly
Deployment windows require coordinated downtime
Rollback procedures are manual and risky
Result: Teams accumulate months of changes into big-bang releases
The hidden cost: when something breaks, you don't know which of 200 changes caused it
Low Transaction Cost Examples (Enable Small Batches)
Automated Testing (CI/CD)
A test suite runs automatically on every commit in minutes
No human coordination required
No environment setup — it's always ready
Result: Developers can push small, frequent changes and get immediate feedback
The economic unlock: you can now process batches of 1 or 2 changes instead of 200
Debug complexity drops from 2²⁰⁰ to 2²
Digital Design Reviews
Asynchronous code review tools (GitHub PRs) allow review without scheduling a meeting
Comments are threaded and persistent
Reviewers can engage on their own schedule
Result: Small, frequent reviews replace large infrequent ones
The economic unlock: problems caught in hours rather than weeks
Cadenced Meetings (Reinertsen's Example)
Weekly standing meetings have near-zero scheduling overhead
No meeting announcement, no calendar negotiation
Everyone knows when it happens
Result: You can afford to meet weekly instead of monthly, enabling smaller batch sizes between coordination points
The economic unlock: variance doesn't accumulate across long inter-meeting gaps
Cloud Infrastructure / Infrastructure as Code
Spinning up a new environment takes minutes, not weeks of procurement
No physical hardware to configure
Result: You can run many small experiments in parallel rather than one large one
The economic unlock: small batch experimentation becomes economically rational
Continuous Deployment Pipelines
Automated deployment with feature flags and instant rollback
No change advisory board, no deployment window
Result: Teams deploy dozens of times per day in small increments
The economic unlock: each deployment is so small that failures are immediately identifiable and reversible
Colocation / Slack / Instant Communication
The transaction cost of asking a question drops to near zero
No need to batch up questions for a weekly meeting
Result: Decisions get made in minutes rather than days
The economic unlock: small decisions can be made continuously rather than accumulated into large decision batches
The Asymmetry That Makes This Interesting
Here's what's non-obvious: the holding cost (delay cost) of large batches is often invisible, while the transaction cost is highly visible.
When a team argues for large batches, they're pointing at real, visible transaction costs. The delay costs — the bugs that compound, the market feedback that arrives late, the rework from misunderstood requirements — are diffuse, delayed, and hard to attribute. This is why Reinertsen's emphasis on quantifying cost of delay is so foundational. Without it, the economic case for investing in transaction cost reduction is hard to make.
The correct framing for any transaction cost reduction investment is:
"If we spend $X to automate this process and reduce transaction cost from $Y to $Z per batch, we can reduce our optimal batch size from N to M. At what cost of delay does this investment pay off?"
This is the conversation that almost never happens — but it's the one that unlocks the compounding benefits of small batches.

The Meta-Point
Transaction cost reduction is often a one-time capital investment that permanently shifts the economics of every future batch decision. Automating your test suite costs money once; it pays dividends on every subsequent development cycle. This is why Reinertsen says it's often better to attack transaction costs before attacking bottlenecks — you're changing the underlying economic structure of the system, not just adding capacity at one point.
──────────────────────
Q: Why does reducing batch size reduce cycle time?

Why Reducing Batch Size Reduces Cycle Time
This is one of the most counterintuitive and important insights in the entire field of flow management. Let me build it from first principles.

The Core Intuition: Little's Law
Start with Little's Law, which Reinertsen mentions:
Wait Time = Queue Size / Processing Rate
This is a mathematical identity, not a heuristic. It holds for any stable queuing system. What it tells you is that cycle time is directly proportional to the amount of work in the system. If you cut WIP in half, you cut cycle time in half — without touching processing rate at all.
Batch size reduction is one of the most direct levers for reducing WIP. Here's why:

The Bathtub Mental Model
Imagine water flowing through a bathtub. The faucet is your arrival rate (work coming in). The drain is your processing rate (capacity). The water level is your WIP.
Batch size doesn't change the drain speed. It changes how much water enters at once and how long it sits before it starts draining.
When you submit a large batch — say, 100 items — the first item in that batch has to wait for the other 99 to be processed before it moves forward. It entered the system when the batch arrived, but it doesn't exit until the whole batch clears. Its cycle time includes all that waiting.
When you split that into 10 batches of 10, each item enters a much shorter queue. The first item in the first sub-batch moves forward almost immediately. Its cycle time collapses.

The Specific Mechanism: Items Waiting for Their Own Batch-Mates
This is the subtle piece most people miss. In a large batch system, an item's cycle time includes:
Time waiting for the batch to be assembled (before processing even begins)
Time in queue behind other batches
Time being processed
Time waiting for the rest of its batch to finish (before it's released downstream)
Items 1 and 4 are pure waste generated by the batch structure itself. They have nothing to do with capacity utilization. A single item in a batch of 100 might be "done" in an hour but sit for 99 more hours waiting for its batch-mates before it moves forward.
This is why the principle says cycle time can drop by an order of magnitude or more without changing capacity utilization — you're eliminating waiting time that was never about capacity in the first place.

A Concrete Example
Imagine three process steps, each taking 1 minute per item.
Large batch (100 items):
Step 1 processes all 100 items: 100 minutes
Batch transfers to Step 2, which processes all 100 items: 100 minutes
Batch transfers to Step 3: 100 minutes
Total cycle time for any single item: 300 minutes
Small batch (1 item at a time):
Item 1 goes through Step 1: 1 minute
Item 1 goes through Step 2: 1 minute
Item 1 goes through Step 3: 1 minute
Total cycle time for Item 1: 3 minutes
Same capacity. Same processing rate. 100x difference in cycle time. The remaining 99 items are flowing through the pipeline while Item 1 has already finished. This is the "order of magnitude or more" Reinertsen is referring to — it's not hyperbole.

The Queue Amplification Effect
There's a second, compounding mechanism. Reinertsen notes that queues increase variability, and variability increases queues exponentially as utilization rises.
Large batches create large, lumpy arrival patterns at downstream processes. When 100 items arrive at once at Step 2, that step suddenly faces a massive queue spike — even if its average load is perfectly manageable. This variability in arrivals drives up average queue size, which drives up average cycle time, beyond what the batch-waiting effect alone would predict.
Small batches smooth the arrival pattern. Downstream processes see a steady trickle rather than a flood. This dramatically reduces queue variance, which reduces average queue size, which reduces cycle time — again, without touching capacity.

Why Capacity Utilization Doesn't Change
This is the part that surprises people most. Your total throughput — items per unit time — can remain exactly the same. You're not doing less work or adding resources. You're just reorganizing when work travels together.
Think of it like a highway. The same number of cars can travel the same distance in the same time whether they travel in one massive convoy or spread out individually. But the lead car in the convoy arrives much later than it would if it had traveled alone. The convoy structure added waiting time for the lead car without adding any cars to the road.
Capacity utilization (cars per hour on the road) is identical. Cycle time for individual items is radically different.

The Feedback Acceleration Effect
There's a third mechanism that compounds everything: faster feedback.
When batches are small, you discover problems sooner. Reinertsen notes that debug complexity grows as 2ⁿ when you change n things simultaneously. A batch of 1 change has debug complexity of 2. A batch of 100 changes has debug complexity of 2¹⁰⁰ — effectively infinite.
Large batches don't just delay feedback — they make the feedback, when it finally arrives, nearly useless for diagnosing root causes. This generates rework, which re-enters the queue, which increases WIP, which increases cycle time further. The cycle time penalty of large batches compounds through this rework loop in ways that don't show up in simple capacity calculations.

The Practical Summary
Reducing batch size reduces cycle time through four distinct mechanisms, all operating simultaneously:
| Mechanism | How It Works | |---|---| | Little's Law | Less WIP in system → shorter wait time, mathematically | | Intra-batch waiting | Items stop waiting for batch-mates to finish before moving forward | | Arrival smoothing | Smaller, steadier arrivals reduce queue variance at downstream steps | | Feedback acceleration | Faster discovery of problems reduces rework entering the queue |
None of these require adding capacity. All of them are unlocked purely by changing the size of the chunks in which work travels through the system. This is why batch size reduction is Reinertsen's "weapon of choice" — it's the highest-leverage, lowest-cost intervention available, and its benefits compound across the entire system simultaneously.

Starred

Dunk (exclude from study)

The Principles of Product Development Flow

Review Questions

Todos

Sensemaker