You’re probably thinking that the purpose of your beta is pretty obvious: to work out the bugs, and in the process of proving the technology works, maybe even scoop up some key prospects who will invest in your solution later (or at least serve as references for you to use later when you sign up new customers).
At least that way you can put a few sexy looking logos on the homepage before you launch.
Because of this rationale, you tend to under price and undervalue your software. Most software companies heavily discount their beta software. After all, how can you charge top dollar for software that isn’t even finished yet? Therefore, you are likely to heavily discount, or even give away, your beta software to the first few dreamy logos that will use it.
Not only does this set an initial low expectation of value in the beta participant’s mind, it also sets it in your mind. Beyond these two showstoppers, however, are even more issues on why this beta approach is fraught with nasty surprises and disappointments.
“Before a great vision can become reality there may be
difficulty. Before a person begins a great endeavor, they may encounter chaos. As a new plant breaks the ground with great difficulty, foreshadowing the huge tree, so must we sometimes push against difficulty in bringing forth our dreams.”
– CHAOS – Where Great Dreams Begin (I-Ching Hexagram #3)
The Rock Bottom Brewery
It’s so very easy to undervalue what you’ve created and fall into the trap that the beta participants are doing you a huge favor by gracing your software with their presence.
I fell into this trap on my first entrepreneurial gig, creating an enterprise software solution in the construction industry. When my business partner and I first had our solution in the hands of some key prospects, we thought we had it made, dreamy logos and all.
We flushed out some bugs of course, as well as some look/feel enhancements, but we had also generated a list of feature requests a mile long – and we weren’t anywhere closer to generating revenue with these companies. It seemed like we were going to need an army of programmers, along with many months, to get these beta participants to become paying customers. I was dismayed to see my dream of becoming a software company turn into the idea of running a custom development shop, where you think you’re going to get paid when you finish, but you really have no guarantee.
We decided to do something different, mostly out of necessity. We didn’t have the budget for any more development because it was coming out of my pocket and my partner’s pocket in the form of credit card debt. At this point in our adventure together, our pockets, and credit limits, were pretty much empty. One night at the Rock Bottom Brewery in Charlotte, of all places, both of our credit cards were declined. It was truly a rock bottom moment.
We were forced into a corner and had no choice but to try to sell what we had created to different companies than the ones who promised us a check only after we delivered a long list of “critical” features (on our nickel).
So we did what we had to do: we stopped using the term “beta” and started selling our software to companies that would pay us handsome fees for the capabilities we already had under the hood. The first few companies said no, but soon afterwards companies began saying yes. Within six months, we had several new customers and several hundred thousand dollars in much needed working capital (i.e. sales). Instead of giving away beta software for free, or at a heavily discounted price, we had sold our first paid betas.
Those early sales fueled our development efforts and helped us close critical gaps in the software. Then we started charging customers for additional capabilities they wanted to accelerate on our product roadmap.
We had accidentally uncovered the secrets to a successful beta.
“The purpose of beta isn’t to test your software. Rather, it is to help your company generate early sales and prove market fit.”
Secrets of Successful Betas
As I reflect back, I realize we had the wrong initial companies in our beta. They weren’t looking for critical capabilities; these companies were looking for proven technology. And we just weren’t proven yet.
One of my larger lessons learned (of which there are many) is to accelerate your efforts in trying to sell an early form of your solution. Don’t wait. Get out there and create the dialog needed to connect with prospects right away – preferably before you start building a bunch of stuff.
Below is my revised checklist of a successful beta phase, after many painful lessons learned. A successful beta phase should:
- Prove market fit: Whether you did the “build it and they will come” approach, or you started with brochureware, a successful beta should leave your team convinced there is a viable need in the marketplace (and your solutions successfully address those needs).
- Generate revenues: Remember that customers, by definition, are users who pay you money. And paying customers are better references for you in the long run, because they can more concretely speak to the value and return on investment they have received from using your software. One of the best ways to prove market fit is to successfully extract revenues from the market segment you are focused on. The beta phase should help your company generate early sales. These early sales will give your team the confidence, energy and staying power you need for the long haul.
- Fuel the product road map: It is much better to have a few beta customers paying top dollar than a ton of beta customers paying hardly anything. When you focus on a few key paying customers, you have a better chance of dealing with companies that have similar needs. This will keep whoever is playing product management from going clinically insane. Randomly signing up a bunch of beta companies is disastrous, because everyone will need different sets of change requests to be successful. Overlapping beta customer needs will crystalize and focus product management on critical capabilities that need to be closed to make those customers raving fans. In addition, some of the critical capabilities will allow you to command more revenue later in the form of higher price points for the software. They will also help you provide upgrade opportunities for customers later.
- Crystalize the value you provide: At the end of the beta, you should deeply reflect on two major components. First, what made people write you the check? What were they hoping to accomplish? Second, what did they accomplish on your software? What measurable results did they experience? A successful beta encompasses a qualitative research component to answer these questions.
“A better definition for a strong beta customer is a prospect that is willing to pay to become a customer for an early version of your product.”
Some Lessons Learned
A better definition for a strong beta customer is a company that is willing to pay to become a customer for an early version of your product. An even stronger candidate is one who will pay a premium to gain critical capabilities in advance of when the product is commercially available to the general market.
Early adopters are typically described as curious, adventurous consumers who buy first, talk fast and spread the word to others about the pros and/or cons of what they have purchased. If you get things right with this group, you’re supposedly on your way.
In my experience, early adopters definitely pay a premium, but other great beta customers are companies with urgent needs to fix pressing problems (that hopefully your software addresses). This implies you will have to engage in many conversations with these companies – which, in my opinion, is more important to focus on during beta than product management issues. Pick your beta participants carefully and avoid free betas.
Just remember that no matter what happens as you grow, your beta customers who paid handsomely for your software should always be treated as the company’s sweethearts.
WANT TO LEARN HOW TO
It's easy! We can show you how.