Beta programs are a real challenge. You build your product. You make multiple iterations of your widget. Now you need people to test it for you. Well, actually, you need to find people intent on breaking the darned thing and then showing you how they did it. Repeatedly.
We all like to watch train wrecks, right? So why is it such a challenge to run successful beta programs?
One of the biggest problems behind any beta program (pre-release testing evaluations of your product), is getting enough knowledgeable people to do the testing for you and to provide constructive feedback. You may need to invite 5 times the number of people you might expect.
Why? Because people tend to drift off, agree to participate but never do or simply download the upcoming version for an advance peek and then never do anything with it. If you’ve never run a beta program, expect this, live it and appreciate that when you do find that rare beta tester that gives you good feedback, you better take care of them.
Here’s the crux of the problem: The majority of beta programs (all, that I’ve been engaged with) involve no direct payment. The tester is someone who thinks enough of your product–for whatever reason–to voluntarily contribute their time and energy. They want you to get your product right.
In many cases, the beta tester benefits because the next version of your product, which they’re almost certain to obtain, will have tweaks meeting their specific needs. If you get the product right, the features they saw fit to test–of importance to them–are more likely to work as desired.
Who gains the most? Almost always it is you, the vendor. The beta tester bears risk: evaluation may require using the ‘test’ product in a production environment. If it doesn’t work (well enough), they may need to completely restart. Frequently, file formats change during development so any work they do, even when successful, cannot be carried forward. As the vendor, you receive feedback on usability, error reports and ways to improve the product.
What did you risk? Almost nothing. What did you gain? Feedback crucial to your success!
I am filled with dismay when I encounter discussions suggesting–strongly–that beta participants pay for the opportunity to be in your beta program. Huh? They carry the risk; they put in the lion’s share of the effort; they’re helping you benefit; and, they should pay for this grand opportunity?
There are a couple common thoughts behind the ‘pay to do beta’ philosophy.
Perhaps most key is that participants are something of an X Factor. They may sign up, but not show up. They may take your precious product for a spin, for free, and give nothing in return. They have no skin in the game.
By requiring beta testers to pay to participate, the idea is that they now have skin in the game. They are more likely to participate and contribute effectively. (Of course, for the reasons I’ve already noted, I think active participants have plenty of skin in the game.)
The second notion behind a pay-to-play-beta is to use your beta program as an opportunity to develop new customers. If they pay, they’re already somewhat hooked and more likely to convert (even at discount) to the full product once released.
That just might work if your ‘beta’ product is incredibly solid akin to a Google ‘beta.’ Of course, there’s debate over just how much of a ‘beta’ a Google beta is. (Even so, you don’t pay for Google’s betas.)
Thoughts on requiring beta participants to pay-to-play is best summed up by my friend Shaan Hurley. Shaan ran a major software firm’s beta programs for years. As he puts it, “If you charge for a beta, it is not a beta but an early crappy product for sale.” I couldn’t agree more.
Should participants have to pay to be in a beta program? Share your thoughts. I’d appreciate reading them.
(Image credit: Carlos Paes)
