Bessemer's Top 10 Laws of Cloud Computing and SaaS Revisited :
Can they be applied to early-stage SaaS start-ups too?
Venture capital firm, , who have invested in multiple cloud computing firms globally, published a whitepaper in late 2010 entitled Bessemer's Top 10 Laws of Cloud Computing and SaaS
It attempted to codify what they termed as their evolving Cloud Computing best practices for SaaS companies, and it's abstract was quite straightforward: "Running an on-demand company means abandoning many of the long-held tenets of software best practices and adhering to new principles."
In reading the ten laws, its becomes apparent that Bessemer has conflated two different categories of rules - those that inform how a product/service is designed, built and deployed, and those that inform the enterprise's higher-level business practices.
Doing so would ordinarily be problematic for analytic clarity... except in this case the oversight reflects and thereby provides proof of a certain reality - that eBusiness operates under its own set of rules, which only partially intersect those that govern conventional business.
While this may now be accepted uncritically as axiomatic - particularly by those working in the eBusiness space - it is only because of Marshall McLuhan's epiphany a half-century ago about media - that the medium is the message - or more plainly, that the platform itself affects content and people's perception of it.
This insight has become so normative that now even children at a very early age grasp the essential difference between a television/movie/video game reality and the one they face at home or at school. And people in general understand that journalists and their subjects are each constructing for the viewer the story that each wants to tell, and that the aliens depicted in National Enquirer-style tabloids belong to a merely conceptual reality, as do celebrities, zombies and truthful politicians.
So too has there developed an almost universal acceptance/expectation that eBusiness in general operates with its own set of rules, and in particular that SaaS businesses - those that are the most "e" of eBusinesses - operate with a rule set that intersect those of conventional businesses the least, because, to extrapolate McLuhan, it follows that products are also affected by their medium - in this case the internet, and all that implies - as are a product's business rules, and the business methods deployed to market it.
With this in mind then, let's revisit Bessemer's 10 Laws and discuss them from the perspective of an actual SaaS practitioner, and in particular, how they can be applied to a younger start-up, rather than one that is already fully funded and scaling exponentially.
Rule # 1: Build less to earn more
Leverage the cloud everywhere you practically can, both for your internal systems as well as for your own product offering(s)... This will not only give you a direct understanding of the customer experience and best-of-breed strategies of Cloud Businesses, but it will free up your technical resources and balance sheet to focus on your core product and customers.
I concur absolutely that this heads the list. I call it the don't re-invent the wheel rule, and apply it to everything that we do.
SaaS is really just a collection of processes/features that we organize and deploy in a particular way, depending on our product. It happens that in the online world, many individual product components are available pre-built, for a fee, and often - incomprehensibly - because of the "open-source" movement, at no cost at all! In many instances - particularly for an early-stage start-up with limited resources - our job is often one of integration and modification/customization, rather than development at a low-level.
It would be as if, as a hardware manufacturer in the off-line world, one were able to source state-of-the-art components or component designs for free, or at a tiny fraction of the cost that in-house R&D would entail. Imagine how that would shrink costs and time-to-market!
This means that we can focus our resources and expertise precisely on our USP, and source those other processes that serve simply to deliver and enhance our core product, from others for whom that component is their USP.
Perhaps the most obvious example of this is , the most ubiquitous, powerful and reliable mapping solution available today.
We use this resource to enable shoppers to locate businesses within a radius from their location - both online and on-mobile. It's simple to integrate, and, for what is essentially a free (for less than enterprise level) yet state-of-the-art functionality, the how-to documentation is pretty good. Importantly, the user-base is sizable enough that a simple search will locate additional documentation carefully assembled and made available by other users - again, incomprehensibly, purely out of goodwill - for even the most unusual use-case.
With something like this available, it would be idiotic to develop one's own mapping solution, at a cost of millions of dollars, to match what Google makes available virtually for free. We are not in the mapping business - nor actually, are we in the R&D business. We are in the online advertising business, and anything that detracts from that reduces our bottom line.
This in particular is a great example, because of the fiasco that occurred with the release of the iPhone 5 by Apple, where they switched from using Google Maps on the device, and decided instead to re-invent the wheel and develop their own mapping solution.
Now, I understand that somewhere in there a clash of the titans business case probably existed, but it turned into a fiasco on so many different levels. Firstly, because their solution produced location errors, which, for a mapping solution actually released into the marketplace is unforgivable. Secondly, because the fiasco itself undermined what had been virtually a perfect reputation that had led to a mystique putting them in a class of their own, one that will now be out of reach for a long, long time. And thirdly, because it says something pejorative about a company, when they are eager to spend hundreds of millions of dollars unnecessarily and imprudently, just because they have the largest cash reserves on the planet, particularly in the context of reports that were published at the same time showing the company's founder and CEO Steve Jobs to be not only one of the world's wealthiest men, but also - in juxtaposition to his enormously wealthy peers who were giving most of their money away through philanthropy - one of the stingiest.
Fortunately for most SaaS companies, such decisions are considerably more straightforward. As in other spheres of life, degree of hubris is proportional to available resources.
Rule # 1 extends into every facet of our own product and it's supporting back-end and back-office systems - from the software languages and frameworks that we use, to the server and database systems, payments, communication, marketing, tracking, CRM and accounting systems, all are developed by leaders in their respective fields, and integrated within our service, some as a "free" open-source resource, others as fee-based SaaS at an often trivial cost when compared to that of in-house development.
Rule # 2: Build for the User (rather than for their manager)
Perhaps it's because Bessemer, at their core, are bean-counters, that they feel the need to remind us what everyone else in the industry already holds as their core principle - to not build software that sucks!
Their point is that buying decisions are made less by managers and increasingly by those within the organization that actually use the products. So, while historically software may have needed only to have a satisfactory USP in order to be purchased by a distant manager, it now requires both the USP and the type of usability elements that have become normalized by platforms such as Google, Facebook or LinkedIn - intuitive and dynamic as opposed to being confusing and complex.
We go one step further, and actually leverage the R&D function of the well-funded giants. If there is a particular piece of functionality we need as a component to our product, and we can't beg, borrow or buy the pre-designed, pre-built, pre-tested widget from elsewhere, we ask the question how did Google solve this? Chances are that there is a well designed example available for us to emulate, that meets our business rules (and some that we never even considered), with the usability issues already resolved.
Bessemer makes two important additional points, however, that are less blindingly obvious, and need to be emphasized.
Firstly, that it's unnecessary to try to capture and solve every possible use case. The Pareto principle (80-20 rule) applies here as it does in so much of what we do. If we can address 80% of the needs of 80% of the market, we can have a reasonable business. Adhering to this principle can save the time and money spent developing functionality that has a diminishing ROI. It's actually quite liberating - particularly for the obsessive types of which this industry is largely made up - to have "permission" to just walk away from marginal use-cases.
The second point has to do with the tendency, particularly by younger companies eager to win large or enterprise clients, to offer some type of customization. "Just say no!", according to Bessemer,
stressing the importance of building a single instance, multi-tenant product, with a single version of code in production, in order to ensure that your operation remains lean and mean.
An exception to this rule, I would think, particularly for younger companies who really need that large sale - for the revenue as well as for the validation - is if the client is willing to actually pay for the custom work, and if the resulting functionality, or a sub-set of it, can then be rolled into the single instance core product. What better way to underwrite the cost of researching, developing and validating new product features?
Rule # 3: Build best-of-breed, single-purpose software
Bessemer describes the recent past for companies as a litany of disastrous attempts to implement complex software suites across their organizations at an enormous cost in time and money, only to face the reality that, while one element may have been be best-of-breed, the other elements were mediocre or worse.
Contemporary SaaS however, provides the opportunity to leverage best-of-breed application offerings, with the standardization and pre-integration of many of the applications and APIs. You can pick the world's best application for every need, every user, and every business case. You can deploy exactly the number of seats you need, where and when you need them.
It's hard not see the corollary here, to the notion that companies should stick to their core-competencies - that conglomerate diversification, absent the strong leadership and commitment necessary to excel across all of the verticals, generally fails to deliver as promised.
Rule # 4: Grow or Die
In technology, you're either getting bigger or you're getting smaller... you either grow up to become a dominant company in your category, or get passed by and killed off by someone who does accomplish this goal.
This is a sobering thought, and it really distills to the essential point the type of pressure that a SaaS startup lives with - to get the products right, to get the delivery platform right, to get the sales and marketing campaigns right. Funding is so scarce on the ground, that you have to deliver the first time around. If you don't, it's unlikely that more money will be made available to allow you another chance.
The other aspect of this is that it's only through deploying a credible plan for capital efficient hyper-growth that you are able justify the high valuation your company requires in order to raise sufficient capital up-front, and in order to persuade core employees to forgo higher salaries in exchange for stock options.
The danger of course is that, if you don't get it right, not only will you have much less equity available to leverage in exchange for additional investment - should it even be made available - but your core employees may run for the exits, unwilling to double-down on the risk of continued lower salaries and the ever decreasing value of their options.
Rule # 5: Understand and trust the 5C's of Cloud Finance
After surveying hundreds of leading public and private Cloud Computing companies, 5 key "C" metrics now rise above the others as essential top level performance indicators: Committed Monthly Recurring Revenue (CMRR), Cash Flow, Customer Acquisition Cost (CAC), Customer Life Time Value (CLTV), and Churn.
For a young start-up, it may be difficult to get visibility of and to track these metrics. It's critical to do so however, particularly because you really need to be validating that package of assumptions on which your product, delivery platform and marketing are based, and modifying where needed very quickly. See Rule # 4, above.
Fortunately, this is the type of solution that SaaS is ideally suited for - a comprehensive, consolidated subscription billing solution, that automatically tracks every facet of revenue, provides full reporting, and a real-time dashboard to view the critical metrics. And, when integrated with a CRM solution, you can have full visibility of the entire cradle-to-grave customer engagement.
We use , because it's a best-of-breed, complete product, purpose-built to serve the SaaS paradigm, and the only available billing solution that provides a solution to manage multiple tax rates - a critical feature, particularly if operating outside of the U.S.
CMRR: Committed Monthly Recurring Revenue
CMRR is the single critical metric by which the health of a growth software business can be judged.
It reflects not merely the number of new customers being on-boarded, or even the total revenue accruing from them, but, rather, this latter figure when adjusted for churn, and to reflect only those customers who have already integrated the service and are operating in the marketplace. Essentially, Bessemer proposes, if you are going to use a metric for predictive purposes, make sure that it also reflects the inherent risks.
This approach is inarguably going to result in a more trustworthy estimate of current and future revenue, but it is hardly revolutionary - even putting aside its simple commonsense. Insofar as it includes the multiple elements that affect the outcome, it reflects the same sober view of reality that the almost 60 year-old PERT technique is intended to, when, as Project Managers, we need to determine a risk-averse prediction for task duration.
We should not however entirely discount the importance of the number of new customers simply being on-boarded. For an early start-up, this may initially be a more critical metric than CMRR, because, in order to get to the place where CMRR is significant, you need firstly to demonstrate market validation of your USP and that your system functions and scales reliably as intended.
The most common method of doing so is to on-board customers at a deep discount or even for free, the more the better. Since the USP of a scalable automated system is that small to medium volume increments carry little or no additional overhead once development is completed, the value of actually having customers, almost regardless of revenue, outweighs the cost.
Not only are these new customers essentially your beta testers, they can also be used in your marketing pitch for the purposes of validation - in terms of promoting the sheer number of "customers" that you have, but also if they are willing to evangelize about your product (which, on a quid pro quo basis, most are willing to do). And, especially if your customers are recognizable brands, the benefit to your previously unknown company of a cross-branding association with them and their success is enormous.
Just as we take on new customers on this basis, so too do many of our SaaS suppliers provide us with their services initially for free or at a deep discount. And, when cash-flow gets tight - as it does from time to time for most start-ups - these same companies don't hesitate to carry us until our cash flow improves. Simply put, for a SaaS company, while initially low or intermittent revenue is a problem, it's one that can be overcome. A failure to on-board new customers however, is almost certainly the precursor to company closure.
Even when a start-up arrives at a point when their volume and scale makes CMRR entirely meaningful, the number of customers they have can still be enormously useful for marketing purposes. For example, what is probably the most innovative ecommerce SaaS system available today, a company with real revenue, and one that recently received a hundred million dollars in second-round funding, still recognizes the value in publicizing the highest number of "customers" they possibly can, despite the fact that perhaps as many as a third of them generate little or no revenue at all.
Start-ups have two masters - their customers, and those people that actually fund their growth - the venture capitalists. Both masters need to be sold on the company's business proposition, and the sheer number of "customers" a company has can be remarkably persuasive, regardless of the immediate revenue that they represent.
Cashflow is even more critical for Cloud businesses because [their] working capital requirements are higher and [customer] payment terms are often stretched out over the term of the contract.
In other words, the SaaS business paradigm creates cash flow issues because, while their major costs are up-front, their revenue occurs in small increments stretched out over time.
The significant method available to help mitigate this problem is to discount the services offered for an extended subscription - an annual rather than monthly term, for example. Since the SaaS business paradigm dictates pre-payment, and because the provision of additional services has a declining cost for SaaS companies, this method can be an excellent way to, in effect, raise operating capital.
But the discount has to be substantial. Parsimony will undermine the objective. For a customer to shrug-off the risk inherent in forking over a year's worth of fees to a new and unknown service provider who may disappear in 30 days - not from malice, but simply because the business may fail - it's critical that the offer be "too good to refuse".
I particularly like the "two months free" tactic. Pay for ten months now, get 12 months of service. It reflects a 17% discount, which, from a SaaS business perspective, is entirely reasonable. Depending on your need for cash flow, you can be even more aggressive, by coupling the "two months free" tactic, with a level-of-service upgrade. So, if you offer, for example, a "basic" and a "premium" product, offering the "premium" product at the price of ten months of the "basic", provides a huge incentive, one that may just address your cash-flow needs, while having a virtually insignificant additional cost.
It's interesting to juxtapose this scenario with that of the well-funded ecommerce SaaS company mentioned above. With the consequent lack of cash-flow issues, this company can afford to offer a discount that provides very little incentive for up-take. In this case, 10% for an annual term, and 20% for a biennial term. They do so primarily because customers will in any case be looking to find out just what the lowest available price is, so it's advantageous to resolve the psychological need quickly and simply. Just by offering a discount at all, they are reducing friction in the sales funnel. By offering a discount that provides little incentive - because they don't actually need the cash-flow - they get to eat their cake and have it too!
CAC: Customer Acquisition Cost
How do you know if your sales and marketing investments are ultimately "profitable"? This single number is the key to determining your level of sales and marketing investment. It can be calculated simply by dividing the sales and marketing costs of the previous time period, excluding any account management costs, divided by the new CMRR gross margin added during the same time period.
Bessemer suggests that a Payback Period of 6-18 months for higher churn products may be appropriate, and as long as 24-36 months for products with long retention periods. A Payback Period longer than that indicates you need immediately to stop spending and improve sales efficiency.
At the other end of the scale, a Payback Period of under 6 months is extremely promising, indicating that you can definitely afford to step up your marketing spending in order to grow even more quickly!
While this may apply to an already well-funded SaaS company, I would suggest that, for an early start-up, a Payback Period of less than a year is critical, just to keep the business viable.
CLTV: Customer Lifetime Value
The CLTV is the net present value of the recurring profit streams of a given customer less the acquisition cost.
Bessemer provides a complex formula requiring a pretty firm grasp of the incremental business costs - from R&D to operations to sales and marketing, concluding that 3-4 years for SMB customers, and 5-7 years for enterprise customers is entirely acceptable.
Presumably the differential is a consequence of the probable higher acquisition cost of enterprise customers, but I would argue that there is probably also a tendency for less churn amongst these customers, because their own implementation/integration costs are also higher, and as such they are less likely to want to switch horses.
The top performing Cloud companies typically achieve annual customer renewal rates above 90% - with most of the churn due to death (bankruptcies) or marriage (acquisitions) - and over 100% renewals on a dollar value basis due to up-sells into this installed base.
There is no denying that this bar is extremely high. While it reflects the performance of wildly successful, extravagantly capitalized companies who want for nothing and are lead by cohorts of the brightest people around, it needs still to be the objective for us mere mortals.
But how can we hope to achieve such success?
It all starts at the earliest stages of product conception, and continues as we execute our business plan. When conceiving/designing/developing and operating our service we have to ensure that:
it is enriching
Essentially, your product has to provide real value to customers, ideally a tangible value, rather than something frivolous. The gold standard of course is a product that actually makes your customers money, or at least helps them to do so in a significant way
it performs as promised or better
We have a customer whose marketing tag line is the simple statement "we do what we promised". There is a wonderful innocence, sincerity and lack of guile in that statement, particularly when considering the conventional wisdom that this level of performance has become increasingly rare. Simply put, churn is a function of un-met expectations. If, instead, these expectations are met, or better yet, exceeded, then service cancellation is unlikely.
it cannot be cancelled without a tangible loss
If the above criteria have been met, then service cancellation should have sufficiently negative consequences for your customer that it becomes unlikely. For example, our product essentially refers targeted sales leads to our customers, which directly leads to sales and revenue for them. Our customers and their customers upload videos and images to our platform, and we enable them to be found by targeted sales leads through search engines. If we have done our job right, then the very last thing that our customers should ever want to do is to lose all of this by cancelling our service.
The perennial business objective is to pursue, acquire and retain a customer for life. This is of course no different for SaaS companies.
Rule # 6: Study the Sales Learning Curve & Only Invest behind Success
Software organizations often fail because they staff-up their sales efforts too quickly, before the sales model has been refined. This concept is even more critical for cloud businesses, given the large upfront investment required to acquire customers. Ramping up too quickly will burn precious cash reserve and may fool the product team into missing some critical elements of the real product market fit that will be important in order to go big over time.
No one who has witnessed this type of colossal blunder first-hand - a product-market mismatch, coupled with premature scaling of a sales model that is also flawed - ever forgets it.
I was tasked with the design and development of a platform to support a particular business proposition. The proposition envisaged a hybridization of methods particular to SaaS and to professional services, ideally combining the lower operating costs of the former, with the higher fees commanded for the latter. This determined that the platform architecture should manage a certain scale and volume, and that some work-flow elements should be completed manually.
I voiced my skepticism to the CEO, but was faced with the choice of either doing everything that I possibly could to help his vision succeed, or of leaving the company. For better or for worse, I chose the former. As they say, everyone has a boss.
A sales and marketing plan was tailored. A recruiting company was hired to find the best salespeople available locally, who were then hired, trained and deployed. A sales team and manager were also recruited and deployed remotely. Radio ads were commissioned, taped and run, as were some print ads.
After 3 months, no sales had been made, and all of the salespeople had quit in despair of being able to sell the product on the basis of its business proposition.
The feedback from the marketplace was unanimous - prospects wanted a lower-cost, more simple product, billed on a monthly basis and with no contract. In effect, they wanted the product, but only if delivered on the basis of what has become the conventional SaaS paradigm.
The cost of this entirely avoidable error was enormous, and the company, having depleted its cash reserves, had to lay-off staff, and then essentially cease operating in order to re-tool.
Changing the entire business proposition meant changing everything. The company had to start from almost scratch - from product conception to architectural design and development to workflow systems to marketing and sales strategies - everything had to be re-thought for a proposition that now required that the platform be hyper-extensible and hyper-scalable, fully automated, and able to manage high sales volumes and user through-put, while maintaining a low operating overhead.
Having exhausted the available funding and most auspicious "window of opportunity" however, it then became extremely difficult and then impossible to raise additional funds from either current or new investors.
Simply put, this should have been a SaaS play all along, and had this Bessemer rule and several others been applied, the company would have avoided such a significant set-back, and had every chance of succeeding.
Those of us who toil largely on the technical side, depend on the CEO, sales and marketing types to get their fundamental assumptions correct, and to then execute with finesse and determination. Regardless of how great the products we build are, they will not sell if they don't actually align with what the market wants - in terms either of features, performance, cost or method of delivery.
So, while, for Rule # 6, Bessemer focuses largely on sales process refinement and the extent of its funding, I believe that it's worth going back to fundementals, and re-emphasizing the critical nature of getting the product right. There are therefore three aspects to Rule # 6:
- Match the product to the market
While the example I gave above reflects a compounding of errors that is probably unusual, every SaaS product will need some fine-tuning once launched, in order to respond to the actual rather than merely conceptual realities of the wild, both in terms of how well customers are responding to the product, and in terms of how well the platform is delivering it.
It's probable that additional features will begin to make sense, and that some existing features will prove less useful than intended. It's also probable that there will be scaling challenges unique to the particular product.
Essentially, the product and delivery platform will - and should - go through iterations of continual improvement, as it adjusts to the changing marketplace.
Younger companies with fewer resources will probably have less-reliable metrics initially, regarding the specifics of market demand, and so will need to be really diligent at gauging and quickly responding to customer feedback post-launch, and in determining whether they can adequately meet the initial performance demands, when they should scale systems, and in what increments.
This last point is critical, because as Getting Real - the methodology for building SaaS applications formulated by - tells us, it's critical not to scale until you need to.
A young company cannot risk it's resources by building and buying capacity and platform capability on spec, before it has the certainty that can occur only after sufficient customer feedback and performance metrics have been evaluated. The strategy focus has to be on planning for various scaling scenarios - so they can be implemented quickly - and in ensuring that the platform is maximally extensible.
Jeremy Edberg, Reliability Architect at , and formally the Chief Architect at clearly knows about .
He provides valuable insights, at least two of which are immediately relevant.
Firstly, that it's prudent to implement a Service- Oriented Architecture (SOA) , thereby enabling you to access discrete functionality - services - through separate API requests.
Not only is this great for trouble-shooting, because you can more easily isolate issues, even more importantly, it enables you to distribute functionality over a broader system, and to thereby implement, with pin-point accuracy, scaling specifically for those elements that require it, rather than a more costly shotgun approach.
Secondly, it's prudent to let the client do the work as much as and whenever possible, by which is meant that it's a more efficient use of resources when we distribute server requests more evenly by using Ajax request methods after the webpage has loaded in the browser.
This is precisely the method used by , for example.
- Refine the marketing and sales process before scaling it.
Bessemer is an advocate of the Sales Learning Curve (SLC) methodology. The core concept is that expending precious resources on speculative sales efforts, at your most vulnerable time, will generally lead to failure.
Instead, you should initially hire sales reps slowly, and focus only on your single most important locale.
Essentially, you can consider that you have climbed the Sales Learning Curve - your marketing and sales process has reached a satisfactory level of refinement (optimization) - when you have reached at least $300,000 CMRR. Bessemer suggests a maximum of 3 sales reps until then.
You know you can profitably scale sales when a couple of sales reps are at an annualized run rate to sign annual contract values (CMRR x 12 months) equal to twice their fully-burdened cost of sales. For a direct, enterprise sales business model, these thresholds are likely to be around $80,000-100,000 CMRR (approx. $1-1.2M annualized), and for tele-sales [or freemium] models, this may scale down to $60,000-75,000 MRR ($720,000-900,000 annualized).
- Scale the marketing and sales process proportional to its success.
With the metrics in hand that demonstrate the veracity of your marketing and sales process, at what rate should you then scale?
If we refer back to the Customer Acquisition Costs (CAC) metric and formula, we can extrapolate a reasonable sales and marketing budget for the next quarter to equal :
(CAC Payback Period x (New CMRR added in the prior quarter x Gross margin %))
Since we have proposed that a CAC Payback Period of under a year - say, 11 months - is reasonable for a young company, if we generated a CMRR of $100k the last quarter, and our Gross margin is 70%, then it follows that we should be able to safely budget $770k for the next quarter, to spend on sales and marketing.
To Be Continued...
comment by John Godfrey
Great analysis and insights.
Add Your Comment: