MFS = Minimum feature set: what's the minmum set of features that would make your product useful enough so people will bother to sign up for it? Is it stable enough?

I know we have the mantra "release early and often", but if you release something way too early, people will look at it, close the browser and move on. Maybe have friends or other people you know take a look at it, before releasing it as a beta?

Depending on the audience of your product, you can have even family try it out. If it is something for general public, you would get a lot of feedback from sisters/brothers close friends about usability.

My benchmark are my sister and brother in law. They are both pretty smart (one a financial analyst, and the other the lawyer), competent in computers, but definetly not techies. if something in navigation doesn't make sense to them, then the general public will have even more trouble figuring it out.

You should get someone to test it that would fit in the user set.

I think they have a name for those... wait for it... they're called users

I really think it is important to do a alpha round and it is even better if you do it before you have all the features on. And you know why? Because your friends that come and test your alpha version will tell in what direction should you head. They will now better than you. Maybe those features that you say will make your app complete on a minimal level is not what your audience is looking for.

My best!

In my experience it's best to just get something out there as soon as it's interesting to play with. It'll get content into your system, it'll point out problems and possibilities that haven't occurred to you, and there's nothing like real users to motivate you to focus on getting the most important things done as soon as possible. I've worked at a number of startups that wasted a lot of time working on features that turned out not to matter at all, because they thought they couldn't release without them.

I sometimes hear this idea that you only get once chance to acquire users, that they'll show up, take a look, and if your product isn't good enough, they'll never come back. I think that's just untrue. First off, the chances that your product will cause enough of a stir to reach your entire potential userbase when it's not very good yet seem pretty low to me. And second, there are plenty of examples of companies that had to completely reinvent their product more than once before they found success -- off the top of my head, Flickr is one of those. I worked for another company that did that, and I didn't notice any problems getting people to look at version 2.

From my experience, you want to really as early as possible once you have enough features to present your core idea. My partner and I spent so much time fixing every little thing, identify every little bug, because we were afraid of launching an "incomplete" alpha may turn users away. To our surprise, the early adopters are actually your best friends, they will provide you with great feedback that may change the direction of your idea completely. In our experience, our users' feedback really changed our focus on which area of the site to develop.

We wish we released earlier. So my recommendation is, once you have all your core feature to demo your idea, you should released to a group of friends/family to test it out.

Wait. Remember that you get only one chance to make an initial splash and attract the attention. First impression lasts. There's no reason to waste the opportunity on something that is not ready or does not work 100% flawlessly.

If you really want to test the system on live people, do a round of closed alpha. However if you want to demo the stuff, wait until it's ready.

(an update)

Hmm .. I should probably add that the above is based not only on a common sense, but also on my personal experience. The project I was involved with grew from zero to a couple of million users in 1.5 years out of a single public announcement. If the project were not as polished as it was at that point, I really doubt the viral propagation would've as massive.

I agree with huhtenberg. The number of people who left quietly is much more than that of people who give you feedback when you don't have the minimal feature set.

Release early. Release often. Listen to your users, not commenters.

Bring in as many testers as will be useful, as soon as they will be useful.

In my case, I have a codebase which meets the "minimum feature set" criterion of "is this something people would like to use"; but I've only invited in a relatively small number of testers, because having lots of people test my code right now would (a) result in me spending time creating accounts and explaining things to people instead of writing code, and (b) result in people being misled about certain key aspects of the functionality.

At the point that I bring in lots of testers, I'll still have issues of accounting (not a problem, since at least the first wave of beta testers won't have to pay), scalability (not a problem, since the beta testers will be a small enough group that I won't need as much scalability as I will ultimately have), and performance edge-cases (which will be documented as "these things don't work very well; don't worry, they'll be much faster soon") left to address; but overall I want my code to be in a state where the vast majority of beta testers say "wow, this is amazing" and run off to tell their friends about it as soon as I let them in.

Cut features, don't cut quality, and avoid cutting so much that you enter a different market entirely. You want to launch as soon as you're better than the existing alternatives for your target market. If your target market is fairly empty, that should be soon.

But you don't want to enter a crowded market just because it's easier to push something out the door. We made that mistake with Diffle; I figured that I could do the website features while still keeping my day job, so we pushed those out the door before working on the thornier game-creation problems. But that moved us from the game-creation business to the game hosting business, which is a much more crowded and competitive area. Our initial launch has been less successful than we'd like - not just in terms of users (which we're gaining, although they're fairly low-engagement users), but in terms of information. We haven't learned nearly as much as we wanted from the initial release, because the folks we're targeting for game creation aren't looking at us yet.

me three. it is so easy to announce -- you just tell people. it is more difficult to deliver. so, sharing with a close group of friends is not only what i recommmend but also the way i plan to go, too, in deciding whether to make it public.

but, i'm with you -- it is so tempting when you work alone to get feedback. so getting feedback from people that are close as ardit points out is the way to go.

If it's of any use whatsoever in it's current state, release it, and get people using it. Call it alpha/beta/whatever, it's just a name.

I would open up the alpha only if you have third parties (or customers) who want to write to your API. Then you should get it into their hands as soon as possible.

Otherwise, wait until you have a solid beta. If you screw up your first release (whether, alpha OR beta) you may not recover. Better to make them wait. After your first solid release, you can go agile-style incremental.

Thanks for the advice, everyone. I think I'm going to go ahead and announce it on news.yc (when the app is ready), but with the caveat that half of the intended features are missing. One factor not mentioned in other comments is the fact that I hope to get some hackers interested in co-foundership with the alpha release.

> app would depend heavily on user-generated content

That's causing me to release later. Don't want to do a full launch of a site that has no content yet...

I'd echo what martianpenguin said.

Open it up to a few people (People from news.yc would be a good choice) who can both test it out, and offer constructive criticism on flaws, bugs, whathaveyou.

And then, you can work towards an alpha/beta