Lessons Learned Running a SaaS Business

I’ve been involved with SaaS businesses (Software as a Service) for just about 9 years. My previous company to Standout Jobs was a SaaS vendor. And in many respects, so is Standout Jobs.

Byron Deeter from Bessemer Venture Partners recently published his 10 Laws for Being “SaaS-y”. Ten rules to live by when startup a Software as a Service business. Incidentally, not everyone agrees. Martin Snyder wrote some competitive arguments worth reading. If you’re in the SaaS space or thinking about it, you should get the full picture.

Extending and responding to Byron’s 10 Laws, here are some lessons learned & thoughts from my experience in the SaaS business:

1. Monthly or Yearly Payments? Most SaaS vendors charge monthly. Some don’t even have long-term contracts, instead allowing customers to leave at any time. This is common with startup SaaS vendors because they’re trying to build a good relationship with customers and lower the barriers to entry. Long-term commitments can be a barrier to entry. And many startup SaaS vendors try to apply consumer-centric approaches to the market – no commitment, inexpensive, pay-as-you-play, etc. These SaaS vendors hope that their application is so useful and sticky, that customers just keep on paying…

   But as Byron points out smart SaaS vendors will offer discounts for longer term commitments and payment up-front. “Pay me for a full year today and I’ll give you 2 months free…” This is a smart approach. Anything that helps you get money up-front is a good thing because it’s money you can absolutely bank on. Future potential earnings are not set in stone. And the more money you have in potential bookings the harder it is to plan.

2. Customer Service is Everything. Everyone knows I love customers and I consider customer support & service paramount to success. Byron explains this perfectly:
   

   SaaS companies have to remember the “Service” in “Software-as-a-Service.” It’s very difficult and expensive to grow subscription businesses if you have moderate customer churn, and prohibitive if your churn is high. The top performing SaaS companies typically achieve annual renewals on a customer count basis above 90% (much of which is often due to bankruptcies, acquisitions, and other events beyond the company’s control), and over 100% renewals on a dollar value basis due to up-sells into this installed base.

   90% renewals is a very high number. And that’s going to require a ton of high-quality support to ensure customers don’t leave. You do have to realize quickly that you can’t keep every customer. As Byron points out, some things are out of your control (like bankruptcies, etc.) One thing to be careful about is only having one contact per client. If that person leaves, it will be much harder to restore the client relationship. That one person is often the biggest evangelist for your product; with them gone, you could lose the customer. So as you’re acquiring customers, make sure to build relationships with multiple people there.

3. Customers Leave. Why? Another thing to watch out for is when customers outgrow your application. For small startup SaaS vendors, this may happen more than you like. It’s important to understand the reason. For example, it might be because they weren’t a good fit. If that happens often, you need to examine the types of customers you’re targeting and potentially adjust that target. But it might be that their needs simply outgrew your applications functionality. In that case you have two choices — build more features or let them go. The folks at 37 Signals are famous for not adding features to their products simply because customers demanded them. Many, many, many people have asked them to build Gantt Charts into Basecamp, and still they refuse. They know their target market, and they’ve said before, “If you need something we don’t have, if you’ve outgrown our software, we wish you the best.”
4. Think Viral. B2B is different than B2C in some ways. But when it comes to making something that’s viral, B2C is beating the pants off B2B hands down. SaaS vendors have to build applications that are viral — that people want to and need to share with others in order to succeed. SaaS products with a viral component will help build multiple evangelists within an organization, increase referrals and help increase usage overall.
5. Adoption is Key. When you first sell your software product to a customer the most important thing is adoption. Customers need to adopt the application as quickly as possible; the longer it takes, the more likely they won’t use it effectively or at all. Byron doesn’t mention measuring usage or adoption as being important, but I think it’s critical. It’s a key indicator of renewal rates. In the early stages of a product it’s also a great indicator of what people like or don’t like about your software. Measuring adoption is easy, and I’d encourage you to build those metrics directly into the application so you can track the data at all times. And use the data as well.

   For example, if a customer is using the application heavily, go find out what they like about it. Get a testimonial. Ask for referrals. If a customer isn’t using the application, find out why. Immediately.

   Tracking adoption can be particularly useful when you discover aberrations in usage. A customer has been using your application consistently for 6 months. Suddenly usage drops to almost nothing. What happened? There are many possible reasons; if you’re not tracking adoption and usage, you’ll never know.

