One of the points that come up most often in my conversations with entrepreneurs is how to get through the ‘beta’ stage. During this stage, the product is far from being complete, both product-wise and technically. However, it’s still at a point where you can already start testing it with external users. Reaching the right beta users is critical. A company’s inability to gather proper feedback or create a stable process that can stretch as far as you planned can jeopardize the entire operation.
Phase 1 – Define Exactly What’s Needed
The single point of failure most companies fail to avoid is defining beta users. It’s very rarely clear enough. There is also little-to-no thought about the beta period and its results. Many times, since we’re dealing with a product that is not mature enough, we tend to operate under the preconception that anyone can join our beta phase. This preconception can be destructive.
What Is the Purpose of the Beta Phase?
There are a number goals, each completely different than the other, and requires a specific game plan. Here are the main ones:
● Get Product feedback – Does the product bring value?
● Get technical feedback – Is the product working well for you (technically)?
● Get ready for the subsequent funding round – To identify organizations that can give positive feedback for investors.
● To evaluate the primary funnel – What will the CAC (Customer Acquisition Cost) be? How many customers will be engaged? Etc.
How Many Beta Users Do You Need?
This is a principal decision that will significantly affect how you ‘recruit’ users.
● 10 beta users or less – Mainly suitable for B2B productial beta or technical feedback.
● 11-100 beta users – Usually suitable for B2C products or ‘soft’ B2B products.
● 101-1,000 beta users – Suitable for user-cost estimation stages or other parameters that require a larger scale.
Phase 2 – Who Are These People Who Are Willing to Use a Beta Version Anyway?
Let’s face it, being a beta user is not an amazing experience. For us entrepreneurs, it seems super exciting. For the end-users—not so much.
In my experience, beta users are divided into three groups:
Group 1 – Early Adopters
They love startups, are dying for innovative technologies, and are product freaks. Early adopters are usually very disciplined beta users. They are patient and highly generous when it comes to feedback. The problem with them is that they tend to drill down and over-focus on the details. For an early-stage product, this is inefficient.
Group 2 – Friends
This is my least favorite group. Unless you need pure technical feedback (i.e., run the product in several environments to see if everything works), I would avoid friends altogether. And I’m not referring only to close friends, but to anyone who has joined your beta test just because they know you – friends of friends, Facebook friends, your investors’ employees, etc. The main problem with this group is that they do not represent your typical user. Throughout Oribi’s history, I have refrained from asking friends to use the product. The only times I have recruited friends to help us was either in the very early stages of technical testing or for pinpoint feedback.
Group 3 – Top-Tier Users
This is my preferable audience. Even if your product is still buggy, there is probably a small percentage of your go-to audience that is so desperate for a solution that they will be willing to suffer the bumps. The great advantage of using this group is that they are your target audience and actually have the exact pain point you are trying to solve.
Should You Fight for Every Client?
The answer is no. Most users simply don’t fit your solution for various reasons. Take, for example, the number of beta users you actually need and multiply it by three. From my experience, this is roughly the ratio between users and churners. What I mean is, if you genuinely feel you need ten beta users, you should strive for 30 companies thatwill actually start using your product. Why do we lose so many users along the way?
● The main issue is the user’s slow response time. While you rely on feedback for your upcoming funding round and are stressed for time, for your users, that will the beta is a low priority. One of the most common scenarios is: You had a successful meeting, you committed to starting the beta, and then… bottlenecks. “We can get to it at the end of the month after we release the new version,” “I’m OOO for two weeks,” “I need DevOps approval, and it might take a while,” and so on. Usually, a company is genuinely interested in participating in your beta, but it’s at the bottom of their priority list. I used to have the ‘must fight for every beta client’ approach, but today I’m in a different beta state of mind. I adopted the law of large numbers, i.e., to move forward with a bigger pool of companies and ‘abandon’ companies who are not responsive.
● The feedback is not relevant. Another well-known scenario is when the input given is not what you were looking for. I had quite a few cases where beta users generated a lot of ‘noise’ in the system. Usually, it means they are not compatible with the user profile you need. It’s a little awkward to ‘fire’ a beta customer, but in most cases, it is a must.
● You prefer investors don’t communicate with certain users. This issue is only relevant if one of the essential parameters for beta users is that you can put them in contact with potential investors. In Takipi, my former company, there was one step before one of our substantial rounds, where I thought it necessary for our investors to speak to a group of our users. Negative or critical types of people are less appropriate in this case.
How to Reach Your First Beta Customers
So there are two groups of potential beta customers you want to approach:
1. Companies that really (but really) need your product
2. Companies that your product is a good fit for
As long as you aim for a beta that includes several dozen users, you don’t need any marketing activities, in my opinion.
I like publishing organically on Facebook groups, Reddit communities, LinkedIn groups, etc., to bring in the first users. In my experience, it’s better not to use a ‘marketing’ tone but rather to disclose that you are in the preliminary beta phase and looking for first-time users. Describe the problem you are solving transparently. These posts will draw in your early adopters and those who are looking for a solution like you offer. These organic posts landed us, in the past, esteemed companies such as Foursquare (at their golden era) and Atlassian. Tend these reach outs with the utmost respect and use them sparingly. There is a limited number of social groups suitable for your needs, and you won’t be able to post such messages frequently.
Another option is to define a list of specific customers you wish to reach and use your connections (friends, employees, investors, etc.) to make intros. Bear in mind that this is different from fishing out for random companies using your contact list. The more your goals are, the more successful your beta is. Even if you find no connections to the target companies, don’t hesitate to reach out via email/Facebook message, LinkedIn message to the right decision-maker and give your pitch. You may get lower response rates, but the more accurate your pitch is and the bigger the company list is, the better your chances are. That’s exactly how I landed Twitter and LinkedIn.
Yet another option is to target a wider audience and run paid campaigns on Facebook or similar mediums. You don’t have to be Don Draper or go over budget. For the most part, reaching a limited number of users is pretty simple and cost-effective. And here, too, the early adopters will ‘find you.’ Indeed, for this strategy, you will need an essential website and onboarding process. It is quite possible to refer these users to a landing page that invites them to sign up for a beta, and from that moment, you will switch to a telephone connection with them.
However, this strategy requires a website and a basic onboarding process. You can also refer users to a designated landing page with a beta registration form and then simply contact them via phone.
How to Make Sure Your Beta Doesn’t Fizzle Out
You have a great meeting with a potential beta customer, they fall head over heels for your product, and you decide they’ll start beta immediately. But then they postpone the onboarding, and after initial use, they suddenly don’t sign in anymore.
This happens to all of us. This combination of an immature product and customers who are not in dire need is a recipe for tremendous momentum that fizzles out quickly.
The real art of beta is building momentum. Here, too, it is vital that you set distinct goals; in some cases, a few days of product use are sufficient to collect feedback. I make sure I set a clear schedule for beta clients before we begin. I even recommend putting it in writing; working with organized documentation promotes a higher commitment. I used to schedule five-minute bi-weeklies, to sync and establish the next steps. Scheduling these short appointments helped me move from ‘nagging’ to a place where it’s okay to call and touch base,
One other habit I developed in all the companies I led was encouraging the users to try the product while we’re on the first session. In Takipi, I would do a 15-minute demo. If the responses were positive, I would suggest using the time left to install the product on one of the client’s servers. In most cases, it works. Harness the customer’s enthusiasm to leap over the hurdle of self-serve installing.
Make sure you thoroughly understand why your beta is fizzling out. If the product is not suitable for that type of customer – there is no reason to waste precious time and effort. This way, if the product is not viable – you will fully understand the reasons why.
Should You Charge During the Beta Phase?
In my opinion, if you can charge – do it. Granted, there are very early stages of the product where it doesn’t make sense to bill users. However, from the moment the product gives real value, it is perfectly logical to charge for it. This way, you’re not only getting insight into how much customers are willing to pay (and for what features), but you also develop a deeper commitment.
How to Communicate That the Product Is Not Market-Ready Yet
As clearly as possible. My law regarding the beta phase is to ensure no harm comes to the customer’s existing conduct; not to slow down their website download time, crash their servers, damage information, etc. It’s sacred. Apart from that, it is perfectly acceptable to have bugs in your product. It is crucial to explain clearly what works well and what is still clunky and may cause issues. When it is clear to both parties that the company is still in the early stages, the dynamics change. The better you communicate your state of affairs, the more forgiving they will be when glitches occur. To a large extent, good communication upfront will prevent you from launching unsuitable pilots. If some users have zero tolerance for errors, they are probably not a good fit for your product at this stage.
Should I Look for Beta Users Abroad? Or Close to Home?
It is easier to find beta customers in your origin country (and manage the project successfully). But, this has some implications:
● Ironically, American customers are usually more ‘easy-going.’ In Israel (where I’m based) are, in many cases, very judgy. It’s perfectly ok to be judgy, but this is not your typical beta user. There is a good chance that the tolerance for trial and error is lower in certain geos.
● Investors prefer at least some of the beta customers to be in the US.
● US customers will usually teach you essential aspects of the adoption process of your product. Parameters such as security, training, etc., are usually less critical when working in Israeli companies, for example, than when you deal with an American organization.
If the purpose of your beta is only technical – there is no need to venture outside your geolocation. For all other purposes, it is vital that at least some of your beta customers are US-based.