How to Build a Strong Beta Testers Community

A great idea can come from anywhere. It is important to involve the real users at the early stages of your development cycle. A strong beta testers community not only improves your product, but also provides context, pain points and ideas while increasing loyalty and engagement.

At the same time, a community requires time and dedication. Sounds hard and scary? Yes and no. I'll offer my tips and tricks on how to build a beta testers program and a process of supporting the program with a modest allotment. I’ll also share when to switch to building a community on a tiny budget.

Building a community is like building a product. You need to understand the target audience and the ultimate goal. The initial step involves running your first beta program, and not yet launching the community. For the beta program, you can try different approaches, tools, etc. When you feel you are ready, then go ahead and start the beta community.

What can stop you from building your beta testers community? Some will say, "I cannot provide something to customers that is not of high quality." These people assume that clients will not tolerate a reduction in quality or an incomplete feature. They fear showing the raw product or feature as they believe it sets expectations; but this can be easily resolved. Think of a product you like. Are you using the first version of it? Surely you are not. The product you love wasn’t built in one moment. It had multiple iterations and a lot of feedback. This is how you build products these days. If you are not convinced, let me tell you a sad story. At the beginning of my tech career I was working on a very complicated B2B product. It took us 18 months to release the new version. And then we got the feedback that it didn’t work. At some point, somebody wanted to improve the product and introduced changes that blocked the entire new feature in a very popular scenario. It was a disaster. If we had had a beta program, we would have immediately discovered this. So, it is better to provide a raw version of your product to the beta customers than a useless product to the market.

Others say, "I cannot share my upcoming projects with my customers because they may be leaked. Product development is very competitive." Of course, your competitors will be happy to know about your plans; it is a vital concern. Maybe they have secret test accounts. But the fear of being exposed should not stop you from improving your product and building a deep relationship with your customers. All you have to do is scan your customer accounts before providing access to the beta version. Propose signing an NDA before the start of the beta program. It should be enough to mitigate any risks.

Perhaps you believe you need to have constant monetary stimulation in order to keep the beta testers community up and running. That’s not exactly true. You may want to attract a certain audience by providing gift cards of service discounts, but at the end of the day, don’t think that gifts, money, or discounts will take away all your beta program issues. Your audience wants to have better products. Your audience wants you to implement their requests. You just need to prove that they can trust you. You need to prove that the audience will get value from the beta program.

Do you think you require special software to manage the community, feedback and feature requests? No; the Excel or Google table is enough to start managing all your data.

Note that a beta testers community cannot replace a product manager. If you, as a product manager, don’t know what the product strategy is, the beta community will not provide these answers for you. You are the leader of the product; this role cannot be delegated to the beta community.

Before you start, you should define your goal and target audience. Defining goals is the first task to complete. Here are a few relevant ones: test an idea and gather feedback to make sure you are solving the right problem; test the sketches to make sure you solve the problem right; and test an early version to get feedback and adjust the solution before the official launch. Don’t forget to describe how you understand that you have achieved your goal. For example, if you want to get feedback regarding your product, that’s great. But what if only one user provides their feedback? Does it mean that you have achieved your goal? Make sure you can measure the results so that you are able to achieve your goal. And as with any other goal, don’t forget to revise your goal during your beta program. You may want to adjust it as you go.

How much time do you have to dedicate to the beta program? If you do everything manually, then you need to set a maximum number of participants. Think how many contacts (customers) can you serve during the beta. Your beta customers will ask questions, provide feedback, and log the bugs. You need to reply to every email/feedback/bug so you can build trust and pay attention to those who dedicated their time to your program. My first program contained around 40-50 beta customers. It took around 30-50% of my time to handle the beta program, which was ok at that moment.

Public beta

Public beta can be more valuable for B2C products. If you want users to share their beta program experience on social media like Facebook, Twitter, Instagram or Pinterest, make sure you have predefined share buttons for the most popular platforms. It can increase attention to your product and attract new customers to join the beta program. Plus, think about gamification. Create a tournament or testathon. Participants love to get badges for their achievements to share in social media.

