We officially ended the beta period for the Plus version of TimeTap last week and the first thing we have to say about it is: Hallelujah!
The beta period lasted for a total of 14 weeks, and we learned a number of valuable lessons in that time. Undoubtedly, there are still lessons to come, but in this post we wanted to give everyone a taste of some of the things we’ve learned so far.
To be sure, our freemium SaaS business model isn’t revolutionary. Tons of businesses have had similar models. And yet, SaaS is far from being taught in business schools. At TimeTap, we often feel like we’re taking a shot in the dark when it comes to some decisions. Sure there are blog articles and books that discuss SaaS subscription models, but nothing has really stood the test of time.
We want to share our experience so that other SaaS companies struggling with releasing their product into Beta can benefit from our blunders. So, with the hopes that you can learn from the places where we stumbled, here are some of the biggest lessons we learned:
Lesson 1: Collect names as early as possible
We initially launched TimeTap with just our Free plan back in November 2014. Before that, we had our public site up and were collecting names of people who wanted to try us out when we launched.
This gave us a lot of momentum when we released TimeTap as we had collected emails from about 300 people. Many of these folks signed up immediately once we sent them an email letting them know TimeTap was ready, and they are still our biggest (and most forgiving) fans.
We didn’t, however, do this for the launch of TimeTap Plus. The biggest differentiating feature between TimeTap Free and TimeTap Plus is that on Plus, you are able to add multiple staff to your account at a cost of $5/month/staff after the base account cost ($9.99). Instead of polling our free users to see who wanted multiple staff and targeting them directly, we just released the feature and sent out a blast announcement.
In a Beta period, feedback is really important and it took us longer to get feedback on our multiple staff feature because we didn’t really have an idea who was going to be interested in it in the first place.
When your team is as small as ours is (4 people at this point) you need advocates for your product, and the best place to find those advocates is among your user base. Collecting names of people interested in the main features TimeTap Plus offers could have helped build stronger relationships between us and our users and gotten us feedback much faster.
Lesson 2: Really Commit to Deadlines
In case you missed the last paragraph, our company is still in its early stages and our team is still small (although we have large enough personalities to make up for it). Sure, we have a founder/CEO, but at this point we don’t have annual reviews or hierarchy structures in our company. A lot of the “oil” that goes into the machine of a larger corporation just makes no sense in our office.
This can be good and bad. The good part is that there’s no red tape to worry about. The bad news is, if we slack and miss the deadlines we set for ourselves, there’s no one “higher up” that’s going to hold us accountable.
We had estimated that the Beta period would last for around 10 weeks. It ended up lasting 14. It’s not terrible, and we did try hard to meet the goals we set. Some weeks we just ran out of time and didn’t get it all done. Other things came up and the scope changed slightly.
If you are developing an app or SaaS product and have a Beta period, make sure that you lay out your goals and deadlines from the start and do everything you can to meet them. When you are working under your own whip, then it can be easy to let you foot off the gas and just creep along. This is especially true if you are a small team.
It’s difficult, because for months at a time your days can look very similar: doing development, testing, more development, more testing, etc. You’ll get tired and bored and you’ll want to do something else. Be wary of this lure. Finish the task at hand, set deadlines, aim to meet them, and forgive yourself if you miss them. Just don’t quit.
Lesson 3: Get on the phone with some of your users
Where we learned the most during the Beta period was in our conversations with actual users. It can be tough to hear feedback, particularly when the feedback involves a hint of criticism, but feedback is crucial to building an application that people love.
We probably should have tried to do more of this. We spoke with at least 10 different users over the phone during beta, and each of those conversations resulted in changes with our design. They also offered a lot of motivation for us to work harder and faster to be able to get features to our users that would ease the real burdens they’re facing.
I’m not saying you have to seek out users to interview, necessarily (although that’s a good idea). I’m suggesting that when your users write in with a support issue, you write back saying “Great question. It’ll be a bit easier to explain over the phone. Is there a good number I can reach you at?”
Once you have them on the phone, be personable and ask a few more questions about what their goals are related to the service area your app is in. After you get off, you’ll have provided great support and started a relationship with your user.
Lesson 4: Promote your app through different listing sites
Before we launched into Beta I spent a ton of time researching different listing sites to put TimeTap on. I found the following blog articles helpful in sourcing those listing sites:
Some of them are paid, some of them are free, some of them are out of date and not worth your time at all. Either way, putting your name on listing sites is great for people who casually browse to see the latest trends and not too shabby for SEO juice.
The listing site we found the most benefit from was CSS Mania which cost us $10 to submit to. It brought a ton of traffic while we were up on the first few pages of the site.
Fair warning: going through all those listing sites gets tiring so space it out over a few days. We probably could have/should have done more of this too, but the good news is it is always an option.
Lesson 5: Put a few things down in stone
Just like you should really commit to deadlines, you should try your best to think through what needs to be set down in stone early on in the process.
For instance, at the beginning of all this we were calling what would become known as TimeTap Plus simply “TimeTap Basic”. We didn’t put much thought into it until halfway through the beta period when we had a team meeting and decided that “Basic” really doesn’t have much appeal to it. At that point we changed everything to TimeTap Plus, which resulted in a lot of different issues (both in our app and in our messaging software which tags users based on plan types).
You can’t foresee everything, but you can try to foresee some things. Go ahead and set aside some time for a team meeting to decide on what things make sense to determine now so you have minimal changes (and headache) later on.
Lesson 6: Aim for weekly releases
Having weekly releases during your Beta period helps to keep the energy and excitement alive. While we didn’t release major updates every week, we did have a small release most weeks during our beta period.
We frequently got responses like “awesome update! thanks for keeping them coming!”. Sticking to a standard release schedule and making an in-app announcement about it will get your userbase revved up.
It also lets your users know that there are real people behind the software! One thing we’ve heard over and over and over again is a sense of surprise when people call our phone number and a real person picks up and that person actually has a picture on our website. It’s as if they think software development teams are an alien species from a distant galaxy.
When you communicate regularly with your users, it breaks down the idea that you are a voiceless bot. It helps your users relate to you and encourages them to communicate back. A weekly release is the perfect method to check in with your users regularly, and it adds excitement because you have something new to share!
Lesson 7: Use a post-it note development timeline
We have a large sheet of paper taped to the window in our office and split into four quadrants: May, June, July, August. In each of those months, we put color-coded post-it notes for each of the major development items we aimed to get done during that timeframe.
Having that timeline on display in our office gave us a greater sense of accountability to the schedule we created. Sure we had to move things around a bit as we got delayed, but that’s easy to do with sticky notes.
We also have a second sheet of paper hanging next to the large sheet that reads “Done Sh**”. After we finish the development item, we move the post it note to that sheet and have a bit of a celebration ceremony (it involves some clapping and maybe a coffee break). It’s not much, but it was really encouraging and seeing that done list grow has been motivating.
Those are the 7 lessons that we’ve learned so far. We have another Beta period coming up when we release our Pro account (one step up from the Plus version) and plan to put these tips to the test again.
I would love to hear what experience you’ve had with any beta trials or releases. Have you ever released a SaaS product into a Beta period? What lessons did you learn from that experience? Please tell us about it in the comments below!