So You Want to Be a "SaaS-y" Founder?

Editor’s Note: Founder and contributor Ben Yoskovitz has been involved with SaaS businesses (Software as a Service) for some 9 years. This includes his current startup, Standout Jobs . How to do “SaaS” right has been debated lately. VC Byron Deeter outlined Bessemer Venture Partners’ 10 Laws for Being “SaaS-y”, some of which were quickly disputed. At his Instigator Blog, Ben recently used his own experience to illustrate the good and bad of being a SaaS vendor, and how to do it better.

We’ve abbreviated Ben’s thoughts below, but here’s his whole post:Lessons Learned Running a SaaS Business.

Extending and responding to Byron’s 10 Laws, here are [my SaaS] lessons learned:

1. Monthly or Yearly Payments?

… 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
…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 … 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…

4. Think Viral
… 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 … the longer it takes, the more likely [customers] won’t use [your product] 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…
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

6. Staying Local Makes Sense Byron suggests staying local and not trying to sell your product internationally for quite some time … 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. [At] my previous company… we had a client in Japan that was also a local install … On top of that, the client couldn’t give us any remote access (for installation, upgrading, support) because of the security rules in place… we actually had to ship them the software [and] when they ran into problems it was almost impossible to resolve.

7. How Long Do Customers Stay? … 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… 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? … NO! [Byron’s] reasoning is sound. Having to manage multiple codebases is very difficult. I’ve lived it. The problems go up exponentially… it definitely has an impact on your ability to scale…. Just hold onto the single instance, multi-tenant approach as long as you can…


Comments have been disabled for this post