I’ve been involved with software development for the better part of the last 12 years. In traditional software development, one of the most important milestones is when the product reaches “Beta”. Software teams have many different definitions of what makes a beta– but most agree that the product should be feature complete and ready for wide scale testing. Beta is a stage of development as the team works to ship the final product.
In my opinion, the “beta” designation has lost all of its meaning in the new world of “Web 2.0.” New companies put up a Web 2.0 site, call it beta, and rarely progress beyond the beta designation (heck, even Gmail is still technically in Beta). I think this does a disservice to users who have learned in the past that “beta” is synonymous with “beta testing.” The idea of beta software is that the functionality is *not* ready for primetime, will probably have issues or bugs, and that users should proceed with caution.
So, why isn’t “MyPunchbowl” a beta? (note: no “beta” in our logo!). Well here is the deal: rather than call it beta and try to get as many users as fast as possible, we decided to take a different approach. Our approach is a measured, steady progression that gives us the best ability to respond quickly to our users without being overwhelmed by traffic. Our goal is that we want 100% of our new customers to have a successful experience with MyPunchbowl. To do this, we are taking a different approach. An approach that I like to call a “Managed Rollout.”
So what is different about a managed rollout? Well for starters, it means that we want to rollout the product to a manageable number of users at a measured pace. We want to have 1:1 contact with our users to really understand what they like and what can be improved. We want to find the critical bugs and fix them quickly, and we want to make sure we have the flexibility to make the kinds of changes that aren’t possible when you have thousands of users. So far our strategy seems to be working: in the first few days, we were able to rapidly fix some issues that came up with our initial users and we were able to make some changes that will improve usability.
Our “managed rollout” means that we are not going to spam everyone we know asking them to sign up today. Instead, we will try to steadily increase the number of users as we gain more confidence about our app. We’ll get the marketing and support pieces in place in parallel, and we’ll add more app functionality to delight our existing users. Most importantly, we’ll increase the chances that every user has a great experience the first time they use MyPunchbowl.
By traditional software definitions, what you see on http://www.mypunchbowl.com is not a Beta. The product has been spec’d, implemented, tested, tweaked, refined, and tested again. Yes, it’s a limited set of functionality, but we believe it is ready to be used in the “real world.” Unlike a beta, it’s a new application that would be called “1.0” in traditional software terms.
The more I learn about web development best practices, the more I am convinced that the old rules do still apply. You still need good specs, you still need user feedback, you still need multiple rounds of refinement and testing. So let’s define “MyPunchbowl” for what it is: a limited set of functionality that is “shipping” quality code. Our managed rollout enables us to do something that the meaningless Web 2.0 “beta” label cannot– it allows us to clearly communicate to our new users that the product is ready for real use. After all, isn’t that what users want?
So go ahead other Web 2.0 sites– call it “beta.” We think we have a better strategy– manage the rollout and increase users steadily as we add more features. That is, unless we get Techcrunched, Slashdotted, or Reddited too soon.