Iteration has become the default virtue of digital product work.
Move fast. Ship. Learn. Repeat. The loop is so embedded in how we talk about building products that questioning it feels almost heretical. Like arguing against testing or against user research. Who would be against learning?
I’m not against it. I’m against what happens when iteration becomes the substitute for thinking.
There’s a specific pattern I’ve watched repeat itself across product teams, and it goes roughly like this. There’s a hard design problem. Nobody quite knows the answer. Rather than sitting with the uncertainty long enough to develop a considered point of view, the team ships something, calls it an MVP, and waits for the data. The data comes back ambiguous, as data usually does. They iterate. The next version is marginally better. They iterate again. Eighteen months later, the product is a patchwork of incremental decisions made under pressure, held together by the logic of what came before rather than any coherent understanding of what the experience should be.
This is the compounding cost of iteration without direction. Each individual decision is defensible. The accumulated shape of the product is no one’s vision of anything.
Fast iteration works best when you have a stable understanding of what you’re building and who you’re building it for, and you’re refining the execution. It’s a delivery optimisation strategy. It’s not a strategy for figuring out what to build in the first place.
The problem is that the conditions where iteration works best are often confused with the conditions where it’s being applied. When a product is genuinely uncertain, when you’re working at the edge of your understanding of the user or the market, fast iteration can be a way of staying busy while avoiding the harder thinking. You’re generating signal, but if you don’t have a clear enough hypothesis to interpret that signal against, you’re mostly generating noise and calling it learning.
What I’ve found, across a lot of projects, is that the teams who do their best work are willing to be slow before they’re fast. Slow in the early phases. Slow in the research and synthesis, in the framing, in the development of a design direction that’s genuinely grounded in understanding. Slow enough to disagree well, to surface the assumptions underneath the problem, to test the brief rather than just the solution.
That investment at the front end changes the quality of everything that follows. Not because you’ve eliminated uncertainty. You can’t. But because you’ve built a stable enough frame of reference that when you do iterate, you’re iterating toward something rather than just away from the last version.
The phrase I keep coming back to is direction before velocity. Without direction, velocity is just movement.
There’s also something worth saying about the human cost of constant iteration without a clear point of view. For the designers doing the work, it’s exhausting in a specific way. You’re never done. Every shipped thing is immediately provisional. The conversation is always about what’s next rather than whether what you just made is actually any good. The craft standards that most good designers care about get sacrificed to the cadence. You stop asking “is this right?” and start asking “is this good enough to ship?”
Those are genuinely different questions.
I’ve led teams that were iterating constantly and producing mediocre work, and I’ve led teams that took longer on fewer things and produced work they were proud of. The second model is harder to defend in organisations that measure output by velocity. It requires a level of confidence in the quality of the thinking that isn’t always comfortable to assert.
But the products that result are more coherent. They feel like they were made by someone who had an opinion about what they were doing. That’s rarer than it should be.
None of this means you should avoid shipping early. You should still test and learn. The feedback loop matters. What I’m arguing for is slowness in the right places. Slow thinking. Fast execution. Deliberate choices about which phase you’re in and what quality looks like in that phase.
The MVP is a release decision, not a design strategy. There’s work that happens before it that determines whether it’s an MVP of anything worth building, and that work benefits from time, care, and the willingness to sit with hard questions rather than shipping past them.
The best design I’ve been part of felt, at the time, like it was taking too long. In retrospect, it was taking exactly as long as the problem required.
Slow down enough to build a direction. Then go.
