Learnings from Our Private & Public Beta Phase

Over a year ago we started working on SupportBee. In a few weeks we will be doing a public launch. We have been in beta for over six months working with about 50 companies. It has been a long phase but we have learnt a great deal about SaaS and our software in particular. Today, I want to share some of these learnings and have a discussion with other entrepreneurs.

However a bit of disclaimer before I begin, Many of the learnings or observations may be relevant only to SaaS startups and may not apply to B2C startups for example. With that in place, let's start

Don't focus on collecting emails during the private beta. Focus on learning more about your problem or customers

The recent trend in web-startups seems to be a launchrock page with minimal information about the product and just a field to collect email. It also encourages people to share the referral link (without actually knowing much about the product) on Twitter to get access faster. In our experience, this is a wasted opportunity. The goal early on should not be to collect as many email addresses but to learn more about the problem you are solving.

We used a wufoo form during the private beta. Apart from asking for their email address, we also asked our visitors what problems they were facing with their existing support setup. We also asked them if they would be willing to talk to us on skype to tell us more about their problem. It worked really well. Dozens of companies described their problems when signing up for beta and many of them agreed to phone interviews. Had we gone the launchrock way, we may have collected some more email addresses but would have lost out on all this useful information.

Early adopters don't care about too many features but do care about the completeness of features

When we started rolling out access to our product, we were worried about not having analytics/reporting and other big features. However most of the feedback we received from our early adopters was about small things that were missing or did not work well in the features that we already had. For example, very few customers complained about the lack of a mobile solution. More customers wrote to us about improving the reply by email (which in a way offers mobile support) functionality that we already had. This was not just one isolated example. Over and over we received detailed feedback on existing features and how to improve them and much lesser about adding big new features.

Early adopters are not scared of using the API

By definition, early adopters like something about your product that they can't find elsewhere. Given that, they are willing to adapt to your unfinished product. 37Signals preaches that you say no to feature requests. This is what most companies do most times. However if you have a great API, you can point your customers to it and they can sometimes build the missing pieces themselves. We are still far from having a developer ecosystem around SupportBee API but several of our customers are already using the API to do small things that are missing (or cannot be added) to the product.

Even if you are free during the beta, people want to know your pricing

There are two school of thoughts around charging during the beta. The lean startup way is to charge during the beta because that way you are validating one of the riskiest assumption in your business models. However, like a lot of startups, we decided to keep the product free during the beta. Surprisingly, the number one feedback we received from visitors on our site and even on Hacker News was about the lack of clear pricing.

If businesses depend on your app, even your early adopters want to know how much it will cost once the free phase is over (even if the app is free for many months). People don't want to move to a tool and change their workflows and build on it's APIs and then realize that it is prohibitively expensive. It's a good idea to have your pricing figured out early on. In fact, looking back, I think it's a good idea to charge really early on. We waited for months before charging and once we did, we realized that we could have done it long back. The sooner you start charging, the faster you will realize if the pricing is working well or not and you can then iterate on it (just like the rest of your product).

There are many other learnings we had during the last six months but the ones above are some of the big ones. If you have any comments or some learnings that you have had during your beta, please leave them as comments.

Hana Mohan

Hana Mohan