Launching Early
I found this in the drafts folder of my blog. I think I wrote it around a year and a half ago but never got around to publishing it. It finally sees the light of day.
The motto “launch early” is often thrown around as being good advice for startups. It’s probably Paul Graham’s second most repeated phrase (behind “make something people want”) and Reid Hoffman has said if you’re not embarrassed by the first release, you launched too late. Here are some reasons supporting that argument that have been milling around my head for a while based on my own experience .
1) Staying determined - When you first have the idea for a startup you’re always at a knowledge deficit i.e. there are always unknown factors that are going to come along and displace your initial assumptions, making you question what you’re doing. The problem is that you don’t need to be launched to go through that process - every extra bit of knowledge you gain about the market you’re operating in is a step closer to finding that detail that is going to scare the shit out of you. That’s tough to deal with. It’s even tougher when you go through that process without being launched. There is absolutely no feeling that is comparable to having a user tell you that your product is awesome. Even if it’s only a handful of people it still injects you with energy. Being launched brings with it a new level of stress but it’s the right kind of stress - it’s the kind of stress that drives you to work harder and faster. The stress you work with when you’re not launched is a different kind altogether, it’s a more destructive force and there’s only so much of it a person can take.
2) Keeping the problem simple - It’s much easier to start solving a small definable problem and add layers to it than it is to try and solve a monstrosity from the get go. It’s the old you can’t eat an elephant whole idea. If you put pressure on yourself to launch early you’re forced into only being able to solve a simple problem initially. The mental exercise of taking the initial problem you’re trying to solve and then breaking that down into smaller problems is invaluable. If you start simple you’re less likely to make mistakes and get off the ground sooner (look at Facebook - it started off as something incredibly simple and has evolved into something else entirely)
3) Keeping an iterative approach - It’s highly unlikely that you’re going to have the flow of Idea –> Build –> Launch –> Lots of traffic (though there’s always an exception to every rule - the most recent one I can think of is Scribd which grew like mad from day one). It’s more likely that you’re going to launch a first version that doesn’t get many users and you need to tweak something or go in a slightly different direction (or maybe even scrap everything altogether and do something totally different). That’s easy to do if you haven’t invested a lot of time in getting that version one ready. On the other hand if you’ve spent the best part of a year getting to that version one, you’ve now got a big emotional investment in that product. That’s dangerous because now you’re going to find you have emotions that don’t want to change the product. The exception to this is if your product is going to take a long time to develop just by virtue of what it is (e.g. Xobni, those guys are building something that’s inherently more complex and powerful than a standard web app).
4) Parkinson’s law - “Work expands to fill the time available” is a big issue when you’re working on a startup. When you’re in a company, there are externally imposed deadlines that can come from clients, departments or your boss. In a startup you set your own timetable and agenda which can be a dangerous thing. If you’re looking to raise investment you might find yourself spending extra days perfecting your executive summary or slide deck. If you’re hacking, you could fall into the trap of continual code re-factoring or working on irrelevant back-end problems that you find interesting. When you’re launched and have feedback from users, these things go away. Now you have to focus on driving growth, if you don’t prioritize and work on the right things at the right pace - your key metrics will be staring you in the face with the truth.