As someone who signs up for almost every BETA under the sun, I’ve seen five best practices emerge that seem to keep me engaged throughout the process. Since I’m a Marketing person, I look at this from a product manager / outbound communication perspective. There are a LOT of things that should be done internally with engineering and support during this process to make your BETA cycles effective.
Internet BETAs have reshaped what BETA means. Traditionally, by definition, BETA meant a closed, invite only perfecting cycle before release. Well, in the web world of today, we now have private BETAs, public BETAs, and always BETAs. Always BETAs (and likely public BETAs) should really simply be released services, not some CYA low-quality service excuse (e.g., Gmail). Anyway, if you’re in either of the first two types, you should add these five things to you BETA project plan.
Email Registered / Interested Users
The communication coordination for most BETA launches is horrible. The product / marketing guy typically misses the email announcement boat by a couple days. I typically hear about a BETA launch via a blog a day or more before I get an announcement email. This doesn’t reflect well on your company or your service. Make sure that you send an announcement email before or shortly after you’ve pitched the bloggers. If you’re doing waves of invites, you should still let anyone who was originally interested in your service that you’ve started sending out BETA invites.
Re-Introduce the User to Your Service
A lot of BETA invites / announcements I receive really don’t tell me much about what it is the service does. And, that doesn’t mean you say, ‘it’s a social network that works where you are.’ Remind me what I can actually do with your service (i.e., what problem is this going to help me solve again?). This re-introduction should occur in both the email and as a splash page / getting started section on the website. Otherwise, most users can’t remember what you do, why they signed up 4 months ago, and why they should consider giving you feedback. (Remember: the goal of BETA is go get great user feedback).
Invite Active Users to BETA User Groups
A lot of the early adopters (digirati-types) are not representative of your target market. That’s the market that will actually make you money in the medium-run. Yes, they’re the gatekeepers so you have to make them happy (e.g., make firefox and safari usable), but try not to spend valuable cycles on integrating with the latest / newly launched service. You should try to identify semi to active users who you believe represent your target market. Invite those users into a special BETA group. Then incentivize them to work with you to provide detailed feedback or to act as a sounding board.
Make Social Features Available for Viral / Word of Mouth
Everything on the web is becoming social. Your BETA process should account for this and make certain that your social features are implemented in a way that allows users to invite friends. Invites should be limited (5 per person) to manage growth and scaling problems. But, this will ensure that users get the full use of the site with the people they interact with most – friends. This will greatly increase engagement and frequency, which ultimately improves BETA feedback.
Open Feedback Channels
Make sure that you have a well-defined user feedback / support process prior to public or always betas. For private betas, you must make sure that the entry point for this process is well-defined and ideally a sorting and bucketing function exists so you can get prioritized feedback to engineering for your next iteration. The more open and transparent the feedback process is the better your users will feel about providing good feedback. No one likes sending well thought-out information into the blackhole of a company.