How to create a Beta program for a software startup

I had the recent realization that Preclose.co’s timing is dead on. If you don’t know how important market timing is, read Peter Thiel’s Zero to One or this quick blurb on his theory on timing. Less than 6 months ago, I was exploring which problem to solve in the real estate tech space, when I came across a reverse pitch from a very influential person in the industry. I quickly pulled together a team and began to execute on it. Not only did I get to meet this very influential player, but received the opportunity to demo the product in front of an audience of top notch industry people. I’ve since received an influx of qualified users wanting access to our Beta product and I’ve had to quickly try and figure out next steps. Quite honest, I wasn’t ready to have so much inbound interest. So…just 3 months into development, with another 3 months to go, here we are building our Beta program framework.

Some may not think this is a true Beta program, it might be more of an Alpha program since we are inviting users to shape the initial product with us. Whatever you want to call it, I thought I’d share some of the thought process behind our framework and how we plan to get to launch in the next 3 months.

  1. Landing Page: We built a quick landing page that captures email addresses at Preclose.co. If you need to capture any other info, like we do, try to keep it down to 2–3 fields of info. The more fields you add to a registration form, the easier it is for someone to walk-away. When someone registers (let’s call them a user), assuming you have some sort of inbound marketing setup, make sure the landing page sends out a confirmation to the user that more info will follow and are excited they registered.
  2. Follow up: Whether the initial follow up is via MailChimp campaign or manually emailing…we try not to let more than 5 days go by without hearing from us. 5 days sounds like a long time, but I’ll do a little research on the user before reaching out (I can do that since we are B2B and lead volume is lower for a product still in development). If you are in a high volume B2C, manually vetting beta users will be painful. You’ll probably need to find a way to segment them through your landing page sign-up process (x.ai is a good example).
  3. Segmentation: For a product that is only 3 months into development, we’ve received a lot of highly qualified inbound interest to be apart of our beta program. I interviewed the majority of the users that expressed interest and segmented them on 3 qualities: industry knowledge, location, and company size. Users that could be seen as influencers in their area (NC and SC states), that had at least 10 other users in their company were selected to help shape the product. Limiting to geography is really key in our case, since we deal with different state and local laws.
  4. Selection: This is a really exciting time, for both you and the beta user. In our case, they’ve expressed interest in shaping the product and being an early adopter. They’ve essentially validated the problem needing to be solved without actually seeing a fully functioning product. Make sure your beta user knows what an honor it is to have them participating in shaping your product, as well as, what they can expect throughout the process. Build that relationship early!
  5. Expectations: Clearly layout what you expect of the user through the process. Centercode, beta management software gurus, says that about 1/3 of your beta users will actually provide feedback. Make sure to account for that when inviting and setting expectations. I’ve decided on a 3 month timeline and make it clear that I may extend into a free trial, but then it will eventually be a paid subscription.
  6. Beta Agreement Forms: Protect yourself and your user by clearly laying out some guidelines around who owns the IP, etc. Centercode has free basic templates that I’m tweaking for our use. Get the signed agreements back from your user before you give any access or share any more info about your project.
  7. Site Visit: I’m going to spend a lot of one-on-one time with my earliest users and already have plans for site visits. I have a project management/professional services background and find discovery is more productive in person (for B2B). Before a site visit, I’m asking users to send me any documents, screenshots, etc of pain points to dig into beforehand. If you are B2C, I recommend holding webinar style sessions and see if that works well in lieu of onsite visits.
  8. Ongoing feedback: I wish we could afford Centercode’s software, but at almost $1k/mo, we can’t afford it as a startup. All our money is being spent directly on product development. While we haven’t started our beta program yet, I can guess that the feedback loop between users, me as the project manager, and our dev team will be extensive. I’m going to trial out ZenDesk and see if that can help with the feedback loop. Any other suggestions that can manage the feedback process, other than email and spreadsheets, let me know!

If you’ve found anything that works exceptionally well during the Beta process, or if I’ve missed something, don’t hesitate to comment on this article. Hope to continue sharing our journey! When we get through this Beta process in early June, I’ll be sure to share any learning lessons!