How do you determine what features are enough for launching? Should we launch with the "bare functionality" without goodies? Or should we add "bells and whistles"?
How do you decide? Is it true we can "get burnt" of suddden exposure, or is sudden exposure rather a myth, and exposure is slow and gradual.
Your suggestions are welcome.
I agree, just make sure you're TESTED! Better small with promises than large with bugs, and not fulfilling your side of the deal.
Adding BETA to your logo doesn't make bugs any easier to accept.
In my experience, it's usually better to release as soon as you have polished the core functionality. And if a feature is very important to a customer or the target audience, it no longer belongs to the bells & whistles and should be rather considered a core feature, no matter how easy it is to implement or how little it adds to the product.
If you're lucky enough to have a choice, release as soon as you have an installation routine and a single useful feature that works.
Like most things, my answer is 'it depends'...
What is the purpose of your software ? If it is an application aimed at a specific set of users with specific needs then you need to make sure you meet enough of those needs to make it worthwhile for people to use your system (remember, most people believe once bitten, twice shy - you won't get a second chance). Would you buy a car that didn't turn left ?
If your application is more general, and you're aiming at a particular slice of users from a wider base (usually techie users) to help evolve your app along agile lines, then release early and often. Many of these types of system don't plan releases based on time, but on features, i.e Version 2.1 will be released when all the tickets assigned to 2.1 are marked as complete, or dropped.
I would also say it depends on the market. I would not release a product without one (even simple) killer feature. Even in early releases, you have to build up some reputation.
There are two dogmas to steer clear of:
Don't release until you are finished.
and
Release as soon as you have anything, no matter how small.
I like the latter approach, but it needs to be taken with a grain of common sense. There's an overhead to any release, depending on your organization and product.
Don't get me wrong: releasing early and often has great advantages, particularly since we never get the business requirements quite right, but you need to weight those benefits against the real costs of a release. This is one of the reasons I like internal releases interspersed among the 'real' releases: they have lower (if nonzero) costs, but keep you development process honestly progressing.
In the end, I guess I end up with the classic consultant's answer: "It depends"!
Is it true we can "get burnt" of suddden exposure, or is sudden exposure rather a myth?
Did you see the news in the press about the launch of Cuil.com? Their press releases touted it as a search engine that would kill Google, yet simple searches produced astoundingly bad results. (Ex. Searching for "COBOL" told you that there were no results for COBOL.) The sudden burst of trafic from the announcements also overwhelmed their servers. I would say that they got burnt by the sudden exposure that they experienced at launch.
Some people call this a "Hollywood Style" launch because it's similar to the way that movies are launched. There are some benefits to this style of launch that you don't always get from a gradual accumulation of users. However, most of these benefits are outweighed by the fact that first impressions are very important and the usual complexity of a product makes it very easy to have a bug spring up and give most of your potential users a bad first impression.
The question is, launch what?
If you're doing internal software, you want to get the users involved as early as possible, so giving a few of them something quick is a good idea.
If you're doing open source, release early and often, with a roadmap for future development.
If you're doing shrinkwrap software, you need to give the users something good for their money. Don't count on charging them for the upgrade that actually makes the software useful, unless you're a large established company that already does that. Unless you're known as the primary source of that sort of software, nobody will bother paying you twice after being burned once.
If you're doing web services, you need to have something useful when you release. It can be small, but it should give the user a reason to come back. Otherwise, it's "Foo.com doesn't have anything good on it, don't go there" even after you've implemented the dancing elephants or whatever. You need to leave the user feeling good about your site, and ideally curious to see what you're doing next. If you're going to release with a splash, make sure a whole lot of things are working.
If you're doing embedded, you release when the software is sufficiently close to perfect, and everybody's signed off, and not a moment earlier.