Private beta

If you want to keep your new product or feature in secret, it can be done even if the competitive landscape is harsh and you need to have an edge. Think about an NDA before providing access to the beta.

Beta page

Create a simple page with all the basic information regarding the beta program. What is the target? What do you expect users to do? What product(s) are you going to provide? Also, it would be useful to include a Q&A to make sure you have explained everything.

The reason you need to have a page instead of putting all the info in an email is that emails tend to get hidden in the inbox. Plus, if you put all the info in an email, it will be super long. Long emails aren’t likely to be read.

What to include:

• If the beta is free
• How the user can join or leave the beta program
• What to do in case of issues (contact support as usual or provide the channel for submitting bugs and feedback)
• How long the beta program will last
• What to expect after the beta program ends
• The time it takes to be a beta tester. How much time should your users spend daily/weekly using your product?
• How frequently you will send notifications/tasks
• Will users get the tasks they need to perform, or will there be a free feature exploration?  

It is important to include how to share information. Is the beta program public so that people can share their journey on social media? Or will they need to sign an NDA?

Submission forms

Make sure you validate the customer as your target audience for the beta program. If you are running multiple beta programs for different targets, you can get new beta users from the multiple beta program submission forms. It can be done using any survey form like Google forms or Qualtrics or Survey Monkey. If your company doesn’t have a survey software license, then I would recommend using a free software for the first beta program.

Cold emails

Creating a passionate and outstanding email can make a big difference. Each of us receives tons of emails every day. Don’t assume that your customers will tolerate boring emails. You must make an impression during the first three seconds; this is the average time a user will spend on your email. During these three seconds your user needs to understand the following things:

• What the email is about
• Why they should join the beta program
• What they need to do (call to action)

The reply rate will be 3-7% depending on the loyalty of your customer base. Don’t hesitate to send a follow-up email. We all operate in a buzzy world bombarded with tons of emails. If a person doesn’t reply within the first two days, you have lost that user. A follow-up email can result in up to 30% of total replies.

How to deliver the updates

How can you get beta users to use the updated version? Do they need to go somewhere and download it? Do they need to agree to the auto-update?  It can be an automated or a manual process. I have done both and as you can imagine, an automated process is easier and less time-consuming. But automation takes time upfront. At the same time, automated updates often require alignment with the internal release process, which can be tricky and hard on the big companies. Manual updates are still the best option when you need to test as soon as possible and don’t have the resources to set up automated delivery. I remember manually sending emails with a link to the updated software version. It was time-consuming, but at the same, we tested product ideas as well as multiple new technologies. We were changing frameworks and UX approaches, and we were not tightly connected to an existing architecture or release process. It gave us a platform for fast experimenting.

Communication plan

How often do you plan to communicate with your beta users? Weekly, monthly? I would recommend sending at least one email per week, even if you don’t provide a new version of your product. You need to be in contact with your audience to keep up their interest in your beta program. Major updates are not the only reason to connect with them; if you lose connection with your audience, then there will be fewer active users in your beta. Furthermore, people may simply forget they are a part of the beta.
Appreciate people for being active and for their feedback. It nurtures the feeling of belonging.

Send a follow-up email about something you have implemented based on the user’s feedback. It makes your beta users feel that they can influence the product. They become emotionally attached and loyal. Don’t forget to include the beta page link and the feedback email address in each of your emails. People tend to lose this information.

When the beta program ends

This is a huge milestone for everybody involved and something to celebrate. A closing email is a must. Provide a summary, milestones, achievements, and major updates made based on user feedback. Congratulate your customers on the beta program end. Make them feel proud for being active beta program users. At the end of the day, you make software for them. And don’t forget to invite them to participate in the closing survey.

Closing survey

