I’ve seen hundreds of new products launch over the last six months, and I think I have some pretty good advice for companies that want to improve their beta release.
In addition to my personal experiences with companies, I recently wrote “What Annoys You Most About Betas?” on Crunchnotes to help me prepare for this post. The comments to that post give a lot of direct feedback from early adopters and much of that information is reflected here as well.
Every company does things a little differently. Some rush the product out, features-be-damned. Others wait, and wait, and wait, until its “perfect”. Some companies are secretive. Others open. And so on.
Certainly there is no set recipe for success (or failure). But there are a number of easy-to-avoid traps when building and presenting a product. Likewise, there are a number of “crowd pleaser” features that always get positive comments.
First Impressions
The main thing to remember is that you generally only get one look from the early adopter crowd. There is just too much going on for them to give a flawed company multiple chances to get it right. You either grab their attention, or you lose their attention. If you grab ’em, everything is easier from then on. If you bore them, you are facing an incredible uphill battle just to get them back to the site. So, basically, don’t blow your first impression.
Once they’ve made the decision that you are not noteworthy, it is very hard to get them to pay attention again.
Rolling Feature Release
Somewhere along the line people got the idea that rolling out functionality in stages is a good thing. There are two arguments for this.
First, it allows an earlier launch. Ok. That’s true.
The second argument is that by releasing features in stages, you’ll have regular news that bloggers and other journalists can talk about. This is also true, but a lot of companies get a little too religious about this and start to pull features just so that they will have news down the road. I hear this all the time from companies – “please don’t write about this feature yet. we want to release it next month and get you to write about us again then.”
If your first impression is positive, people will want to hear about future news. If it isn’t, people won’t care. Focus on making that launch a memorable one.
Every new feature is not news.
Incomplete Features
Some people take the “rolling feature release” idea above to mean they can release half-baked stuff. This allows for a quicker launch, of course. Slap a label on it, like “developer release”, “alpha” or “beta” and the hope is that people will be understanding and kind, and give you good advice and suggestions for improvement and evolution.
This is a bad idea. You will be crucified for wasting people’s time and they will leave brutal comments slamming your product. It is far better to delay launch, or remove the feature entirely, than show stuff that doesn’t work.
This is a “fall on your sword” issue. If the team is pressing to do this, spend political capital in fighting it. Your equity will be worth more because of it.
Pre-launch labels do not protect you from scorn.
The Browser Issue
Internet Explorer has dominant market share, and (at least today) you must work on IE to get mass consumer adoption.
However, most of the early adopters use Firefox, and a lot of them use Macs. At one point, 80% of TechCrunch readers used the Firefox or Safari browsers.
If you don’t support Firefox and, to a lesser extent, Safari, when you launch, you are going to be shunned by the early adopters.
Landing Pages
Many companies put up a basic landing page while they are in development. These landing pages usually ask for people’s email address, promising notification when the product launches.
I personally like landing pages because it gives me something to point to when writing about a pre-release product. But many users don’t like them. A common complaint from people is that they sign up on a landing page and don’t hear anything for months (so they forget all about it). Another complaint is that the landing page doesn’t give clear information on what the product will do.
If you are going to do it, make sure that launch is imminent and that you give fairly detailed information on the product vision.
Bloggers and Blogging
Most early adopters read blogs. A lot of them write blogs, too. Engage with bloggers.
They are a powerful way to spread your vision, and they are generally much more technically adept than the average big publication journalist. They don’t have to deal with editors and fact checkers (for better or worse), and so it is often easier to get your pure vision out there for the world to read.
You should also publish a blog. Not only is it the best way to tell the world about what you are doing, it also gives you the opportunity to repay bloggers who write about you with a link back to them. Don’t underestimate the importance to a blogger of being linked to on your blog. Just like you, bloggers want mind share.
Never, never, never attack your critics on your blog or in comments on other blogs. Engage with them and be constructive even if they are not. Even if they are dead wrong, thousands of other people probably have had the same thought and haven’t bothered to write about it. Don’t assume they are a jerk; rather, assume that your communications are flawed and need to be re-thought. You are going to have to develop a very thick skin.
Obvious Trust Issues
Don’t ask for more personal information from your users than you absolutely need. Yes, having good demographic information on your users, like zip code and birth date, is a valuable asset. But many people won’t sign up for services that are asking for more information than absolutely necessary, or will purposefully enter false information.
Don’t break people’s trust during the registration process. Be like Netvibes if you can and offer a near-complete service without registration at all.
Summary
My guess is that there will be even more useful suggestions given directly by users in the comments to this post. These comments are even more important than what I write, so you should listen carefully to this feedback.
There are a number of recent posts by others that will be at least indirectly useful to companies launching betas as well. I highly recommend reading these:
Stephen Bryant: 2006: First Thing We Do, Let’s Kill All the Betas
Adam Green: The danger of beta burnout
Fred Oliveira: Fewer templates, more user experience (good advice on design and usability)
Rob Hof: Best Way to Post Video Clips to Share Publicly? (an example of a lost opportunity)
Razvan Antonescu: Launching a new service and guerilla PR – Part 1, Part 2