A bottleneck is the constraint that governs a system’s throughput. It is the point where demand exceeds capacity and work begins to accumulate. As described by Eliyahu M. Goldratt in the Theory of Constraints and by David J. Anderson in the Kanban Method, the constraint is the step that limits how much value the entire system can produce. When work arrives faster than it can be processed, queues form in front of it and downstream activities starve. Improving flow, therefore, requires identifying and deliberately managing the system’s constraint.
Visualizing Flow
Constraints cannot be managed if the system is invisible.
In most product development environments, work moves through multiple states, teams, and handoffs. Without a visual representation of that flow, delays and queues remain hidden. Managers sense that delivery is slow, but they cannot see where capacity is being exceeded or where work is accumulating.
A visual model of workflow makes queues explicit. When work begins to accumulate in front of a particular step, that step is likely operating as a constraint. When downstream activities are idle, it is further evidence that throughput is being governed upstream.
Unless workflow is made visible and kept current, constraints remain obscured and are often misdiagnosed.
Using Kanban to Visualize Work
A Kanban system provides a concrete way to make workflow visible. By mapping each work state and limiting work in process, queues become explicit.
When work begins to accumulate in front of a specific state, that state is likely operating as the constraint. When downstream states are idle, it is further confirmation that throughput is governed upstream.
A Kanban system does not eliminate constraints, but it makes them observable. Without that visibility, constraints are often misidentified and local optimizations are mistaken for improvement.
Using Cycle Time To Discover Bottlenecks
Visualization reveals where work accumulates. Measurement confirms whether that accumulation represents the governing constraint.
Begin by measuring total cycle time across the relevant portion of the system. Then measure cycle time by state. If a particular state consistently consumes a disproportionate share of total cycle time, it is likely functioning as the constraint.
Measure how long work remains in backlog states as well. Extended waiting before active processing often signals intake exceeding capacity.
State-level cycle time distinguishes between large individual items and structural constraints. If only a few items linger, the issue may be item size. If most items experience delay in the same state, the system is constrained there.
Constraint identification requires both observation and measurement.
Diagrams of Cumulative Flow (CFD)
Other visualizations, such as cumulative flow diagrams, can show inventory growth over time. However, they do not isolate where cycle time is being consumed. A widening band in a CFD indicates that arrivals have outpaced departures in that state, but it does not, by itself, prove that the state governs system throughput. To identify the constraint, state-level cycle time and direct observation of queue accumulation are typically more reliable indicators.
Look for Ticketing Systems
When a group requires formal intake before work can begin, it is often operating as a constraint.
Ticketing systems, request portals, intake forms, and approval workflows exist because demand exceeds the group’s capacity. The formal process is a mechanism for controlling access. While such systems can create order, they also make the constraint visible: work must queue before it can be processed.
These constraints are frequently policy-driven rather than physical. In product development, they often appear as required documentation, templated submissions, or gated approvals that must be completed before work advances. Each gate introduces a queue. Each queue increases delay.
Cross-functional teams are designed to reduce these policy constraints by collapsing handoffs and eliminating formal intake boundaries. When work must pass through multiple contractual interactions between siloed groups, throughput is governed by those boundaries.
If you are searching for a constraint in a product development system, start by identifying where work must request permission to proceed.
Managing the Constraint
There are three classic approaches to managing a constraint:
Exploit
Subordinate
Elevate
These come from the Theory of Constraints and apply directly to product development systems, although they must be interpreted carefully in knowledge work.
Exploit.
Make the most of the constraint’s existing capacity without adding resources. In manufacturing, this often means ensuring the machine never sits idle. In product development, exploitation looks different. People are not machines. Driving a knowledge worker to 100% utilization reduces availability to handle variability and increases delay.
Exploitation in knowledge work means protecting the constraint’s focus. Ensure it works only on the highest-value items. Remove unnecessary interruptions. Route work around it when the constraint’s expertise is not truly required. If one expert becomes the bottleneck, work must qualify for that expert’s attention rather than defaulting to it.
Subordinate.
Align the rest of the system to the constraint’s capacity. Do not release more work into the system than the constraint can process. This requires discipline. It often means accepting that not all ideas will be built.
Subordination is where WIP limits become critical. When intake exceeds capacity, queues grow and cycle time expands. Throughput does not increase. The organization must decide to build fewer, more valuable items rather than many partially completed ones.
Elevate.
Increase the constraint’s capacity. This may involve automation, better tooling, cross-training, or adding people. However, elevation should follow exploitation and subordination. Adding capacity without first stabilizing the system often increases complexity without increasing throughput.
In product development, elevation may also mean redesigning work so that the constraint is required for only the portions that truly depend on it. Structural redesign is often more effective than headcount expansion.
Common Mistakes
Several common management responses make constraints worse rather than better.
Maximizing utilization.
When delivery slows, the instinct is to increase busyness. Managers assume that if everyone operates closer to full capacity, throughput will increase. In knowledge work, the opposite typically occurs. High utilization reduces availability to manage variability, increases queue length, and expands cycle time. Communication declines, defects increase, and coordination becomes more difficult. Throughput does not improve because the constraint has not changed.
Starting more work.
Under pressure, teams often respond by beginning additional work in parallel. This increases work in process without increasing capacity. Queues grow, cycle times lengthen, and variability compounds. Throughput remains governed by the constraint, regardless of how many items are in flight.
Adding capacity prematurely.
Hiring or reassigning people without first stabilizing the constraint rarely produces the expected improvement. If the constraint is policy-driven, structural, or knowledge-based, adding people increases coordination overhead without relieving the true limitation. Elevation is effective only after exploitation and subordination have disciplined the system.
A constraint must first be made visible before it can be managed. Visualize workflow. Observe where queues accumulate. Measure cycle time by state and across the system. Identify the point that governs throughput.
Then act deliberately: exploit the constraint, subordinate the system to it, and elevate capacity only when necessary.
In manufacturing, constraints are often fixed and visible. In product development, as described by Reinertsen, constraints are frequently emergent — created by structure, policy, specialization, or variability. They move. They reappear. Managing flow, therefore, is not a one-time intervention but an ongoing discipline of identifying and treating the system’s constraint.
Goldratt, E. M., & Cox, J. (2004). The goal: A process of ongoing improvement (3rd rev. ed.). North River Press.
Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Blue Hole Press.
Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Celeritas Publishing.