If you’re not iterating, you’re already falling behind
When I worked at Facebook in the early days, we used to talk a lot about what would be “the new Facebook”, because if we didn’t become the “new Facebook”, there was a hundred YC startups that surely would. There was a definite sense of urgency around shipping new code.
This sense of urgency is, in my opinion, the true meaning of “Move Fast and Break Things”. It wasn’t about carelessness and disregard for users, although sometimes it did unfortunately manifest that way. Instead it was about accepting a certain amount of risk you’d break something in return for the perceived upside of forward momentum, because with so many companies wanting to be the next Facebook, if we weren’t moving forwards, we were moving backwards.
Obviously that hasn’t yet come to pass in the truest sense of the Facebook being toppled as a company, but the sentiment still rings true, regardless of what your product is. It’s kind of like what Reid Hoffman says.
If you’re not embarrassed by the first version of your product, you’ve launched too late
When I hear that phrase, what comes to me is this - What you build will never be perfect. You can spend an eternity on polish. In fact, it can drag down your whole organization. It’s infinitely better to ship what you have and iterate. Obviously there’s a quality bar to meet depending on your product. A pacemaker has a higher bar, than say, an app to connect people for dating. But as much as possible, all your processes should bias to releasing what you have at that moment.
The cost of iteration
For software, the cost of iteration has never been lower. Infra as a service, feature flags, CI/CD as a service, and much more have created an environment that enables increasing faster development cycles.
As an example, these days when bad code is committed to a code base, it’s sometimes quicker and easier to fail forward than it is to revert. When you’re dealing with a primarily server based piece of software, you can keep rolling deploys and get a fix out much easier than the days of floppy disks and gold master CDs, so you have an inherently lower risk profile, and as an industry, we should be leaning into that, not getting ever more cautious.
Feedback fuels the best products in the world
The reason you should be doing this is because feedback is the lifeblood of a good product. Ship the smallest possible unit, get feedback, iterate. Repeat.
As you iterate, you’re refining, you’re improving, you’re getting closer to something that solves a need for your users.
Move a pixel, nudge a button, publish a blog post, knock a few ms off a load time by sorting a collection differently. Whatever releasing means to you, be doing it.
Iteration as a super power
If, like me, you work as a Developer Advocate, then encouraging Product Managers to incorporate feedback from the community and getting other engineers to push that code into the hands of that same community in order to get more feedback should be a critical effort of your team. You and your community are direct benefactors of the historically low cost of iteration in modern software, so use it as a super power to deliver an ever improving platform for the developers you serve.