The paradox of how bugs and downtime can be a good thing

January 14, 2013starting up

Often if I give a talk or I speak with someone about getting their idea off the ground, the topic of how solid the product should be comes up. In particular, people very frequently wait far too long before launching.

One of the key learnings for me with Buffer was that the impact of problems people have and downtime they experience are directly tied to how we, as a startup, choose to handle it. Let me share some examples for why this is the case.

Downtime is an opportunity to make people love you more than they did before you went down

"Life is 10% what happens to you and 90% how you react to it" - Charles R. Swindoll

As Buffer grew from a few hundred users to tens of thousands in the first six months, we hit some scaling issues, in particular as a result of my lack of experience in scaling MySQL (as an aside, we’ve since moved to MongoDB). I quickly learned how to optimize queries and which indexes to add. I often needed to resize the single Linode instance Buffer was hosted on. As a result, there were times of both unexpected as well as deliberate downtime in the early days of Buffer.

One of the most remarkable things we found during these periods of downtime, was that if we were super responsive on Twitter, we could actually gain some very loyal Buffer supporters. The scenario would be that I (or later, Tom and I) would be hard at work fixing the issues, and Leo would be 100% focused on responding to Tweets within seconds. What we found, which is very counterintuitive, was that in some ways by being down, we had emerged in a better position afterwards than we were beforehand. This insight helped us to be much calmer about downtime in the future.

With bugs in the wild, you’re forced to work harder and faster. Your product improves quickly.

I’ve found that some of the hardest stages of creating a new startup are those early weeks or months when you’re racing to get your product ready for initial launch. You’re trying to decide how polished the product should be, and how many features you need to include.

Through my own experience and speaking to other founders who have launched products, I’ve found that we almost always say we should have launched sooner. The thing is, when something is live, that’s where all the learning happens. Until you put it out there and get real usage, you’re sat in the dark coding and have no idea if it will work.

I would even go as far as to say that you should “push it live” when there are still a few bugs or it doesn’t look perfect. Once it’s out there, you’re going to fix them faster, and your users will find and tell you about problems you had no idea about. Doing this is a nice hack to increase your productivity: I’ve found that when I did this especially in the early days, I always had a great todo list and was compelled to work away at the items. Essentially, the product will improve much more quickly than if you work quietly in stealth mode.

Handling challenges and pressure is a key skill for startup teams

One of the things that is often said is that startups are inherently a process where there is a massive amount of uncertainty. Alyssa and Andy in the team certainly know that we can change our minds about even fundamental aspects of Buffer literally from one day to the next. It takes a certain type of person to be able to handle this kind of environment.

With this uncertainty, often those involved with a startup are faced with some fairly pressurised situations, whether it is downtime or figuring out and fixing some critical bug quickly. I think these times are really the ones where, more than anything, the team needs to remain optimistic and positive. Therefore, any bugs or downtime that comes up, is yet another opportunity to practice these traits and in some cases to find out who can see those situations through while remaining calm and productive.

The other thing that we’ve often found at Buffer, is that we look back on the downtime and those times where we are up all night figuring out how to get Buffer back up and realise that in those few hours we’ve learned a massive amount. In that light, we don’t wish that those scenarios wouldn’t happen.

Photo credit: Bearden