Open any sprint retrospective notes from a functioning product team and look for the themes. "We need faster CI." "Design review is a bottleneck." "We need more product bandwidth for specs." "QA is always backed up." "We don't have enough senior engineers."

These are all real problems. Most of them are also symptoms of the wrong problem being targeted.

Every shipping system has one primary constraint. Everything else is secondary. And almost every team spends most of its energy on the secondary problems.

Finding the Real Constraint

The hard part: the constraint often hides behind the visible pain. It might not even feel like the main problem — it might feel like a background condition that's always been there.

Common true constraints in shipping systems:

Product decision latency. In many organizations, the real constraint is not execution — it's product decisions that haven't been made. Engineering is ready to build, design is ready to finalize, but the call on direction hasn't been made. The system backs up because nothing can move without that decision. Improving engineering speed or CI time doesn't touch this at all.

Design review. Design is a small team, and they're reviewing across multiple tracks simultaneously. Everything that touches design waits — not because design is slow, but because design is a shared resource with more demand than capacity. The fix isn't "faster design" — it's either reducing the demand on design review or increasing design's capacity to handle it.

QA or testing. The test phase is always backed up. Engineering ships faster than QA can review. The queue in front of QA is long. Shipping velocity is determined by QA throughput, not engineering velocity.

A specific engineer. This is more common than teams admit. One person is the implicit owner of releases, or of a critical subsystem, or of the final sign-off before deployment. They are the constraint whether or not they appear in any org chart. Improving everyone's productivity except theirs doesn't change the throughput of the system.

CI or environment availability. Shared test environments, slow CI pipelines, deployment coordination — mechanical constraints that add queue time proportional to the number of people waiting. Often fixable with investment but often treated as background noise rather than the primary constraint.

How to Find It

The diagnostic question: if you freed up one bottleneck in the system, which one would make the most difference to how fast features actually ship?

The answer is usually identifiable with one method: trace the critical path for several recent features. The critical path is the sequence of steps that the work actually had to go through, in order, from decision to launch. Identify which step took the longest and had the most work backed up in front of it.

That step is your constraint: the actual throughput limiter.

Then ask: is there a way to increase the throughput of that step without making large organizational changes? Often there is: adding capacity, removing unnecessary work from that step, co-locating decisions that feed into it, reducing the demand on that resource through better upstream preparation.