Launching is incredibly important. But a big splashy launch day is a waste of your time. Putting your application in the hands of real people is the most important thing you can do.
Before we dig into this, I want to dispel the myth of launch day. Certainly, launch day is not meaningless–it’s a significant milestone for any team–but the notion that it needs to be a flashy event with lots of traffic, attention, and perfectly timed media announcements does more harm than good. If you were to have a spectacular launch day and an influx of traffic, the risk of a major bug or even downtime could completely negate the benefits of your snazzy event (but we’ll address that with the next chapter, which is about launch day strategies).
You deserve to celebrate your launch, but keep in mind that it’s a fairly brief moment in the grand scheme of things. It’s tempting to fall into the trap of wanting your launch day to be a perfect event with media coverage and massive amounts of attention. Remember, within forty-eight hours your traffic will settle down to normal levels, and it’ll be back to business as usual. What you do after your launch determines whether you’ll succeed.
Don’t think of it as launching a completed product, but rather a foundation from which you can gather feedback and bring in the revenue that will ultimately fund your vision. In that context, launching too late often carries greater risks than launching too early. You don’t want to launch garbage, but you should launch before your product has all of the features you think it needs. Absolutely nothing helps invigorate your team like releasing their work into the world. In a way, this is just the first launch of many: every new feature has its own launch day. This first one is just you dipping your toes in the water. You’ll eventually get launching down to a science.
As a startup, your biggest risk is spending your limited resources on the wrong things. Premature scaling. Features no one will use. Internal tools you don’t need. Those are problems you shouldn’t worry about yet. No matter how confident you feel, there’s no way to have all the right answers until real customers start using your product. You introduce more risk with every day you don’t launch.
The instinct to add more features before launch often stems from the assumption that new features carry only benefits and no drawbacks. But I think it’s the other way around. Every feature and delay carries significantly more drawbacks than benefits at this point in your product’s life cycle. Until you receive real-world feedback from paying customers, you simply don’t have enough information to make the best decisions. Moreover, every day that you’re not generating revenue, you’re inching towards failure.
Sifter was missing a few features when we launched. It was coming down to launch time and we had to choose among themes, search, file uploads, an API, or milestones. We launched without any of them. We added some shortly thereafter, but launching without these “critical” features didn’t kill us or ruin our launch.
I felt incredibly uncomfortable telling people that Sifter was ready, but as it turned out, it wasn’t a big deal. A handful of folks asked us for some of the features that were missing, but that didn’t stop us from launching. Sure, we may not have had every bell and whistle, but we were making money sooner rather than later. And that money helped fund the work on those features.
While some features are essential to the long-term life of a product, there aren’t any silver bullets. If you were to look at Sifter’s growth over time, you’d notice that there aren’t any spikes when we’ve added significant features. Just slow and steady growth.
Nothing is more important than getting your product out the door. Launching gives you feedback, revenue, and momentum–and that’s when the real work starts. Celebrate the achievement, but don’t obsess over the event.