To Launch or Not to Launch
One of the most difficult aspects of creating a new product is deciding which features are necessary for launch. Leaving out features can make you uncomfortable. However, there's a point where you should be more scared of adding features than leaving them out.You really have two options. Launch earlier or launch later. That part is fairly straightforward. The hard part is figuring out where those points are on your development timeline.
That's simple enough, but, if we think about it, the time to implement a certain set of features is going to be the same regardless of when we launch. "Feature X" is going to take two weeks to build whether we launch today or launch after it's implemented.
However, if we launch today, we'll be providing a working product a month earlier for everyone who doesn't need "Feature X". We may even discover that nobody wants "Feature X" and that we should instead be focusing on "Feature Y". Or maybe they just want "Feature Y" first. Either way, the earlier launch is exposing you to real ideas from real customers, and that can only help.
Even if you launch without some features, they aren't going anywhere. You can launch now without the features and add them in a month, or you can launch in a month with the features. Either way, a month from now, you'll be in about the same place.
So what's the real dilemma? I can't quite put my finger on it, but sometimes it's hard to cut back on an original vision. Other times, I suppose it's a matter of feeling like we have to have all of the features that the competitors have. Either way, it's too easy to become fixated on the vision in our head. There's inherently more risk in delaying the launch than there is in coming up short on features.
If you launch earlier, there's a chance you may learn that you prioritized the new features incorrectly. As an added bonus, an earlier launch means revenue will be coming the door sooner as well. Alternatively, if you delay the launch and work on the wrong features, you've just misused the most valuable asset you have. Time. That's a hell of a lot worse than putting out a product that's too simple.
The only real risk is that people could be underwhelmed with the initial release, and the launch could be anti-climactic. However, that's really not a bad thing. It just means we have more time to listen to people and give them what they really want in the next release. That doesn't seem like such a bad option to me.
The Latest
We built a simple bug and issue tracker named Sifter and we blog about it when we're not working on it. We think it’s a great way to get feedback and keep everyone updated on our status.
Grab our feedSignup for our occasional emails…
We'll only send emails for significant product announcements, and those happen every couple of months at most. Of course, we won't give away or sell your e-mail address either.
Comments
My guess is that people will understand. Your initial customers will come through this blog (or yours), and will know that the creator(s) is/are listening to them. If there's a feature they want, and others too, it'll be implemented in a couple of weeks.
My opinion: Launch early.
I get where you're coming from, but I've never found it to be that straight-forward. The way you write it out and make your point though is very compelling, and I can't find a good way to justify that "itch" that irks me when I think about pre-mature launch.
My question now is how would you apply this logic to an upgrade? Not a trivial, small feature upgrade but perhaps a large paid upgrade. Going from version 1.x to 2.0 perhaps.
Would you be more cautious and then worry more about the underwhelm effect? Or would you continue to just release as soon as it's ready and go from there?
Valid points all around. As I am documenting the feature set for my application, I am also thinking about these things.
I wonder if that variable that you can't quite identify is that of the balance involved with roadmapped features vs. customer requests- the balance of adding features according to your product roadmap as opposed to working on fixes and requests that will inevitably fill up your inbox once the product is in the wild. With most sites I have built for clients, there is a decent amount of time spent post-launch on little fixes and changes that the client finds (usually their visitors find) that intrude on time I am spending on my next project. Its never fun but usually there are at least a couple of things- and sometimes quite a list builds up.
Great post. Choosing when to release is something we all struggle with when building a web app. I think the concept is pretty obvious to release early and often, but you explain it very clearly. Nice work.
I can think of one other reason for delaying. Once you launch, you'll have to deal with customer support issues in addition to your planned features. That can slow down your overall development effort. Of course, without customer feedback, you might never spot the problems in the first place.
Whenever you decide to launch, we at Infovark would be happy to give Sifter a workout. We've been looking for a simple and elegant bug tracking system for a while.
Cheers,
Dean
Sound like a soft launch is the best solution. Open it to some.. keep the media out. Every one wants the big WOW moment but you also want users to start using it as well. Seems like the best of both worlds.
I believe in the "launch early, release often" adage, because as you said in your post, you may find that your users don't want feature x, but really want feature y. Having real users on your product is more valuable since you will be able to see what direction they will take it and see what is really needed, not what you think is needed.
Actually, after the release, the development usually turns out to be slower. If the people lay hands on the product, you will be overwhelmed with various support requests you perhaps haven't count on. So after the release, you'll perhaps get to the feature X much later than if you do it before the release. However, the less features you'll launch with, the less bugs may come, but still, user imagination is ticking around the real product he's using, and he has the power et right to bug you. :)
Jesse - I think "large" upgrades should be a very rare thing. The goal is to constantly evolve in small safe strides. Of course, every now and then, when there's a large release, I would think it would be alright to have a long cycle without any minor updates.
Going through the exact same thought process right now. We've settled on doing an early soft launch for all the reasons you mentioned. Additionally, having happy, paying customers in the pipe when you "officially" launch looks good to other potential customers and press.
Good luck with your decision.
P.S. We definitely aren't going to be underwhelmed ;)
Hey Garrett,
Just wanted to say good luck with the launch. Our products have some overlap (ours being Lighthouse), but good luck nonetheless. I really like and have been inspired by some of the design decisions you've made along the way.
P.S. I just realized today we've played COD4 together with Dan and Bryan. I'm Encyte on Xbox Live.
Justin - Thanks. Yeah, there's some overlap, but at their core they're definitely targeting different audiences. I see it as being kind of like Photoshop vs. iPhoto. In fact, I'm expecting we'll suggest Lighthouse on the Sifter site for people who are looking for something that's more flexible.