Beta Programs - My Take

Recently I read a nice post by April Dunford on her Rocket Watcher blog about her take on beta programs. I also found a rant by Tom Grant on beta programs with an interesting spin.

Beta programs in software companies have become so distorted it’s hard to find a consistent approach any more.

In the Dark Ages

In the dark ages of the software business when everything required a mainframe, the cost of developing software was extraordinarily expensive. The cost of merely acquiring a ‘small’ mainframe and associated system software from IBM was easily into 7 figures and then there was the cost of supporting it too. It was cost prohibitive for most software companies to test a software product as thoroughly as they would like.

Beta to the Rescue

The answer was the beta program where you would get a handful of ‘beta customers’ who would bravely try out your new product in exchange for some give and take. This was largely a development managed exercise where the goal was making sure the product was as good as possible before handing it over to the sales team.

No One Wants to be First

Those big hairy mainframe software products also had long sales cycles. Buyers would take 12 to 18 months or more to finalize a buying decision, and involve a large number of buying influences. No buyer wanted to be the first customer but at the same time they were heavily influenced by references and case studies.

Converting Beta Customers to Customers

Enterprising people in software companies figured out that if they could also get the ‘beta customers’ to become customers that would also be references, that could accelerate pipeline growth and compress the sales cycle. Necessity is the mother of invention.

So the focus shifted to finding beta customers who would not only lend their testing help, but also their ability to influence other buyers. This became a widespread practice because it was very successful.

Beta in the New World

Some companies today use beta programs as their quality control department (then wonder why beta customers think their product sucks). Others use it as a way to get feedback on usability (wait to test usability until you get to beta and you’re screwed). Some use it as a way to sell a product that’s not ready for prime time because they need revenue in the quarter.

My Take

My position on beta programs is built on the work Jim McCarthy discussed in his book “The Dynamics of Software Development”.

  1. The beta program is never an excuse for poor testing or design
  2. The beta program is for validating positioning and messaging
  3. The beta program is an opportunity to find weaknesses in delivery and support mechanisms
  4. Salespeople may not derail the beta program to close a deal

Of course you want the beta program to help test the product in real-world environments as a way to find and fix rough edges. But your product should be in a shippable state before your beta program starts.

A huge benefit of an effective beta program is to validate the position statements and messages for each buyer who you need to influence, before committing large sums of money to marketing programs. Often the good initial work done in positioning is adjusted as a result of the feedback received in a beta program and helps to differentiate your message to stand above the crowd.

What are the goals of your next beta program?

Is validating your positioning and messaging one of them?

Also read Saeed Khan’s article “Building a Better Beta”.

David Daniels

David Daniels

(0) Comments

Looking for the latest in product and data science? Get our articles, webinars and podcasts.