Why beta programs are alpha
by Rosie Odsey, Dec 20, 2017
I’m sure you’re well aware of Codebots’ beta program by now. But in case you’ve been offline for the last 4 months, let me give you a run down.
A beta program is early access to a new product/platform. The main objective of a beta program is to gather broad customer feedback before a product is publicly released in the market. It’s a quid pro quo between the beta user and the software company. In exchange for early access to an awesome platform, you’ll help us improve and refine it for our public launch.
Where did it come from?
The terms can be traced back to IBM in the 1960s. They used “alpha” and “beta” to label product development checkpoints. Testing product ideas or theories was referred to as A (alpha) testing. Testing feature complete products was considered B (beta) testing. These terms were swiftly embraced by many other companies, considering IBM’s reputation as a world leader in business processes.
The most obvious advantage is that you’re able to gain valuable insights from early adopters. These learnings allow you to make improvements to the software before public release.
A by-product of a successful beta program is the hype and interest it can generate. Firstly, the beta users themselves spread the word that they’re the first to use this awesome new software. Secondly, the early release generates hype months before public release.
It doesn’t take long before a user decides whether or not they like your software. Their first impression will often determine whether they continue using the software. So the stakes are high. A successful onboarding process ensures the users first experience with the software is pleasant. But that means you need to know what users will first want to do, what they need to know and how you can best teach them. When running your beta program you can test different onboarding processes to determine what works best. Codebots will be running a series of workshops to educate our beta users. From those workshops we can draw learnings and refine our onboarding process prior to public launch.
It may be hard to get users to sign up to your beta program. A beta involves people investing their valuable time in unreleased (and possible buggy) software. Fortunately this isn’t the case for the Codebots beta with over 200 signups in one weekend alone.
It’s important to separate your beta program from your UATs. A beta test should not be used as a substitute for conducting adequate testing. If the only feedback you receive from your beta users relates to bugs/broken functionality in the software, there is no opportunity to focus on other, business critical improvements.
During your beta program you’ll need to move fast. There’s only a certain amount of time before the program finishes, so make the most of it.
Before you commence, there are a number of logistical considerations to address. Firstly, what is the profile of the ideal participants you want in the beta? Every product has a target market, so the beta users need to reflect the target market. Obviously there’s no point flooding your beta program with tech savvy developers if your target market is laypeople.
Other considerations include the total number of beta users and the duration of the program. As tempting as it may be, don’t overload on beta users. You want to spend your time valuably, not running around managing hundreds of beta users.
In case it hasn’t been mentioned enough, the Codebots beta program is launching soon. You can apply to be a beta user here. Hurry though, there’s not much time left!