What we learned from moving fast and breaking things
For startups, moving fast is great for learning fast, but moving too fast can lead to startup lessons best learned from others. We’ve been building in public and moving fast for our AI social media manager Natasha. But we moved so fast that things broke, we irritated people and got our app restricted by Twitter. With the brakes engaged, we’ve been fixing bugs, repairing relationships, and thinking what to do better. Here’s what we’ve learned.
First, some background. Moving fast is in my DNA. I’ve worked at startups for most of my career. The rest of my time was spent in quantitative finance, where correctness is often more important than speed. Most of my career success stems from delicately balancing these two competing needs, such as building a financial exchange for derivatives from scratch with 65 us latency or building a near real-time bond pricing system covering 22k US corporate bonds that beat the industry standard by 30%.
Despite these experiences, I still messed up launching Natasha. We spent 4 months developing at a breakneck pace and launched our pilot for Natasha with 10 customers 🍾. Things seemed great! But just a few days into our pilot, a bug surfaced that resulted in some people being spammed by our scheduler and our app being restricted by Twitter. Not the result we were looking for 😭.
So what startup lessons can you learn from our mistake? There’s nothing wrong with moving fast. But speed is a byproduct of being deliberate and efficient. Otherwise, you’re left with nothing more than the chaos of a puppy. Here are some concrete takeaways:
Avoid collateral damage – consider who is affected when something breaks. Is it limited to a small group of users or can a problem affect a broader population? In our case, people who weren’t users got spammed with multiple messages. That tarnished our brand in the very community we were trying to court.
Be vigilant – the faster you move, the more monitoring you need. Set up alerts, check logs regularly. In our case, I fell victim to my own unchecked hubris. Our scheduler had worked well for a few weeks, so I didn’t think there would be any issues with it. Unfortunately, a hidden bug was activated when there was a change in another part of the system.
Avoid breaking things that are difficult to repair – moving fast often means making decisions that are half-baked. Before acting on a decision, think about how difficult it is to fix what breaks. If it only takes an ounce of cure, then an ounce of prevention isn’t necessarily worth it. But a pound of cure requires more planning to avoid that situation.
Know when to slow down – if things are breaking more often, that’s a sign you need to slow down. A startup isn’t a race; it’s a journey. Success comes from enjoying the journey, not from racing to the finish. Take the time to do things well (not perfect). On the dev side, write more tests, design more upfront. On the business side, set better expectations and boundaries, communicate more.
Build in public, apologize in public – Admitting mistakes is a sign of strength, not weakness. Be willing to step forward and say you messed up. Share what you learned. Our little fubar reminded me of these lessons. So we’re slowing down, building in controls, and communicating more.
In retrospect, I knew most of this prior to this public failure. I broke a lot of my own rules for the sake of speed. Thankfully, this reminder happened during our pilot where we have limited users that are all accommodating.
If you find these lessons helpful, please share this article!