Think before you break things
Why "move fast, break things" doesn't mean ship garbage.
There are a few tropes in Silicon Valley that follow along the same theme — that a bootstrapped, scrappy [even sloppy] but high-velocity approach to product-building and, more generally, company-building, will always prevail:
“move fast, break things”
“do things that don’t scale”
“if you’re not embarrassed by the first version of your product, you’ve launched too late”
Within the appropriate scope, these are, of course, great pieces of advice. From my own experience, for example:
By moving fast and breaking things, I’ve found I can quickly learn how to build the thing I need to build, which is a substantially better means to learn the limitations of my understanding than to try to shoot the arrow in the right direction from the get-go. The best way to see 5 feet further in fog is to walk forward 5 feet, or so they say.
By doing things that don’t scale, you can optimize for what really matters, e.g. manually giving customers untenable, manual spikes of delight, rather than agonizing over building system to accomplish this worse at scale.
By shipping something “embarrassing”, you are effectively prioritizing better, forcing clear thought on which product features are essential to test the hypotheses you are going after.
And that’s because these pieces of advice align very tightly with very specific objectives. And when those objectives are your objectives, of course you should follow this advice. But that said, there’s no free lunch — with each one of these objectives, there’s something else being sacrificed.
And as these aphorisms have become meme-ified, they’ve also been blindly applied without properly navigating these tradeoffs. For instance:
Build fast, break things is great when you don’t know what to build and need to optimize for learning how to build. But it’s a terrible philosophy for actually building a scalable product. It means “learn fast”, but it’s often taken to mean “ship garbage”.
“Do things that don’t scale” is a great mantra for GTM and product teams, particularly when trying to garner customer love — the essential thing about love is that it comes from relationships, so focusing on that main component rather than scalability will always keep the main thing. This does NOT mean you should “do things that don’t scale” when trying to build a scalable engineering backend, for instance.
Finally, shipping something “embarrassing” is too often taken to mean “ship something that’s a pile of worthless shit.” If you already know what’s wrong with your product, this is going to generally just get you feedback that you know already and churn your leads. It’s one thing to build an appropriately scaled-down product, but another to build a product with such jarring deficiencies that no one will be able to use it any meaningful way and so won’t be able to give you any reasonable feedback (at least, nothing more than Figma mockups alone could do).
In engineering work, in particular, misapplication of these tropes can be very destructive. Adopting these patterns carelessly can lead to an immense amount of tech debt that you can never crawl out of, which inevitably reduces stability and usability of the product. Your employees burn out trying to resolve issues from within a mountain of garbage code. All of your early design partners churn — losing those who would be your fiercest advocates and ruining your brand perception to boot.
All this is to say: you should generally try to think about things before you do things, however obvious that sounds. As with most bits of meme-ified advice, these tropes are not inherently bad. But just remember that they can go completely awry when misapplied. You’d be wise to think before you blindly apply them.