Most execution problems are one problem
A business improves its design process, and delivery does not speed up. It hires two more engineers, and delivery does not speed up. It adopts a new project tool, and delivery does not speed up.
The reason is usually that none of those interventions touched the thing that was actually limiting output. Effort went into parts of the system with spare capacity, which produces work in progress rather than throughput.
This is the single most transferable idea in execution, and it applies identically to a factory, a design studio, a sales funnel, and a delivery team: a system's output is set by its binding constraint, and improvements anywhere else are close to worthless until that constraint moves.
Nearly every framework in this article is, in some form, a method for finding the constraint or for stopping the organisation from creating new ones.
This article covers the Build stage only: turning a strategic choice into the systems, structures, and assets that deliver it. It is the second of four stage guides. The first covered Define; later pieces cover Drive and Scale.
The same evidence test
This series grades frameworks in three tiers, and the grades carry across clusters.
Empirically grounded. Independent research, replicated, published where it can be challenged.
Documented practitioner method. Field-developed, internally consistent, refined across many engagements, with evidence largely produced by those who advocate it. Most of the useful toolkit sits here, which is acceptable provided nobody pretends otherwise.
Popular but thinly evidenced. Widely taught, intuitively appealing, resting on selected cases. Usable as vocabulary, unsafe as justification.
Build has a better evidence base than Define. Two of the frameworks below are supported by substantial independent research, which is unusual in this field.
Six frameworks that hold at Build
1. Theory of Constraints
Empirically grounded, with a stated caveat.
Goldratt's five focusing steps: identify the constraint, exploit it, subordinate everything else to it, elevate it, then repeat — because once it moves, the constraint is somewhere else.
Mabin and Balderstone's meta-analysis, published in the International Journal of Operations and Production Management, examined over 80 documented applications. Average reductions of roughly 69% in lead times and 66% in cycle times, inventory down around 49%, and financial performance improved by more than 60%.
The caveat matters and the authors state it themselves: despite extensive searching, they found no reported failures. A body of literature containing only successes has a publication bias problem. The magnitudes should be read as what good implementations achieved, not as expected outcomes.
Where it applies: anywhere throughput matters more than utilisation, which is almost everywhere.
Where it breaks: teams identify a constraint and then immediately try to elevate it — buy more capacity — before exploiting what already exists. Exploitation is free. Elevation costs money.
2. Delivery performance measurement (DORA)
Empirically grounded.
Four metrics: deployment frequency and lead time for changes, which measure throughput; change failure rate and time to restore service, which measure stability.
The research base is genuinely substantial — annual State of DevOps surveys since 2014, synthesised in Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim, drawing on tens of thousands of responses. The headline finding: teams performing well on these measures are around twice as likely to meet or exceed organisational goals including profitability, market share, and productivity.
The important structural finding is that speed and stability move together rather than trading off. Teams that ship more frequently also break things less. That contradicts the intuition most leadership teams start with.
Where it applies: any business shipping software, and by analogy any repeatable delivery process.
Where it breaks: the metrics become targets. Mandating deployment frequency produces inflated deployment counts, not better delivery.
3. Working Backwards and the PR-FAQ
Documented practitioner method. Amazon.
Before building, write the press release announcing the finished thing, plus the FAQ answering the hard questions. If the release is not compelling, the idea is not ready.
The mechanism is that it forces the outcome and the customer benefit to be stated in plain language before any resource commits. Vague ideas cannot survive the format.
Where it applies: any significant build decision, particularly where several stakeholders hold different pictures of what is being made.
Where it breaks: it becomes a document to be completed rather than a test to be passed. If no PR-FAQ has ever resulted in an idea being dropped, the exercise is theatre.
4. Opportunity Solution Tree
Documented practitioner method. Teresa Torres.
A visual structure connecting a desired outcome to the opportunities that could deliver it, then to candidate solutions, then to the experiments that test them.
Its value is preventing the most common product failure: a solution arriving with no traceable line back to an outcome. Every branch has to connect upward or it does not belong.
Where it applies: product and experience decisions where the backlog has grown faster than the reasoning behind it.
Where it breaks: the tree is drawn once and never revised. It is a working artefact, not a diagram.
5. Team Topologies
Documented practitioner method, with supporting evidence from adjacent research.
Four team types — stream-aligned, enabling, complicated-subsystem, and platform — and three interaction modes. The underlying claim is that communication structures determine system architecture, so team design is a design decision rather than an HR one.
Where it applies: organisations where delivery has slowed as headcount grew, or where every change requires coordination across several teams.
Where it breaks: applied as a reorganisation template rather than as a diagnosis of where handoffs are creating delay.
6. Service Blueprinting
Documented practitioner method.
An extension of journey mapping that adds what happens behind the scenes: frontstage actions, backstage actions, and the support processes underneath, all mapped against the customer's experience over time.
Underused, and particularly relevant to businesses where the product includes fulfilment, support, or physical delivery. It is the tool that makes operational failure visible as customer experience.
Where it applies: commerce, services, and any business where the experience depends on operations the customer never sees.
Where it breaks: it maps the intended service rather than the actual one. Blueprint what happens, not what is supposed to happen.
Two frameworks that need handling
Design Thinking and the Double Diamond
Popular, thinly evidenced.
The vocabulary is useful and widely shared: diverge then converge, twice. As a shared language for structuring creative work it earns its place.
As a claim about outcomes it is weak. The evidence is largely case-based and selected, and the framework's own advocates have struggled to demonstrate that following the process produces better results than not following it. Use it to organise a workshop. Do not present it as the reason a decision is sound.
Weighted scoring frameworks
Documented practitioner method, systematically misread.
RICE, ICE, and weighted scorecards convert judgements into numbers, then rank the numbers. The arithmetic is real. The inputs are estimates, and the output inherits every bias in them while presenting as objective.
The legitimate use is forcing explicit comparison of factors a team would otherwise weigh implicitly. The illegitimate use is treating the ranking as an answer. If reordering the list by moving one estimate by 20% changes the top item, the framework has not decided anything — it has laundered a judgement.
These are one sequence, not a menu
Find the constraint first. Until the binding limit on throughput is identified, every other improvement is speculative. This ordering is not a preference; it is the reason the other five have anything to work on.
Define the outcome before the solution. Working Backwards and the opportunity tree both exist to stop building before the outcome is stated.
Design the team structure around the flow. Communication structure becomes system structure whether or not anyone intends it.
Blueprint the experience including what is invisible. Operational failures surface as customer experience failures, and only a blueprint shows both at once.
Instrument delivery. Measurement comes last in the sequence and runs permanently. Throughput and stability together, never one alone.
The Build stage closes when the business can produce what the strategy requires, repeatedly, without heroics — and can see where it is slow.
Diagnostic: is the Build stage actually closed?
Seven tests. Two or more failures means the stage is open.
The current binding constraint on delivery can be named, and someone owns moving it.
Every significant build in progress traces to a stated outcome.
Team boundaries match the flow of work rather than function or historical accident.
Both throughput and stability are measured, and neither has been made a target in isolation.
Someone can name a thing that was proposed and dropped during definition.
The service blueprint reflects what actually happens, including failure paths.
Adding a person to the busiest team would be recognised as unlikely to help.
Test seven is the one most organisations fail, and it fails for the same reason the others do — capacity feels like the answer when flow is the problem.
What this stage produces
A system that converts a decision into delivery at a known rate.
That is the honest description. Not a product, not a brand, not a platform — those are outputs. What the Build stage actually produces is the capacity to keep producing, with the limiting factor identified and visible rather than mysterious.
A business that has closed Build knows what it can ship in a quarter and why that number is what it is. That is the input the Drive stage needs, and it is the difference between a growth plan and a wish.
Frequently asked questions
What is the most important execution framework?
Theory of Constraints, on both evidence and transferability. A system's output is limited by one binding constraint, and improvements elsewhere produce work in progress rather than throughput. Almost every other execution framework is a method for finding or avoiding constraints.
Does Theory of Constraints have real evidence behind it?
Yes, with a caveat. A meta-analysis of over 80 applications found average lead time reductions near 69% and inventory reductions near 49%. The authors also noted they found no reported failures, which indicates publication bias. Treat the magnitudes as what good implementations achieved.
Are DORA metrics relevant outside software?
The specific metrics are software-shaped, but the structure transfers: measure throughput and stability together, never one alone. Any repeatable delivery process can be instrumented the same way.
Is Design Thinking worth using?
As shared vocabulary for structuring creative work, yes. As evidence that a decision is sound, no. The supporting research is case-based and selected, and following the process has not been shown to produce better outcomes than not following it.
Should we use RICE or a similar scoring framework?
Use it to force explicit comparison, not to produce answers. If moving one estimate by a modest amount reorders the top of the list, the framework has converted a judgement into a number rather than resolving it.
How many people should a team have before restructuring?
The signal is not headcount. It is whether delivering a typical change requires coordination across multiple teams. When it does, team boundaries are cutting across the flow of work, and that is a structural problem no amount of process will fix.
How long should the Build stage take?
It does not end in the way Define does. Build closes as a phase when the business can deliver what the strategy requires repeatably, then continues as an operating discipline. The constraint moves, and finding the new one is permanent work.
Sources
Goldratt, E., The Goal; Mabin, V.J. and Balderstone, S.J., The Performance of the Theory of Constraints Methodology, International Journal of Operations and Production Management (2003)
Forsgren, N., Humble, J. and Kim, G., Accelerate (2018), and the annual State of DevOps research
Amazon Working Backwards and PR-FAQ practice
Torres, T., Continuous Discovery Habits — Opportunity Solution Tree
Skelton, M. and Pais, M., Team Topologies
Service blueprinting literature, originating with Shostack (1984)
Structure your next phase
Zerologic works with leadership teams to build the operating system a strategy requires — experience architecture, process design, team structure, and the measurement that shows where it is slow.
Talk to us: partners@zerologic.io · zerologic.io
