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
I tend to agree with the advice but only for well funded startups who can afford to wait and test and retest.
First impressions are overrated. Who gets it right the first time? A regular improvement of the product/service, based on user feedback, is worth more in my opinion.
For bootstrap ventures, launch as soon as you can. Anything. The feedback is priceless.
People who look for flaws always find them. I think there are about 170 million Internet users now in the US. If you have a useful product/service, it make take some time, but you’ll get users. Just don’t run out cash.
There’s a better way not to blow your beta: don’t launch one at all. Public betas are rediculous. If your product is public, it’s not a beta, it’s a release. Take responsibility for your product. “Beta” only passes the buck to your customers — outsourcing your pain to them.
Get over Beta already.
Totally agree on the Mac OSX and FireFox issue. They’re all early adopters. They’re also connectors meaning all their friends look up to them for advice.
If you can impress an OSX or FireFox user by proxy you’re impressing 10-20 of their friends.
Factor it this way. IE might have 80% of the market but every FireFox/OSX user counts for 20 regular users.
Kevin
Great post. I think we hit all of them with Newsvine pretty well except maybe the “tell users what it is on the landing page” part… but then again, I posted a lot of info about that on my own blog so maybe that helps make up for it.
One note about Jason’s suggestion about not doing public betas at all: Ours is a private beta so we don’t fit into the category, but let me just say that betas (at least private ones) offer a lot of very important safeguards that the 37s team might not be worried about due to the nature of their products. 37s creates very simple things. Very good, very simple things. I’m not even saying they are simple on the inside, but the team does a great job of intentionally limiting what you can do with their products. This also limits what can break. The products are also generally aimed at web heads so that limits the potential audience as well. These are all *good* things and part of the 37s mantra. However, it also means they might not need the amount of testing (even public testing) that other products and services might need.
If you aren’t confident that the world beating down your door on day one won’t tip you over, that doesn’t mean your product is bad or that you’ve done anything wrong. It’s just part of erring on the side of caution. Too much caution equals never launching. Too little caution equals multiple technological failures. Somewhere in the middle is where it’s at… and this post sums that up well.
Hey Mike, perhaps for your next post you could do a quick roundup of the betas of 2005 and judge them on how they succeeded or failed as betas (setting aside the eventual success of the overall product)? Case studies like that would be ace.
I agree that Betas can be an invaluable tool to completing a product. I say completing a product intentionally. Betas, in my opinion of course, should be used the find the bugs, errors, or functionality that all of the developers hard work just missed. I think the beta released version of an application should have at least 98% of the functionality and bugs worked out, with that last 2% being found by no other way than beta-testers. Plus there’s no better way to judge how the software / hardware integration will hold up under regular usage than by having regular users use it.
Great Article Michael! Defined something all of us where thinking about.
-Rob
While not having your product ready to support all browsers is the quickest way to marginalise your offering and to piss people off, the other aspect is that by making your offering US-centric you are cutting out more market than what you are by only supporting IE. The ~180M net users in the USA are only a small part of the pie, in the rest of the world (Europe, Asia etc.) people are just as excited about Web 2.0 but almost feel left out as their regional requirements are not taken into account (language, currency, Unicode etc.).
Build for everyone on the web, not just the different client platforms but for different geographic areas as well.
The reason we went Beta with Omnidrive is because having a user feedback loop during development is the best way to create a product that people will want.. if we went straight to public there would have been a very high chance that we missed some opportunities that have come up and we would have lost all that early adopter interest. Being Beta means being agile. Jason I would like to hear about how 37S specs their products and how you know if you are building something for the masses, or just something that the 5/6 of you think is cool.
Good write-up Mike
What do you guys think of Riya’s beta? My feeling is that they kind of left a big chunk of their alpha testing base hanging when their software does not work at all on many systems…The site is great, but the client obviously very badly tested. yeh, it is beta, but i think most expected it work
I think he’s right on with first impressions. If the site is crap, I have a negative impression that lingers, and I never go back. For example Snapfish might be okay now but I remember when it was awful, so I don’t even consider it.
So the question is whether the feedback you get on your sucky site is worth more than the x number of people you lose from showing your sucky site to. There are enough people out there that maybe you can afford to lose a lot of geeks right up front… Snapfish doesn’t seem to be missing me!
Also… when I read the subject “Don’t blow your beta” I just figured it was another post about social porn.
Freudian Slip 2.0
Landing Pages
Still waiting to hear more about edgio. What is it? Will I ever get an email? How is it pronounced?
Well funded startups can’t wait. Really. There’s no option *but* to go out with the beta and get user feedback as early as possible.
Great post, but I think you missed another critical point - large companies should be following many of these rules too.
Oh my gosh…and I thought that a novel idea…a wonderful idea…a great idea…is what made products attractive and successful. I agree with “Startups can’t wait”…but there are a lot of “lessly” funded products OUT THERE that have the opportunity in this “free” market to make something happen. And guess what? They don’t have to come from the Siilcon Valley!
Michael, you’re too early to make these judgments in a Web 2.0 market that is still in its infancy!
Bob - Hey, I don’t make those judgments. Honestly. The readers of this blog do and I see it in the comments all the time.
“Jason I would like to hear about how 37S specs their products and how you know if you are building something for the masses”
We build products for ourselves and then turn them into products. We’re not special or unique — if we need it, hundreds of thousands of other small businesses need it too. If we miss something, we can always add it later if we think it’s necessary.
We never ever release “betas” to the public. When we release, we release version 1. We take full responsibility for ay bugs we have, any performance issues we have, anything we’ve missed, etc. That’s our role as the people who sell the product. Releasing something to the public at large as a beta only says to them “don’t trust this yet.” We don’t think that’s a fair burden to place on the public at large.
Private beta, sure. Public beta, never. It’s a trend that has to end.
Again, you have to agree with the Firefox and Safari comment. But you also have to think about OS support, I think Google is generating a lot of frustration amongst the early adopters by releasing products that don’t run under Linux or on a Mac. You only have to look at the hysteria surrounding the recent leak of a pre-alpha of Google Earth for Mac OS X to know there is a lot of pent up demand there…
Re: Landing pages: “Another complaint is that the landing page doesn’t give clear information on what the product will do.”
I had to chuckle at this one because not 10 minutes before reading your post I followed a link to a landing page for something called “Ookles.” It’s a start-up of some sort from Scott Johnson of Feedster. Of what sort? I don’t know, ’cause the landing page is completely uninformative. I realize this is hardly a “beta,” and I’m sure 45 seconds with Google would solve the mystery for me if I cared. But still, it seems odd to go to the trouble of creating a landing page (kinda nice looking one, at that) and say absolutely nada about what you’re doing. I mean, just a sentence or two would suffice.
Michael - Yeah, well we made the same mistake with our edgeio landing page. Live and learn.
Landing page is useful, if only to get the website indexed by Google.
Also, for companies skipping beta, the above pointers work too, as in don’t blow your introduction.
I will doublecheck this post when I launch my Web 2.0 apps shortly.
Thanks Michael.
Once again you have produced valuable and well written advice. Much appreciated.
-Thomas
Very useful and very well said!
It’s amazing to me that all these landing pages don’t have a giant RSS feed button instead of a giant textbox to enter your email address. How web 1.0. Really, I don’t want to give you my email address, but I do want to hear your pre-launch hint dropping, launch notice, post-launch service status and upgrades. In my feed reader it’s information, in my mailbox it’s spam.
re: landing pages
at least write back that you received my email address, suckers. if you don’t value my email address, i won’t value your “product”.
Very interesting post, i have definitely made mistakes while launching my site. I think next time I will launch a private beta and then launch the full thing when it is ready, the only problem is attracting enough users to make the private beta worthwhile.
I agree with a lot of this - but as an early commenter pointed out, if you are bootstrapping you probably can’t afford the luxury of waiting to deploy.
In my experience user feedback has been extremely valuable and I wouldn’t have tried to second guess it if I had another chance.
Great post.
Michael, you’re missing the point. Successful companies are based on reaching people who are in pain and making their lives better.
So find some people who are suffering needlessly, come up with a brilliant way to (a) cheaply reach a lot of them and (b) cheaply make their week a little easier.
Then execute your plan. That’s a business. Forget about Betas, Web 2.0, yellow fade, eyeballs, alexa and all that. It’s a distraction. The point is to make money.
Michael, you didn’t have a beta or “features” or any of this for WebCrunch, which I’m sure is paying nicely at this point. You saw a crowd of loaded entrepreneurs and VCS who were looking for hot tips, and you started dishing. Now you’ve got buzz and a hot brand. Nicely done. You’re successful because you are in touch with real people, and this was made a lot easier to do because you picked a very narrow set of them and chose a very simple message. We should all follow your actions, but your advice is half-baked.
if you are bootstrapping you probably can’t afford the luxury of waiting to deploy.
Maybe smarter boostrapping is in order. The customer only cares about their end result of using the service. If it sucks then it wouldn’t help the situation if you explain to them you had to release an early version because you were bootstrapping it.
Great post Michael. Some solid advice and there are some great comments here as well. We’re actually going to be implementing some of the commenters suggestions over at Ookles so thanks to everyone!
I’ve recently written up a post explaining how we approached our sign-up page on the Ookles Blog (Sorry for no link but I don’t agree with linking in the comments of other people’s posts).
Michael’s point is well taken as it regards Web 2.0 early adopters … Clearly, nothing beats a slick and functional UI to draw users into your unique feature sets … Though, we also observe in our former experience that less-than-pretty prototypes that were slapped together in order to prove a concept have resulted in businesses that now count their 10s and 100s of millions in annual revenue by the minute. Now less-than-pretty server side engineering is much different than less-than-pretty user experience — and that, I presume, is the heart of Michael’s point …
I think that in many cases, on-line “open” betas are really just an excuse for launching services before they’re ready.
I think that in many cases, on-line “open” betas are really just an excuse for launching services before they’re ready.
I couldn’t e-mail either!
I couldn’t agree with you more on the landing page issue. Which is why I suggest making a landing page viral; begin the word of mouth early on by actually offering something to your potential users on your landing page. If it’s cool/fun/interesting, and has something to do with what you’re going to offer, they’ll talk about it.
Hope this helps someone: On Building A Viral Landing Page
I really agree with the first impression thing. For myself, once I experience a badly designed site, I will never be back to check whether it’s improved or not. This is the issue we should remember, never publish the site with a lot of bugs.
Good information, thank you. By the way: This is a really impressive website-layout. Clean code and accosting Design.
Launching a new service and guerilla PR
A very good post, succintly summarising the key points. I’d agree with the point about incomplete features - the recent Blogger version is testament to this. They didn’t have a fully functioning product with all the ‘drag and drop’ widgets until right at the last moment. I think on reflection Google could have done more development behind closed doors before releasing the new Blogger to the public.
Hi! Nice site!