January 9, 2006

Don’t Blow Your Beta

Michael Arrington

88 comments »

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

  • Sphere It

Trackbacks/Pings (Trackback URL)

  1. WeBreakStuff » Web applications: Being Beta
  2. super hanc petram » links for 2006-01-09
  3. boca do cenoura » Blog Archive » Don’t Blow Your Beta
  4. Space & Beyond » Betta not be a Beta
  5. Marketing Begins At Home
  6. Deaglan on WordPress » Perpetual beta and co-creation
  7. Nothing But Net » links for 2006-01-10
  8. Edwyn Chan's Weblog : web 2.0 | blog media | china
  9. ExtraEight » How to release web applications
  10. Vy Blog
  11. Ajaxian
  12. Startup Fever
  13. Michael @ Zingee
  14. E-pire’s blog » Web Betas
  15. Computerworld Blogs
  16. Macro Linz » links for 2006-01-11
  17. No Soap, Radio!
  18. TECHNOSIGHT » Opportunities 2006 - Usability
  19. ConsumerEmpowerment.com » Empowerment all over…
  20. Bubbling Up — qwerky Archive
  21. Ookles Blog » Beta Explained
  22. Xesume’s Blog » Blog Archive » Startup and Beta Release 101
  23. Omer Khan’s BLOG » Blog Archive » Google Video Store is Live
  24. SillyDomainName.com » The difference between Web 2.0 and Web 2.0
  25. Actics Blog » Blog Archive » Life in a startup
  26. The Development » The Beta Program
  27. 59 Ideas » Blog Archive » Release Fast, Release Often, Perpetually Beta
  28. 59ideas | Idea in a weekend
  29. QYPE*Vibes » Blog Archive » Lampenfieber…
  30. Un lugar en el mundo… » Blog Archive » Lo mejor de la semana (y III)
  31. Planblog » Blog Archive » Qype beta
  32. Gnomedia » Web 2.0 mai are un autor…
  33. Oxyfish » Blog Archive » First Impressions vs Getting Feedback
  34. The Beta Program at AmihaiCohen.com
  35. Jac Wright » Writing (Beta)
  36. A Group / Apart » Archive » On Building A Viral Landing Page
  37. Opskriften på en god beta · omFlash();
  38. RMX Direct » A Series of Posts on Developing Web Applications
  39. Ajaxian » The Importance of a Good Beta
  40. The Beta Program « Amihai’s Untitled Journal
  41. Kristaps Kaupe
  42. meish dot org » links for 2006-01-11
  43. Second Brain - Organize Everything in Your Personal Internet Library
  44. Favorit i repris: "Schabbla inte bort din beta" [Det handlar om fibrer, Fleecelabs]
  45. Kristaps Kaupe
  46. The dot com dream... « Rudimentary Art of Programming & Development
  47. e633d3f806d76c47ac4ddbcc6c476004
  48. gioca a poker on line

Comments

RSS feed for comments on this post.

  1. Jeff

    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.

  2. Jason Fried

    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.

  3. Kevin Burton

    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

  4. Mike D.

    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.

  5. Paul Montgomery

    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.

  6. BEWB

    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.

  7. Robert Sandie

    Great Article Michael! Defined something all of us where thinking about.

    -Rob

  8. Nik Cubrilovic

    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

  9. Steve Ng

    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

  10. sizer

    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!

  11. Kevin Burton

    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

  12. Sean

    Landing Pages

    Still waiting to hear more about edgio. What is it? Will I ever get an email? How is it pronounced?

  13. Startups can't wait

    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.

  14. Kevin Carey

    Great post, but I think you missed another critical point - large companies should be following many of these rules too.

  15. Bob

    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!

  16. Michael Arrington

    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.

  17. Jason Fried

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

  18. Alasdair Allan

    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…

  19. Michael M.

    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.

  20. Michael Arrington

    Michael - Yeah, well we made the same mistake with our edgeio landing page. Live and learn.

  21. Jie Kang

    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. :-)

  22. Tom

    Thanks Michael.

    Once again you have produced valuable and well written advice. Much appreciated.

    -Thomas

  23. Ivan Minic

    Very useful and very well said!

  24. James Prudente

    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.

  25. dusoft

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

  26. Tom

    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.

  27. David

    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.

  28. Chris M.

    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.

  29. Rob Poitras

    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.

  30. Michael Air of Ookles

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

  31. Sunjay

    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 …

  32. Sheyla

    I think that in many cases, on-line “open” betas are really just an excuse for launching services before they’re ready.

  33. anal

    I think that in many cases, on-line “open” betas are really just an excuse for launching services before they’re ready.

  34. Johnny

    I couldn’t e-mail either!

  35. Cliff Spence

    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

  36. Yufeng

    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.

  37. Milos

    Good information, thank you. By the way: This is a really impressive website-layout. Clean code and accosting Design.

  38. lineage2

    Launching a new service and guerilla PR

  39. Karaoke Kev

    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.

  40. Betty

    Hi! Nice site!