It’s been a little over 4 years since I officially launched my internet marketing software company, HubSpot. (The “official” date is June 9th, 2006 — for those that are curious about such things). So, I’ve had about 4 years on the “inside” of a fast-growing, venture-backed B2B SaaS startup. Quick stats: ~2,900 customers, ~170 employees and $33 million in capital raised. But, this is not an article about HubSpot, it’s an article about things I’ve learned in the process of being a part of one of the fastest growing SaaS startups ever. (I looked at data for a bunch of publicly traded SaaS companies, and the only one that grew revenues faster than HubSpot was Salesforce.com).
In any case, let’s jump right in.
7 Non-Obvious SaaS Startup Lessons From HubSpot
1. You are financing your customers. Most SaaS businesses are subscription-based (there’s usually no big upfront payment when you signup a customer). As a result, sales and marketing costs are front-loaded, but revenue comes in over time. This can create cash-flow issues. The higher your sales growth, the larger the gap in cash-flows. This is why SaaS companies often raise large amounts of capital.
Quick Example: Lets say it costs you about $1,000 to acquire a customer (this covers marketing programs, marketing staff, sales staff, etc.). If customers pay you $100/month for your product and stay (on average) for 30 months, you make $3,000 per customer over their lifetime. That’s a 3:1 ratio of life-time-value to acquisition cost. Not bad. But, here’s the problem. If you sign up 100 customers this month, you will have incurred $100,000 in acquisition costs ($1,000 x 100). You’re going to make $300,000 over the next 30 months on those customers by way of subscriptions. The problem is that you pay the $100,000 today whereas the $300,000 payback will come over time. So, from a cash perspective, you’re down $100,000. If you have the cash to support it, not a big deal. If you don’t, it’s a VERY BIG DEAL. Take that same example, and say you grew your new sales by 100% in 6 months (woo hoo!). Now, you’re depleting your cash at $200,000/month. Basically, in a subscription business, the faster you are growing, the more cash you’re going to need.
2 Retaining customers is critical. In the old enterprise software days, a common model was to have some sort of upfront license fee — and then some ongoing maintenance revenue (15–20%) which covered things like support and upgrades. Sure, the recurring revenue was important (because it added up) but much of the mojo was in those big upfront fees. The holy grail as an enterprise software startup was when you could get these recurring maintenance fees to exceed your operating costs (which meant that in theory, you didn’t have to make a single sale to still keep the lights on). In the SaaS world, everything is usually some sort of recurring revenue. This, in the long-term is a mostly good thing. But, in the short-term, it means you really need to keep those customers that you sell or things are going to get really painful, very quickly. Looking at our example from #1, if you spent $1,000 to acquire a customer, and they quit in 6 months, you lost $400. Also, in the installed-software world, your customers were somewhat likely to have invested in getting your product up and running and customizing it to their needs. As such, switching costs were reasonably high. In SaaS, things are simple by design — and contracts are shorter. The net result is that it is easier for customers to leave.
Quick math: Figure out your total acquisition cost (lets say it’s $1,000) and your monthly subscription revenue (let’s say again say it’s $100). This means that you need a customer to stay at least 10 months in order to “recover” your acquisition cost — otherwise, you’re losing money.
3 It’s Software — But There Are Hard Costs. In the enterprise-installed software business, you shipped disks/CDs/DVDs (or made the software available to download). There were very few infrastructure costs. To deliver software as a service, you need to invest in infrastructure — including people to keep things running. Services like Amazon’s EC2 help a lot (in terms of having flexible scalability and very low up-front costs), but it still doesn’t obviate the need to have people that will manage the infrastructure. And, people still cost money. Oh, and by that way, Amazon’s EC2 is great in terms of low capital expense (i.e. you’re not out of pocket lots of money to buy servers and stuff), but it’s not free. By the time you get a couple of production instances, a QA instance, some S3 storage, perhaps some software load-balancing, and maybe 50% of someone’s time to manage it all (because any one of those things will degrade/fail), you’re talking about real money. Too many non-technical founders hand-wave the infrastructure costs because they think “hey we have cloud computing now, we can scale as we need it.” That’s true, you can scale as you need it, but there are some real dollars just getting the basics up and running.
Quick exercise: Talk to other SaaS companies in your peer group (at your stage), that are willing to share data. Try and figure out what monthly hosting costs you can expect as you grow (and what percentage that is of revenue).
4 It Pays To Know Your Funnel. One of the central drivers in the business will be understanding the shape of your marketing/sales funnel. What channels are driving prospects into your funnel? What’s the conversion rate of a random web visitor to trial? Trial to purchase? Purchase to delighted customer? The better you know your funnel the better decisions you will make as to where to invest your limited resources. If you have a “top of the funnel” problem (i.e. your website is only getting 10 visitors a week), then creating the world’s best landing page and trying to optimize your conversions is unlikely to move the dial much. On the other hand, if only 1 in 10,000 people that visit your website ultimately convert to a lead (or user), growing your web traffic to 100,000 visitors is not going to move the dial either. Understand your funnel, so you can optimize it. The bottleneck (and opportunity for improvement) is always somewhere. Find it, and optimize it — until the bottleneck moves somewhere else. It’s a lot like optimzing your software product. Grab the low-hanging fruit first.
Quick tip: Make sure you have a way to generate the data for your funnel as early in your startup’s history as possible. At a minimum, you need numbers on web visitors, leads/trials generated and customer sign-ups (so you know the percentage conversion at each step).
5 You Need Knobs and Dials In The Business. One of the great things about the SaaS business is you have lots of aspects of the business you can tweak (examples include pricing, packaging/features and trial duration). It’s often tempting to tweak and optimize the business too early. In the early days, the key is to install the knobs and dials and build gauges to measure as much as you can (without driving yourself crazy). Get really good at efficient experimentation (i.e. I can turn this knob and see it have this effect). But, be careful that you don’t make too many changes too quickly (because often, there’s a lag-time before the impact of a change shows up). Also, try not to make several big changes at once — otherwise you won’t know which of the changes actually had the impact. As you grow, you should be spending a fair amount of your time understanding the metrics in your business and how those metrics are moving over time.
Quick advice: If you do experiment with pricing, try hard to take care of your early customers with some sort of “grandparenting” clause. It’s good karma.
6 Visibility and Brakes Let You Go Faster. One of the big benefits of SaaS businesses is that they often operate on a shorter cycle. You’re dealing in days/weeks/months not in quarters/years. What this means is that when bad things start to happen (as many experienced during the start of the economic downturn), you’ll notice it sooner. This is a very good thing. It’s like driving a fast car. Good brakes allow you to go faster (because you can slow down if conditions require). But, great visibility helps too — you can better see what’s happening around you, and what’s coming. The net result is that the risk of going faster is mitigated.
Quick question: If something really big happened in your industry, do you have internal “alarms” that would go off in your business? How long would it take for you to find out?
7 User Interface and Experience Counts: If you’re used to selling client-server enterprise software that was installed on premises, there’s a chance that you didn’t think that much about UI and UX. You were focused on other things (like customization, rules engines and remote troubleshooting). That was mostly OK, because on average, the UI/UX of most of the other applications that were running on user desktops at the enterprise sucked too. So, when you got compared against the other Windows client-server apps, you didn’t fare too badly. In the SaaS world, everything is running in a browser. Now, the applications you are getting compared to are ones where someone likely spent some time thinking about UI/UX. Including those slick consumer apps. You’re going to need to step it up. In this world, design matters much more. Further, as noted in #2 above, success in SaaS is not just about selling customers, it’s also about retaining them. If your user experience makes people want to pull their hair out and run out of the room screaming, there’s a decent chance that your cancellation rate is going to be higher than you want. High cancellation rates kill SaaS startups.
Quick tip: Start recruiting great design and user experience talent now. They’re in-demand and hard to find, so it might take a while.
So, what do you think? Are you running a SaaS startup now? What have you learned? Would love to hear about your experiences in the comments.
Warning: I'm about to go on a bit of a rant. I usually only reserve these
kinds of articles for when things really irritate me, and this is one of
those times. I'm generally a patient, considerate person, really I am.
Here's the source of the most irritation I've felt from a technology article
in a long time (and this from BusinessWeek, a major brand that I respect):
The Hype For Software As A Service
I actually hesitated to even include a link to the article, because you might
be tempted to go read it. But it has to be done. It's kind of like when you
smell something really awful that's been growing in your refrigerator.
Then, you give it to your spouse and say: "Hey, check this out -- can you
believe how bad it smells?"
Disclaimer: I work for a tiny little startup that provides marketing software as a service. So, I guess
I could be biased. I'm not wrong on this one, but I could be biased.
Back to the article. Here are some of the issues I had:
1. SUVs Suck, So SaaS Must Too: The author does some
strange build-up in the opening paragraphs using "SUVs are cool" and "cell
phone causes cancer" as examples. The point? That both of these are/were
surrounded by "hype". And, we should always beware of hype. Think of the
children! I'm already irritated. For the record: I don't think SUVs are
cool. Oh, and these inane examples are what drove me to the title of this article. Fight fire with fire and all that.
2. SaaS Is Cheaper: The article tries to refute the "myth"
that SaaS is cheaper by providing this cogent argument: "Most service providers
charge each user by the month." There's no discussion of the economics of
installed software, drive-by sales in enterprise software, or the cost of
capital for small businesses. Hey, those SaaS vendors charge monthly, so it
must be more expensive. Right? That must be why Salesforce.com has
been so successful -- they just charge more than Siebel.
2. SaaS Reduces Hardware Investment : It refutes the
"myth" that SaaS requires less hardware investment by arguing that although you
don't have to pay for all the servers and stuff, you still have to pay
for fast access to the Internet. Here's the quote: "Sure, the SaaS providers
deal with the servers, and all the Windows headaches and patches and builds and
versions and whatever. That's their problem. But you still need fast access to
the Internet." The rest of this particular argument just gets worse from
there. Now, I'm really irritated.
3. SaaS Is Quicker To Setup: Yep, this is a myth that is
"busted" too. The example provided: "It's kind of like assembling furniture."
The author provides as evidence that SaaS is not easier to setup, the fact that
he's got a lopsided bookcase in his den. This "proves" that little theory about
SaaS being quicker to setup, wrong. Sure, setup costs for SaaS can be high
(based on level of customization), but on average, SaaS offerings are
simpler and quicker to get going on.
4. Data Can Be Secure In SaaS: The article argues that
data backup and reliability in SaaS is a myth. Once again, we have extreme (and
in one case totally unrelated) examples offered as proof. Yes, data security is
always a risk, but I'm not convinced that the risk is any higher for
SaaS than businesses (especially small businesses) than running the software on
your own servers, sitting in your closet somewhere.
If you think I'm being overly harsh, please read the article. I dare you.
And, if you do go read it, please don't forward it around to your colleagues.
Sometimes, you don't need validation that the thing in your refrigerator really
does smell that bad.
End of rant. Back to our regularly scheduled program next time.
I've recently been thinking a lot and discussing with my colleagues at
HubSpot the implications of Saas (Software as a Service). We're looking at this
from many angles: operational cost, development cost, support cost, etc.
One of the big advantages for SaaS startups is the opportunity to be
economically efficient along many dimensions through multi-tenancy.
But, just because the opportunity is there doesn't necessarily mean that
every startup is exploiting it equally.
In my online readings and research, I came across an article about the SaaS Simple Maturity Model. Though I'm not particularly fond
of the name, the framework is very useful.
Here's my (even simpler) interpretation of the levels of maturity of a SaaS
Level 0 (Chaos); Every time you add a new customer, you add
a new instance of the software. If the customer needs something specific, you
change that software instance. Each customer is essentially running on their
own "version" of the software. Yuck!
Level 1 (Managed Chaos): Every customer runs on the same
version of the software and any customizations are done via
configuration. But, you still have different instances for each customer (their
own website, their own virtual server, their own physical server, etc.).
Level 2 (Multi-Tenant, Highrise): You've got all customers
running on a single version of the software, and they're all running essentially
on one "instance". The good news is that you're getting the benefits of
multi-tenant (sharing resources across customers). Even better is that you're
not writing custom code for each customer -- everyone essentially runs on the
same version. The big challenge is that as you add more floors to your building
(to stretch the analogy a bit), it gets more and more expensive. And, there are
limits to how high you can build to accomodate a large number of tenants.
Level 3 (Multi-Tenant, Build-Out): This is when you've got
multi-tenant, single version of the software model. But, you can scale-out (add
buildings at will). This is optimal because instead of letting the architecture
decide how many tenants you put into a building, you can let the economics
decide. And yes, there is an optimal number of tenants per instance
and this number varies on your situation.
Level 4 (Utopia): This is like Level 3, except you've
figured out an efficient way to run different versions of the software on
different "instances". You're doing this not because you're writing custom code
for a customer, but because you want to run different code for different
customers -- to try things out. The best example is having an "early adopter"
instance where customers that want to use your latest and greatest features can
do so. Helps them. Helps you. Helps everyone. As long as you're efficient
about release management. [Note: This last one is my own fabrication and
wasn't part of the original framework referenced above).
HubSpot, my startup, is currently at a Level 2 and shooting for Level 4 this
year (with a brief stop at Level 3 as an intermediate point). The good news is
that we're adding cusomers quickly so this is more than an academic exercise for us.
We can actually rationalize the investment in terms of economics because the
benefits that we get from improvement actually makes us money.
Are you a superstar startup developer in Boston? Consider applying to
HubSpot. Help us figure out how to delight thousands of customers and make
money at it. Share in the fun and success. You can email me at dshah [@]
onstartups.com. If you have what it takes, we've got some awfully smart and
passionate people you'd enjoy working with.
This has been the longest time elapsed between posts (12 days) since this blog started over a year ago. Apologies for that. I’m traveling in India for the holidays (which is where I’m writing this from now).
During my time in India, the question of whether startups should offer both a hosted and a non-hosted version of their applications came up. This issue comes up in conversation about once every 4-6 weeks for me, so I thought it was time to try and address the issue. On an unrelated note, I’m also planning on a follow-up article regarding software startups in India which I’ll write once I’m back on home ground in Boston.
So, should startups offer both a hosted and non-hosted version of their software? The short answer is: ideally, no.
Thoughts On Offering A Hosted and Non-Hosted Version
- Duplication Of Costs: I’m a big fan of the hosted software model and generally advocate using the Software as a Service delivery mechanism wherever possible. But, regardless of whether SaaS makes sense for you or not, I’d argue that you shouldn’t offer both a hosted and non-hosted version. In addition to the cost of developing the software itself, there is a cost associated with each delivery mechanism you choose. If you decide to install your software on client premises, you’ll be investing in things like install scripts, documentation and some sort of remote diagnostics/support (based on what type of application you have). If you’re providing a hosted version, you’ll be investing in infrastructure (even if it’s outsourced), backups and other kinds of things. By trying to do both a hosted and non-hosted version too early on, you’ll be incurring both sets of costs. This may be fine later, as you have a clearer idea of the revenue opportunity but in the early days, few startups can afford any kind of extraneous expense.
- Different Kinds Of Customers: Even though the software is the same, you’ll find that often different kinds of customers will lean towards either a hosted or a non-hosted version. Trying to meet the needs of both these kinds of customers can also be difficult and expensive. The ideal situation for a startup is to find a significantly large pool of potential early customers that have as much in common as possible. This is how you get the most leverage (and can drive the best profits). The more divergent your customer-base, along whatever dimensions are interesting, the more difficult a time you will have. If you pick either hosted or non-hosted, you’ll find that you start “filtering” your potential client-base and focusing on a smaller pool (which is a good thing). For example, at my current startup, we are only offering a hosted version of the product. The reason is that our ideal customers are those that do not have the IT resources to manage their own infrastructure (they’re small businesses). When we encounter potential clients that insist on a non-hosted version of the software they can install themselves, the chances are extremely high that the customer is not a good fit for us as they don’t fit the “profile” of customers that we could bring the most value to.
- SaaS May Be More Acceptable Than You Think: I think too many entrepreneurs work under the mistaken assumption that for their market, offering just a hosted version of the software will not be “sufficient”. That too many of their customers will be so concerned about the security of their data that they will be unwilling to let their data leave their four walls onto a hosted software platform. I can understand why it is so tempting to believe this – I believed it myself at one time. One thing I have learned is that clients don’t spend as much time worrying about data security as you think they do (of course, this varies across markets). When they do worry about, they’d much rather it be someone else’s problem than theirs anyways. My advice is to at least try offering a hosted version of your software to your potential market and see what kind of receptiveness you get. [Note: If the market ends up not adopting your offering as quickly as you’d like, make sure you don’t blame the fact that it’s hosted too quickly – it could be something else]. As for the argument that by simply offering an “installable” version of your software, you can cover all your bases and not forego any of your customers. This is a dangerous trap. Its similar to the trap of “if I add this feature and that feature, I can increase the pool of my potential customers…”. In the early stages of a startup, your goal is not to increase the total pool of possible customers, but to go after a narrower pool of customers that have lots in common so you can service their needs extremely well – and economically.
So to wrap-up: Try if you can to offer just a hosted version of your software (note to self: Write a follow-up article on all the benefits of hosted software for startups). If you must
provide an installable version of your software too, then do that. Just don’t try to hedge your bets and do both. It’s usually the wrong way to go about it for early-stage startups. If it turns out later that you can capture a sufficient number of other clients by offering an alternative model than you can cross that bridge when you get there.
What do you think? Am I overstating the costs of providing a dual (hosted + non-hosted) option? Would love to hear your thoughts in the comments.