"Move fast and break things" is a phrase that aged badly — not because speed is wrong, but because the framing confused shipping quickly with learning quickly. These are related but distinct capabilities, and optimising for one at the expense of the other produces teams that are either fast and reckless or thoughtful and slow.
The teams doing this well have noticed something: iteration quality is not the opposite of iteration speed. It is what makes iteration speed sustainable over a long time horizon.
What iteration quality means
Iteration quality is not about polish. A high-quality iteration can be a rough experiment — a paper prototype, a coded spike, a survey of twenty users. The quality is in the learning, not the output.
A high-quality iteration:
— Asks a specific question before it begins
— Has a clear success criterion
— Is small enough that its result is interpretable
— Generates a decision, not just observations
A low-quality iteration is one where the team ships something, watches metrics, and argues about what the numbers mean. The problem was not in the execution — it was in the design of the experiment.
The bottleneck in most product development is not the speed of shipping. It is the quality of the question the team is trying to answer.
The tech debt trap
Fast iteration often accumulates technical debt. Technical debt slows future iterations. If the team is fast in the short term but slower in each subsequent cycle, the compounding effect makes them less productive over twelve months than a team that moved more deliberately.
The solution is not to avoid debt — it is to be intentional about which debt you take on and when you pay it down. Teams that never refactor are accumulating compound interest without noticing it.
The measurement problem
Iteration speed is easy to measure: time from idea to ship. Iteration quality is harder. Proxy metrics include: what percentage of iterations produced a clear decision? How often did the team change direction as a result of what they learned? How many iterations were abandoned because the question turned out to be unanswerable?
The teams with the highest iteration quality tend to spend more time before the iteration begins — writing the question clearly, defining what success looks like, scoping the experiment to the minimum viable form. This investment in pre-work reduces the total time to a decision.
In practice
Before each iteration, write down: what question are we answering? What result would tell us to proceed? What would tell us to stop? If these questions cannot be answered in a sentence each, the iteration is probably too large or too vague.
After each iteration, have the team answer: what did we learn? What decision did we make as a result? If there is no clear decision, the learning has not been converted into value — and the next iteration will be slower, not faster.
Speed is a lagging indicator. Teams that invest in iteration quality become fast. Teams that optimise for speed alone become slower over time.