Make sure you hear not only the loud voices, but also the quiet ones. A survey is a great tool to understand how your beta users saw the beta, what was missing, and what was done great. Include questions with predefined or closed answers as well as open-ended ones. Closed questions give you an overall picture - the quantitative result. Open-ended questions are much harder to process, but will give you new information not specifically asked for - the qualitative result.

For example, while processing open-ended questions, I realized that I didn’t communicate with the community often enough, yet I thought I was bombarding my beta participants with emails. That was an eye-opening moment. The closing survey can help you make your future beta programs better. If your beta program is long enough (more than three months), you may consider having not only the closing survey, but also a middle-term survey to track the first results and adjust your beta program processes and scope.

Track the response rate. If it is lower than 10%, then you need to adjust the survey. It may be too long, confusing or complicated. Also, you can use the survey to recruit people to your next beta program or enter the beta community with access to all the new features before their release.

From the beta program to the beta community

When you feel you have a solid beta user base and all processes are in place, you can move from the beta program to the beta community.
Running a beta community will require more time. You can start it yourself, but very soon you will need a community manager. There are multiple activities to keep beta participants active and motivated:

Community webinars will keep your community updated regarding the latest results and news. It will also give your audience an opportunity to ask questions about the hottest topics.

A forum – this could be a platform where users can discuss and exchange their experiences and opinions. You can start with the free Slack version or use any free forum platform like Wordpress plugin. It should be a moderated and safe space, so make sure you have enough moderators to do so. If you are going to moderate the forum by yourself, you will need to handle spam, abusive or inappropriate behavior, and a lot more. Also, there will be a lot of questions to address. I would recommend starting a forum with a team to support it.

Features, bugs, and ideas - your users should be able to submit them. Other users can see the ideas/features and vote on the ideas. It will help you understand what is important to the community. Remember that transparency builds trust. Seeing that your vote is important and will be taken into consideration is sure to increase feedback and involvement. Schedule interviews to hear the most critical and important ideas, features, and major bugs. Having an idea tracker without a regular review is useless. Also, your beta user will be frustrated and feel unheard. Launch this idea tracker only if you have time and the dedication to constantly work with it. In an ideal world, the idea tracker will be connected to your development tracker, so the status of the idea or bug will be automatically updated. This is not always the case. Don’t forget to update the status; it will show the community that their opinions matter.

The reward program for finding security issues. The bigger your product, the more attention from the cyber community. Even if you hire a third-party security audit, there is a high probability that somebody will find a security breach. You want this person to receive a reward rather than "exposing" the security issue.

I wouldn’t recommend starting with the reward program for bugs in general, because it is very time and money consuming. But starting the security reward program can significantly decrease the risk of security issues exposure during the hockey stick growth. We all remember the Zoom security issue articles during their exponential growth. Nobody wants this kind of attention for their product.

Now you should be inspired and have a plan on how you can start your first beta program. However, there are several more points to remember:

• It takes time to keep the beta community up and running. You need to dedicate time, so block it in your calendar
• Be ready to make cold calls and send cold emails. A low response rate is expected at first.
• You can start without software. You can have one email for feedback, another for feature requests and then use Excel to track the beta testers.
• The loudest customers may or may not fit your ideal profile. Be careful about this. Profile the customers before accepting them into the beta program.

I can share a very funny story regarding user profiling. I was looking for specific companies for my beta program to test the product idea and the sketches. One company replied that they were a perfect match and agreed to an interview. During the interview I discovered that the company wasn’t my target audience. They just were so nice and wanted to help and they thought they knew about the type of company I was asking for; sweet and bitter at the same time. I excluded this company from the target beta program, but included another one. Don't underestimate the importance of customers’ profiling; make sure you have a true target audience for your beta program.
Your first beta program will never be great. Just try, get feedback, adjust, and start over.

About the Author

Lilia Gorbachik is a product manager with more than 15 years in IT, working in different roles: QA, pre-sales, project manager etc. Gorbachik is also a product management coach who helps PM professionals and startups.