Handing out beta invites has become an accepted practice for launching a new web service. Interestingly the user experience you get from signing up for beta invites can differ a lot. Basically there are three things that can happen:
- you sign up - and get an invite immediately: the service is not running a beta program, they are just harvesting email addresses and you fell for it.
- you sign up - and never hear from them again: the service did not launch successfully, with a little bit of tough luck your email address is being sold with the assets of the company
- you sign up - and have to wait some time (more about that later) to finally get your invite. Sometimes it helps to publicly ask for (or beg for) invites to speed up the process.
The question is: why do I get some invites very easily, whereas I have to wait for others weeks or months, and there seems no evidence of successful begging for invites. Example: if you are looking for an invite to
Unblab, an innovative email client for high-traffic communicators, you should prepare for a long wait and you are not alone.
The reason is that product managers are running closed beta programs for two reasons (and there is a third for web services).
Reason number one is to get high-quality feedback from a selected number of users, ideally from users that are in your target group. With a private beta program for a consumer-web service you can get this kind of feedback, because your beta users will be highly engaged, after all they have been selected to see your product before anyone else does, you can ask them questions regarding their demographics and other services they are using, so you can make sure they fit into your market segment (a service that demonstrated this nicely is
Gist, which required me to fill in a 10-page survey before I got the invite) - and as many startups do not have established customer support practices, let alone detailed usage analytics or business intelligence software, it is easier to handle the load of 1.000 selected beta testers than the crowd of people that will sign-up & forget once you hit the Techcrunch start page.
There is an important draw-back to this approach: in reality you will not get a fair representation of your target users with a closed beta program. You will get early adopters who linger around at places like the
friendfeed Invites room to get the first peek at the web service that might become the next big thing, but forget about it if you do not hit their sweet spot (and this is probably not the sweet spot of the target user), you will get your competition's product managers and subsequent feedback that is not representative of your user group. But do not abandon the notion of a closed beta yet, because there is still reason number two.
Reason number two is to build a community and to get people talking about your service. The more people you invite to the service, the more people can potentially talk about it, but on the other hand, the more rare your invites are, the more reason people have to talk about your service, for example by asking for beta invites, by leaking screenshots, by promoting your service (if you tell them that this will increase their chances of getting an invite). Again, we have the problem that this is the early-adopter crowd that will talk about the service at early-adopter places like Twitter and friendfeed, but once you have enough buzz, attention will spill over to tech blogs and you are ready to move up the technology adoption curve. So what is the right amount of invites you should hand out: this chart explains it.
The real question, where is the local maximum depends on the size of your market, the share of early adopters in it, how likely people are to talk about your product. But with proper monitoring of Twitter (and a good, trackable product name) you can easily move along the curve giving out more and more invites until you see that the additional attention you get from giving out an additional invite degrades.
By the way: the third reason to run a closed beta program is a lack of technical scalability. If a service cannot sustain more than 10 concurrent users, you have a very good reason to cap the amount of invites at 1.000 until you have fixed your problems. So the next time you see a service high on the attention scale, but with a little amount of invites circulating, it could be the case that they just have more pressuring issues than putting additional load on their servers to people asking more or less politely on Twitter.
Comments [1]