Image may be NSFW.
Clik here to view.
If my experience is anything to go by, beta programs are often run by companies because they HAVE to be run. I completely disagree with this philosophy. The more you can get actual users to test out the product and the more feedback that you can get, the greater the chances that your product will succeed in the marketplace. I have often been asked about whether a beta program exposes too much functionality and takes away the surprise element from the launch. However, I often ask the question – isn’t it great that people start talking about your product before it is launched and build up anticipation about what is going to hit the market?
Sure, you may not want to expose everything to your beta users – such as a surprising element in the interface or one or two bits of functionality that you absolutely know will be a success. But besides that, in my own experience, the more you let your beta users test out your product, the better off that you will be.
Alright, enough ranting. If you are ever asked to run a beta program, you need to make sure that you do it well. Here are a few tips that I have learned about successful beta programs:
- Plan well: Usually, beta programs are just one of the many activities in a product launch plan. While a beta program is an element of your launch plan, it deserves its own project plan. I usually draw up a separate project plan which helps me track the program and ensure its success. This definitely means that there is a need for more time and commitment from you. But hey, if you want the rewards, you’ve got to invest the time. No pain, no gain, remember? Remember to think through the risks, possible issues, and contingency plans needed to handle unpleasant situations – such as handling vitriolic feedback or an uproar related to a change to an existing feature. You can never be too prepared.
- Get the much needed sponsorship: Your boss and the powers that be need to bless your beta program. Remember, even though this is your product, they are responsible for the department and for the company. Make sure that you have their buy-in for each of your plans and that you have spoken to them about all the risks and possible issues and have discussed the contingency plans in place.
- Choose the beta participants wisely: You want to make sure that your beta participants actually test the new features and provide you with much needed feedback. If you have very competitive features that you want to keep under the wraps till when the product is finally launched, you will want to enforce a non-disclosure agreement (NDA). Make sure that the beta participants understand the concept of an NDA and will respect the terms of such an agreement. You don’t want your secrets leaked on blogs or twitter by an overzealous participant. Neither do you want a participant who will not test your product and just turn in an “A-okay” at the end of the testing period
- 4. Decide the extent of interaction between testers: Sometimes, when beta testers talk to one another, it ends up in productive discussions. Most times, it leads to chaos. Despite the fact that encouraging people to talk to one another about their experiences is helpful, I have found it to have created a lot more noise, a dilution in the sense of ownership, and therefore lowered productivity. However, enabling interaction does sometimes get out different perspectives to a single problem and allows for gamification ideas as incentives. However, if you decide to allow interaction between beta testers, I would say, do so at your own risk.
- 5. Get the right timing: Plan the beta program when your quality assurance (QA) team has gone through the complete functionality once and is some way through regression testing. You don’t want a buggy version of your product out there for a beta. Remember, your beta testers are customers and therefore, your product still needs to be in great shape when it reaches them. Do not make the mistake of thinking of them as extensions of your QA team. At the same time, leave some time for your development team to fix all the issues that the beta program may uncover. Don’t announce a beta program a few weeks before the actual launch date. Give yourself and your company enough time. At the same time, don’t wait too long after a beta to release the new product. People don’t keep secrets too long. And once they’ve seen what you have on offer, they’re going to want to have the new features as soon as possible. In my own experience, a beta program about two to three months before a major release, works really well.
- 6. Not too long, not too short: Beta testers have full time jobs. They’re actually doing you a favor testing your product for you. That’s right – never mind if they’re getting to preview a really cool piece of technology, participate in a draw, or win a discount that you’ve built in for beta participants – they are still doing you a big favor. So, keep the program short enough to see that they are pressurized to test and long enough so that they can give you enough feedback. A month long beta program, in my opinion, is ideal for most enterprise class products. You can choose to make an upgrade / provide a fix pack mid way – this shows your participants that you are responsive and are willing to listen.
- 7. Incentivize: As mentioned in the previous point, remember, these guys need an incentive beyond just getting access to your new features early. So, make sure you make your beta testers feel special. Market to them using emails which let them know that they are special. Personalize the email when you send it out – use a tool like Marketo or Eloqua that helps you send individual personalized emails. You can have a discount for beta testers, or a recognition program, a lucky draw for the person providing the best feedback. Sometimes, you also need a bitter medicine. Beta testers tend to offer a lot more feedback if they know that they may not be invited the next time round if they don’t participate.
- 8. Set processes for feedback: Ensure that your beta participants have an easy way to submit feedback to you and receive responses and clarifications quickly and efficiently. Remember, you may need screen shots, information about environments, and many other such pieces of information to even reproduce a bug that they have reported. So, remember that a few of your technical wizards and architects are closely involved and can help respond, ask questions, and keep people engaged. Also see that you have the infrastructure by which they can send files, screenshots, as well as text feedback to you. Good communication and the ease of such communication will make or break your program
- 9. Get your house in order: Before you kick off the program, make sure that your team, infrastructure, and product are reasonably ready. You do not want structural issues at your side to take away from the effectiveness of the program. Make sure your key technical people, your marketing department, your infrastructure, your legal team, and your processes are all set. And yes, you don’t want to be sick and out of action. So, take your Vitamin-C!
- 10. Follow up, Follow up: Remember to follow up with both your development team and with beta testers to make sure that the communication is flowing both ways. Both sides will usually begin with a lot of enthusiasm, but all the zing will fizzle out soon enough. You will need to ensure that you keep them engaged, excited, and interested. Follow up with emails, by jumping into a few discussions yourself as the facilitator of the discussion, and by giving contributors recognition to give you more feedback.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
