Raw thoughts from Alex Dong

Why release early is so hard and how to stay on course

“Release early” is probably one of the most important things that every startup should remember.  As a serial entrepreneur, I have inevitably pitched this idea many times. So you can imagine how surprised and disappointed I was when I was asked “why it took so long to release?”.   I have fallen into this classic trap of startup. I keep on iterating the product without releasing it to the wild.

In the Odyssey, the Sirens sing a song so irresistible that none can hear it and escape. Circe warns Odysseus of the danger and tells him how to avoid it. He must plug up his mens’ ears with beeswax, and have himself tied to the mast, if he wishes to hear it.

I spent the last month thinking about how to stop myself making this mistake again. The conclusion turns out to be surprisingly simple. Treat ”release early” as a religion.  All the reasons that put off release could have reasonable arguments.  They would make perfect sense when you think of them as stand-alone problems.  But at the end of the day,  no matter how valid the points are, faced with the “irresistible tendency”, we should probably follow Circe’s advice and treat release early as an unbreakable belief.

My frist mistake is also the most common one: “one shot mentality”.  I over-estimated the importance of the first shot. I worry that if we deliver an inferior product, if we get the color wrong, or the text not lined up properly, or the warning dialog box doesn’t have the proper drop-shadow, people will remember these for the rest of their life.  You may find this laughable. You may ask who would be so stupid to waste time on these trivial things. Well, the world is full of people who are fanscinated by the icon ambulance story or don’t accumulate technical debt.  As we sink deeper and deeper into the product, it’s almost impossible to refrain ourselves from worrying about those details. Except maybe having a mast we can tie ourselves to.

With a deadline, it becomes a lot easier to decide which one is more important. Shall we support a close integration with facebook or implement an internal tool to track bugs because frankly no bug tracking system on this planet gets it right yet.  A deadline also acts as a “shakedown cruise ”. If anything major is broken like the founders hate each other, or the engineers want to stab the designers from the back or the idea is fundamentally wrong, the stress imposed by the deadline will help to shake these problems out.

However, an artificial deadline is, well, artificial. Everyone knows it’s just some date that the CEO grabs from thin air.  There is always a tension to push off the deadline a bit more. “One week, we just need one more week.”   Unfortunately the longer the team works on the problem, the more they understand it and the more problems they can see. If the team starts to dogfood their own product, someone somewhere will always find some fundamental flaw in the product that needs to be addressed before the product can be released, like IE8 support.

The real danger here is who the product is designed for. The longer the product stays in the hands of engineers, the further it is steered away from the real user who might be using it.  PG once wrote:

One of the things that will surprise you if you build something popular is that you won’t know your users. Reddit now has almost half a million unique visitors a month. Who are all those people? They have no idea. No web startup does. And since you don’t know your users, it’s dangerous to guess what they’ll like. Better to release something and let them tell you.

Things could be even worse if the developer is solving his own problems.  For every improvement he does, he might alienate 100 other users who would otherwise use the service.  It’s almost like we have to keep reminding ourselves that some random person on the internet knows better.  If we could put our ego aside and stay humble, this is exactly what “release often” and “iterate” mean. To listen to what your users ask for and build it for them.

When a deadline is not sufficient, the startup team needs to have some external expectation. For example line up some journalists and release the news of product launch date to the wild.  Or making the CEO the champion of external world in the team.  If he has announced the release date to content partners, channel partners, potential users or investors, he will feel personally obligated to meet the date. Hence making it much harder to extend the deadline.