← All Essays

The Vicious Cycle of Shipping Slow

The hidden cost of taking too long

An illustrative image for this article
Original photo by Juli Kosolapova

You know that moving slowly limits your options. It causes you not to try to get it right as many times as your competitor might, you iterate less and end up with subpar solutions. The value is obvious.

Something you might not notice is the effect it has on the culture of your product teams. When you take a long time to ship and don’t iterate soon afterwards, the people making your product feel like they won’t have a chance to reevaluate their decisions. And that is the mother of all brakes.

The cycle

When engineers feel they won’t have a chance to clean up their code in a following iteration, they feel compelled to anticipate everything which could go wrong, over-investing in architecture for something which might work and handling obscure edge cases which may not matter. The need to get it right the first time makes them even slower.

When designers feel they won’t have a chance to improve on an experience soon, they feel compelled to spend more time finding the perfect solution, polishing details and not letting any imperfections go. The need to get it right the first time makes them even slower.

When product managers feel they won’t have a chance to iterate or revisit their hypotheses, they feel the responsibility to pick the right answer the first time, which requires more analysis and hard to articulate, one-sided decisions. The need to get it right the first time makes them even slower.

When anyone thinks they’ll won’t be able to improve upon what they’re shipping, scope grows out of control, because this is the one chance to do it. The need to get it right the first time makes everyone even slower.

And the cycle repeats, slower each time.

Break out of it

When you make quick decisions, launch fast and iterate soon afterwards:

  • Designers let go of small details and completeness, because they know they’ll have to make changes to the design anyway. They still get to polish things, but over time, not at once.
  • Engineers let go of perfect architecture, because they know actual usage will better inform their design.
  • Product Managers let go of having the right answer, because they’ll be able to validate it and adjust it, and will eventually get there.

So next time you’re thinking of delaying a project just a little bit, even if it’s to improve your chances of getting it right, think about the hidden costs of that decision down the line. It may be worth it, but good chances are it’s not.

Assume you’ll be wrong. Ship fast. Revisit quickly. Now go!