6. Staying Local Makes Sense. Byron suggests staying local and not trying to sell your product internationally for quite some time. He describes a number of the issues (many of which I’ve experienced):
   

   …companies [SaaS vendors] are faced with questions about latency, data access and security through replicated local datacenters, in-country customer support personnel, packaged integration with other regional software and SaaS products, and other similar issues.

   He’s absolutely correct. The biggest issue is typically customer support. How do you support a customer in Asia with your 9-6 EST support time? It’s very difficult. Once (at my previous company) we had a client in Japan that was also a local install (breaking another of Byron’s laws. On top of that, the client couldn’t give us any remote access (for installation, upgrading, support) because of the security rules in place (they were dealing with some very sensitive stuff.) So we actually had to ship them the software. Customer support was a nightmare. When they ran into problems it was almost impossible to resolve. (If Byron’s reading this he’ll probably get a good chuckle out of it.)

   Martin Snyder disagrees:

   Third, the rule about 1M a month in MRR before hitting Asia or Europe is just silly. If the phone rings, and the person on the other end wants to buy, you sell them a subscription. Who cares where they are sitting? If your localization strategy for the app is strong, you may even be able to offer local languages with little increase in your cost basis.

   This was exactly our old strategy. Doesn’t matter where you are, if you call and want to buy, we’re selling. We didn’t actively pursue customers overseas, but they did find us occasionally. I’m not sure a single one of them lasted with us for long. But it’s certainly tempting to sell to anyone who comes knocking.

7. How Long Do Customers Stay? This is a great question. Byron doesn’t address it, although I’d love to get his thoughts. On average, how long does a customer stay with a SaaS vendor? There are probably too many variables to figure it out and come up with a useful number. But in my previous experience it was about 3 years. If we kept a customer 3 years we were very happy. The beauty of the SaaS model is in renewals — because it should cost less and less over time to service a customer, and therefore you should earn more profit from them over time as well. This is a simplistic explanation of a more complicated economic model, but we found that after 3 years there were too many things that could go wrong (evangelist at the customer leaves, customer goes bankrupt, gets bought, etc.), and we’d already done very well with the client.
8. Customization Requests are Inevitable. I’ve met very few customers that are satisfied with a software application and don’t want something changed. Very often, customers will ask for customizations. And they’ll even be willing to pay for them. Is this a good thing?

   Byron says NO.

   Single instance, multi-tenant – Have only one version of the code in production.

   His reasoning is sound. Having to manage multiple codebases is very difficult. I’ve lived it. The problems go up exponentially. But how realistic is maintaining a single codebase? The customization requests will come in, and oftentimes they’ll be extremely unique to an individual customers so you can’t apply their value throughout the codebase. I have a hard time believing that bigger SaaS vendors actually stick to this rule.

   In order to do so you’ll have to accept that customers will leave. I know at my previous company if we hadn’t customized the application, customers would have gone elsewhere. So we did it, and quite often. But it definitely has an impact on your ability to scale.

   I wish I could believe Byron’s rule is perfect, but it simply isn’t. There’s no easy answer to this question. Just hold onto the single instance, multi-tenant approach as long as you can…

Software as a Service Evolving

The SaaS market is evolving. It’s still fairly new, and although well-accepted there are still skeptics. What’s interesting is that I’ve watched it evolve since very early on. Back in the day (Oy, I can’t believe I just said that), the biggest issue was security. That’s all people cared about. Over time, as things got more secure, it became less an issue. That was overtaken by uptime. Customers started demanding Service Level Agreements (SLAs) guaranteeing uptime, with money back for not meeting those goals, etc. It became a paperwork disaster. But, over time, as hosting environments grew stronger (and now we see a lot of success with things like Amazon S3 and EC2), uptime isn’t talked about as much. Everyone’s guaranteeing pretty much the same thing anyway…

Performance also used to be a huge issue. And it wasn’t an easy one to resolve, because a performance roadblock or hiccup could be anywhere — could be someone on a slow computer, slow Internet connection, etc. One bad server between your application and the customer, and performance was in trouble. Performance is still an issue today, especially as SaaS vendors add layers of technology to things and try to push the limits of what’s possible.

Another issue that remains, and I think will stay with us for quite some time is reliability. It depends on the importance of the data being stored with the SaaS and the importance of the application to the customer (is it mission-critical, for example?) but reliability remains important. In this case I’m defining reliability in a general sense — in the customer’s mind, they’re asking, “Is this software vendor reliable? Can they support us as we grow? How long will they be in business?” These aren’t questions that will get asked of all SaaS vendors (it depends on the type of customer you have), but it is something you should be prepared to answer. And it’s something you can combat — by looking professional, acting professional and providing top-quality support.