Be Butchers, not Brain Surgeons
“…The life of any startup can be divided into two parts — before product/market fit and after product/market fit.” — Marc Andreessen
If a startup don’t have product/market fit, finding it should be the first, second and third priority. Everything else should be sacrificed.
For software engineers, that means: If you don’t have product/market fit, don’t worry about scalability. Don’t worry about arriving at the perfect architecture. Don’t worry about style guides or code cleanliness. Write ugly code. Write code you’re ashamed to show your peers. Write fewer tests. Fix fewer bugs. Refactor less. Optimize less. Best practices are for later. Be Butchers, not Brain Surgeons.
I’ll bet that sounds wrong to you.
Consider this: 90% of startups fail. That’s a lot. Every startup without product/market fit is a crisis, and we should behave accordingly. That means ruthlessly focusing on what brings you closer to that fit and at the expense of everything else.
Startups don’t fail because of a bug or for lack of tests. They fail because they run out of time. Startups therefore should focus on velocity. Each product launch or refinement is an experiment — you want to fit as many of those experiments into your runway as possible.
It took me a long time to come to this conviction and even longer to live it. It certainly isn’t something easy to accept — it cuts against all of the “best practices” we’d want to advocate if we weren’t at an early-stage startup. Even more painfully, it puts our egos and reputations at risk. Engineers are judgmental about each other’s work, and working fast means working sloppy. It goes against our own instincts, which are to build something great. Being a butcher requires repressing your own drive for quality.
This requires a totally different mindset. As Amit says, before product/market fit we should think of ourselves as prototypers, not engineers. It’s not an easy change to make. But if we don’t make that change, we’re wasting our time perfecting something that we’ll likely end up throwing away.
Naturally, it’s about striking a balance. I’m not saying write no tests. I’m saying only write tests that provide high value. I believe that most startups strike the wrong balance and err on the side of code quality and best practices.
Let me put it another way: would you rather survive with an ugly codebase or fail with an elegant architecture, high test coverage, etc.?
This doesn’t just apply to engineers. It applies to designers as well, for example. No designer should waste time tweaking a pixel or retiming an animation before product/market fit. Your time is better spent elsewhere.
Hopefully, you’ll eventually find product/market fit. That’s the time to pump the brakes and starting doing things “the right way.” By the time you reach that point, you’ll probably have changed direction or started over at least once — and you’ll be glad you didn’t waste any more time than necessary on the work you’ve left behind.
Fred Brooks said, “Plan to throw one away.” I’d go a step further. When it comes to product, “They’re all disposable until proven otherwise.”