

Should I open up alpha or wait until full(er)-featured beta? - ph0rque

I am the solo (so far) founder of a startup; working on a web app that is very nearly ready for people to play around with. However, it still lacks some features that would make it complete on a minimal level. Should I announce it once the alpha is complete, or wait until I write the features that are still lacking?<p><i>Update:</i> By lacking features, I mean those that would fundamentally change they way the app would be used, once they're written. Also, the app would depend heavily on user-generated content; this makes me think I should release earlier rather than later.
======
ardit33
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.

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

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

------
aykall
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!

------
sah
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.

------
huhtenberg
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.

~~~
joel_liu
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.

------
Frocer
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.

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

------
cperciva
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.

------
nostrademons
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.

------
OpenWebU
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.

------
Flemlord
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.

------
axod
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.

------
ph0rque
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.

------
tim2
> 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...

------
ajkirwin
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

