Category Archives: SaaS

The Rule of 40 — Down, But Not Out!

Neeraj Agrawal and Logan Bartlett of Battery Ventures recently published the 2019 version of its outstanding annual software round-up report.  I highly recommend this report — it’s 78-pages chock full of great data about topics like:

  • Why Battery is long software overall
  • The four eras of software evolution
  • The five forces driving software’s accelerating growth
  • Key trends in 2018, including setting records in three areas:  (1) public company revenue multiples, (2) IPO volume (by over 2x), and (3) M&A volume (by over 2x).
  • Key trends from their 2017 report that are still alive, well, and driving software businesses.

But, most of all, it has some great charts on the Rule of 40 [1] that I want to present and discuss here.  Before doing that, I must note that I drank today’s morning coffee reading Alex Clayton’s CloudStrike IPO breakdown, a great post about a cloud security company with absolutely stunning growth at scale — 121% growth to $312M in Ending ARR in FY19.  And, despite my headline, well in compliance with the Rule of 40.  110% revenue growth + -26% free cashflow margin = 84%, one of the highest Rule of 40 scores that I’ve ever seen [2].  Keep an eye on this company, I expect it should have a strong IPO [3].

However, finding one superstar neither proves nor disproves the rule.  Let’s turn to the Battery data to do that.

When discussing the Rule of 40, most financial analysts make one of two plots.

  • They do a scatter plot with revenue growth on the X-axis and FCF margin on the Y-axis.  The Rule of 40 then becomes a line that separates the chart into two zones (compliant and non-compliant).  Note that a minority of public companies actually comply suggesting the rule of 40 is a pretty high bar [4].
  • Or, more interestingly, they do a linear regression of Rule of 40 score vs. enterprise-value/revenue (EV) multiple.  This puts focus on the question:  what’s the relationship between Rule of 40 score and company value? [5]

But that thing has always bugged me is that nobody does the linear regression against both the Rule of 40 score and revenue growth.  Nobody, until Battery.  Here’s what it shows.

First, let’s look at the classic Rule of 40 regression.  Recall that R-squared is a statistical measure that explains the dependence of the dependent variable (in this case, EV multiple) on the independent variable (Rule of 40 score).  Here you can see that about 58% of the variation in enterprise value multiple is explained by Rule of 40 score.  You can intuit that by looking at the dots relative to the line — while there is clearly some linear correlation between the data, it’s a long way from perfect (i.e., lots of dots are pretty far from the line).  [6]

rule of 40-4

Now, the fun part.  Let’s see the same regression against revenue growth alone.  R-squared here is 51%.  So the explanatory power of the Rule of 40 is only 7% higher than revenue growth alone.  Probably still worth looking at, but it sure gets a lot of PR for explaining only an incremental 7%.  It could be worse, I suppose.  Rule of 40 could have a lower R-squared than revenue growth alone — in fact, it did back in 2008 and in 2012.

rule of 40-3

In the vein, for some real fun let’s look at how this relationship has changed over time.  The first thing you’ll notice is that pre-2012 both last twelve month (LTM) revenue growth and the Rule of 40 had far weaker explanatory power, I suspect because profitability played a more important role in the equation.  In 2012, the explanatory power of both metrics doubled.  In 2015 and 2016 the Rule of 40 explained nearly 20% more than revenue growth alone.  In 2017 and 2018, however, that’s dropped to 7 to 8%.

rule of 40-2

I still think the Rule of 40 is a nice way to think about balancing growth vs. profit and Rule of 40 compliant companies still command a disproportionate share of market value.  But remember, its explanatory power has dropped in recent years and, if you’re running an early or mid-stage startup, there is very little comparative data available on the Rule of 40 scores of today’s giants when they were at early- or mid-stage scale.  That’s why I think early- and mid-stage startups need to think about the Rule of 40 in terms of glideslope planning.

Thanks to the folks at Battery for producing and sharing this great report. [7]

# # #

Notes
[1] Rule of 40 score = typically calculated as revenue growth + free cashflow (FCF) margin.  When FCF margin is not available, I typically use operating margin.   Using GAAP operating margin here would result in 110% + -55% = 55%, much lower, but still in rule of 40 compliance.

[2] If calculated using subscription revenue growth, it’s 137% + -26% = 111%, even more amazing.  One thing I don’t like about the fluidity of Rule of 40 calculations, as you can see here, is that depending what might seem small nuances in calculations, you can produce a very broad range of scores.   Here, from 55% to 137%.

[3] To me, this means ending day 1 with a strong valuation.  The degree to which that is up or down from the opening price is really about how the bankers priced the offer.  I am not a financial analyst and do not make buy or sell recommendations.  See my disclaimers, here.

[4] In fact, it’s actually a double bar — first you need to have been successful enough to go public, and second you need to clear the Rule of 40.  Despite a minority of public companies actually clearing this bar, financial analysts are quick to point out the minority who do command a disproportionate share of market cap.

[5] And via the resultant R-squared score, to what extent does the Rule of 40 score explain (or drive) the EV/R multiple?

[6] If R-squared were 1.0 all the dots would fall on the least-squares fit line.

[7] Which continues with further analysis, breaking the Rule of 40 into 4 zones.

What's the "Cause of Death" in Your Churn Reporting?

In looking at this issue across several companies, I’ve noticed a disturbing trend / missed opportunity in how many SaaS companies classify the reason for customer churn.  Roughly speaking, if companies were hospitals, they’d too frequently be reporting the cause of death as “stopped breathing.”
Yes, the patient who died stopped breathing; the question is why did they stop breathing.  In churn-speak, “yes, the customer who churned issued a churn notice and chose not to renew.”  The question is why did they choose not to renew?
Many people have written great posts on reasons customers churn and how to prevent them.  These reasons often look like hierarchies:
Uncontrollable:

  • Got acquired
  • Went bankrupt
  • Corporate edict
  • New sponsor

Controllable:

  • Failed implementation
  • Product functionality
  • Product ease of use
  • Oversold  / poor fit

These hierarchies aren’t a bad start, but they aren’t good enough, either.  A new sponsor isn’t an automatic death sentence for a SaaS product.  He or she might be, however, if the team using it had a rough implementation and was only half-satisfied with the product.  Similarly, a failed implementation will certainly reduce the odds of renewal, but sometimes people do have the will to start over — and why did the implementation fail in the first place?
Physicians have been in the “churn” business much longer than SaaS companies and I think they’ve arrived at a superior system.  Here’s an excerpt from the CDC’s Physicians’ Handbook on Medical Certification of Death — not a publication, I’d add, linked to by most SaaS bloggers:
chain of death
For example, when my dear father passed away from a stroke several years ago, I remember the form said:
example cod
(And, at the time, literally observing that it was a better way to classify churn.)
The rule above spells it out quite clearly  — “DO NOT enter terminal events such as respiratory arrest […] without showing the etiology.”  That is, “stopped breathing” by itself isn’t good enough.  Just like “sent churn notice” or “decided not to renew.”
I have not built out a full taxonomy here; classifying churn in this way remained a future item on my to-do list at the time we sold my last company.  Nevertheless, while I know it’s not easy, I believe that companies should start trying to find a way to richly encode churn reasons using this “chain” concept so as to not lose critical information in encoding their data.  Otherwise, we risk believing that all our customers churned because they sent us a churn notice (or some easily blamed “uncontrollable” event).
As one example:

  • Churned, due to
  • New sponsor, due to
  • Failed implementation, due to
  • Partner problem, due to
  • Partner training

Or, another:

  • Churned, due to
  • Corporate edict, due to
  • M&A, due to
  • Product dissatisfaction, due to
  • Oversold, due to
  • Sales training

These aren’t perfect, but I’m trying quickly demonstrate the real complexity behind why customers churn.  For example, happy customers might challenge a corporate edict issued after an acquisition — so you can’t just blame the edict.  You have to look more deeply.  If you knew that the customer fought the edict and failed, you might stop the chain there.  But if you knew they were never terribly happy with the system because they were overpromised capabilities at the start, then you should code that into the chain, too.

# # #

For more information on the warning signs and symptoms of a stroke, go here.
 

What’s the “Cause of Death” in Your Churn Reporting?

In looking at this issue across several companies, I’ve noticed a disturbing trend / missed opportunity in how many SaaS companies classify the reason for customer churn.  Roughly speaking, if companies were hospitals, they’d too frequently be reporting the cause of death as “stopped breathing.”

Yes, the patient who died stopped breathing; the question is why did they stop breathing.  In churn-speak, “yes, the customer who churned issued a churn notice and chose not to renew.”  The question is why did they choose not to renew?

Many people have written great posts on reasons customers churn and how to prevent them.  These reasons often look like hierarchies:

Uncontrollable:

  • Got acquired
  • Went bankrupt
  • Corporate edict
  • New sponsor

Controllable:

  • Failed implementation
  • Product functionality
  • Product ease of use
  • Oversold  / poor fit

These hierarchies aren’t a bad start, but they aren’t good enough, either.  A new sponsor isn’t an automatic death sentence for a SaaS product.  He or she might be, however, if the team using it had a rough implementation and was only half-satisfied with the product.  Similarly, a failed implementation will certainly reduce the odds of renewal, but sometimes people do have the will to start over — and why did the implementation fail in the first place?

Physicians have been in the “churn” business much longer than SaaS companies and I think they’ve arrived at a superior system.  Here’s an excerpt from the CDC’s Physicians’ Handbook on Medical Certification of Death — not a publication, I’d add, linked to by most SaaS bloggers:

chain of death

For example, when my dear father passed away from a stroke several years ago, I remember the form said:

example cod

(And, at the time, literally observing that it was a better way to classify churn.)

The rule above spells it out quite clearly  — “DO NOT enter terminal events such as respiratory arrest […] without showing the etiology.”  That is, “stopped breathing” by itself isn’t good enough.  Just like “sent churn notice” or “decided not to renew.”

I have not built out a full taxonomy here; classifying churn in this way remained a future item on my to-do list at the time we sold my last company.  Nevertheless, while I know it’s not easy, I believe that companies should start trying to find a way to richly encode churn reasons using this “chain” concept so as to not lose critical information in encoding their data.  Otherwise, we risk believing that all our customers churned because they sent us a churn notice (or some easily blamed “uncontrollable” event).

As one example:

  • Churned, due to
  • New sponsor, due to
  • Failed implementation, due to
  • Partner problem, due to
  • Partner training

Or, another:

  • Churned, due to
  • Corporate edict, due to
  • M&A, due to
  • Product dissatisfaction, due to
  • Oversold, due to
  • Sales training

These aren’t perfect, but I’m trying quickly demonstrate the real complexity behind why customers churn.  For example, happy customers might challenge a corporate edict issued after an acquisition — so you can’t just blame the edict.  You have to look more deeply.  If you knew that the customer fought the edict and failed, you might stop the chain there.  But if you knew they were never terribly happy with the system because they were overpromised capabilities at the start, then you should code that into the chain, too.

# # #

For more information on the warning signs and symptoms of a stroke, go here.

 

My Final Verdict on Multi-Year, Prepaid Deals

(Revised 5/4/19, 10:41 AM.)

After years of experience with and thinking about multi-year, prepaid SaaS deals, my mental jury is back in the box and the verdict is in:  if you’re a startup that is within my assumption set below, don’t do them.

Before jumping in, let me first define precisely what I mean by multi-year, prepaid deals and second, detail the assumptions behind my logic in response to some Twitter conversations I’ve had this morning about this post.

What do I Mean by Multi-Year Prepaid Deals?
While there are many forms of “multi-year prepaid deals,” when I use the term I am thinking primarily of a three-year agreement that is fully prepaid.  For example, if a customer’s ARR cost is 100 units for a one-year deal, you might approach them saying something akin to:

By default, our annual contracts have a 10% annual increase built in [1].  If you sign and prepay a three-year agreement, i.e., pay me 300 units within 60 days, then I will lock you in at the 100 units per year price.

Some people didn’t know these kinds of deals were possible — they are.  In my experience, particularly for high-consideration purchases (where the customer has completed a thorough evaluation and is quite sure the system will work), a fairly high percentage of buyers will engage in this conversation.  (In a world where companies have a lot of cash, a 10% return is a lot better than bank interest.)

Multi-year prepaid deals can take other forms as well:

  • The duration can vary:  I’ve seen anything from 2 to 7 years.
  • The contract duration and the prepaid duration can decouple:  e.g., a five-year deal where the first three years are prepaid.

But, to make it simple, just think of a three-year fully prepaid deal as the canonical example.

What are My Underlying Assumptions?
As several readers pointed out, there are some very good reasons to do multi-year prepaid deals [11].  Most of all, they’re a financial win/win for both vendor and customer:  the customer earns a higher rate of return than bank interest and the vendor gets access to capital at a modest cost.

If you’re bootstrapping a company with your own money, have no intention to raise venture capital, and aren’t concerned about complicating an eventual exit to a private equity (PE) or strategic acquirer, then I’d say go ahead and do them if you want to and your customers are game.

However, if you are venture-backed, intend to raise one or more additional rounds before an exit, and anticipate selling to either a strategic or private equity acquirer, then I’d say you should make yourself quite familiar with the following list of disadvantages before building multi-year prepaid deals into your business model.

Why do I Recommend Avoiding Multi-Year Prepaid Deals?
In a phrase, it’s because they’re not the norm.  If you want to raise money from (and eventually sell to) people who are used to SaaS businesses that look a certain way — unless you are specifically trying to disrupt the business model — then you should generally do things that certain way.  Multi-year prepaid deals complicate numerous things and each of those complications will be seen not as endemic to the space, but as idiosyncratic to your company.

Here’s the list of reasons why you should watch out.  Multi-year prepaid deals:

  • Are not the norm, so they raise eyebrows among investors and can backfire with customers [2].
  • Complexify SaaS metrics.  SaaS businesses are hard enough to understand already.  Multi-year deals make metrics calculation and interpretation even more complicated.  For example, do you want to argue with investors that your CAC payback period is not 18 months, but one day?  You can, but you’ll face a great risk of “dying right” in so doing. (And I have done so on more than one occasion [3]).
  • Amplify churn rates. An annual renewal rate [4] of 90% is equivalent to a three-year renewal rate of 72%.  But do you want to argue that, say, 79% is better than 90% [5] or that you should take the Nth root of N-year renewal rates to properly compare them to one-year rates?  You can, but real math is all too often seen as company spin, especially once eyebrows are already raised.
  • Turn your renewals rate into a renewals matrix.  Technically speaking, if you’re doing a mix of one, two, and three-year deals, then your renewal rate isn’t a single rate at all, but a matrix.  Do you want to explain that to investors?

renewals matrix

  • Tee you up for price knock-off at sales time.  Some buyers, particularly those in private equity (PE), will look at the relatively large long-term deferred revenue balance as “cashless revenue” and try to deduct the cost of it from an acquisition price [6].  Moreover, if not discussed up front, someone might try to knock it off what you thought was a final number.
  • Can reduce value for strategic acquirers.  Under today’s rules, for reasons that I don’t entirely understand, deferred revenue seems to get written off (and thus never recognized) in a SaaS acquisition.  So, ceteris paribus, an acquirer would greatly prefer non-prepaid TCV (which it will get to recognize over time) to deferred revenues (which it won’t) [7].
  • Can give pause to strategic acquirers.  Anything that might cause the acquirer to need to start release pro forma financials has the potential to scare them off, particularly one with otherwise pristine financial statements.  For example, having to explain why revenue from a recently acquired startup is shrinking year-over-year might do precisely that [8].
  • Can “inflate” revenues.  Under ASC 606, multi-year, prepaid deals are seen as significant financing events, so — if I have this correct — revenue will exceed the cash received [9] from the customer as interest expense will be recorded and increase the amount of revenue.  Some buyers, particularly PE ones, will see this as another form of cashless revenue and want to deflate your financials to account for it since they are not primarily concerned with GAAP financials, but are more cash-focused.
  • Will similarly inflate remaining performance obligation (RPO).  SaaS companies are increasingly releasing a metric called RPO which I believe is supposed to be a more rigorous form of what one might call “remaining TCV (total contract value)” — i.e., whether prepaid or not, the value of remaining obligations undertaken in the company’s current set of contracts.  If this is calculated on a GAAP basis, you’re going to have the same inflation issue as with revenues when multi-year, prepaid deals are involved.   For example, I think a three-year 100-unit deal done with annual payments will show up as 200 units of RPO but the same deal done a prepaid basis will show up as 200-something (e.g., 210, 220) due to imputed interest.
  • Impede analysis of billings. If you want to go public or get acquired by a public company, financial analysts are going to focus on a metric called calculated billings [10] which is equal to revenue plus the change in deferred revenue for a given time period.  For SaaS purist companies (i.e., those that do only annual contracts with one-year prepays), calculated billings is actually a pretty good measure of new sales.  Multi-year prepays impede analysis of billings because deferred revenue ends up a mishmash of deals of varying lengths and is thus basically impossible to interpret [11].  This could preclude an acquisition by a SaaS purist company [12].

More than anything, I think when you take these factors together, you can end up with complexity fatigue which ultimately takes you back to whether it’s a normal industry practice.  If it were, people would just think, “that’s the complexity endemic in the space.” If it’s not, people think, “gosh, it’s just too darn hard to normalize this company to the ones in our portfolio [13] and my head hurts.”

Yes, there are a few very good reasons to do multi-year, prepaid deals [14], but overall, I’d say most investors and acquirers would prefer if you just raised a bit more capital and didn’t try to finance your growth using customer prepayments.  In my experience, the norm in enterprise software is increasingly converging to three-year deals with annual payments which provide many of the advantages of multi-year deals without a lot of the added complexity [15].

# # #

Notes

[1] While 10% is indeed high, it makes the math easier for the example (i.e., the three-year cost is 331 vs. 300).  In reality, I think 5-6% is more reasonable, though it’s always easier to reduce something than increase it in a negotiation.

[2] Especially if your competition primes them by saying — “those guys are in financial trouble, they need cash, so they’re going to ask you for a multi-year, prepaid deal.  Mark my words!”

[3] Think:  “I know the formula you’re using says ’18 months’ but I’m holding an invoice (or, if you wait 30 days, check) in my hand for more than the customer acquisition cost.”  Or, “remember from b-school that payback periods are supposed to measure risk, no return, and to do so by measuring how long your money is on the table.”  Or, “the problem with your formula is you’re producing a continuous result in a world where you actually only collect modulo 12 months — isn’t that a problem for a would-be ‘payback’ metric?”

[4] Renewal rate = 1 – churn rate

[5] That is, that a 79% three-year rate is ergo better than a one-year 90% renewal rate.

[6] Arguing that while the buyer will get to recognize the deferred revenue over time that the cash has already been collected, and ergo that the purchase price should be reduced by the cost of delivering that revenue, i.e., (COGS %) * (long-term deferred revenue).

[7] Happily, the deferred revenue write-down approach seems to be in the midst of re-evaluation.

[8] If the acquired company does a high percentage of multi-year, prepaid deals and you write off its deferred revenue, it will certainly reduce its apparent growth rate and possibly cause it to shrink on a year-over-year basis.  What was “in the bag revenue” for the acquired company gets vaporized for the acquirer.

[9] Or our other subsidiaries, for a strategic acquirer.

[10]  Known either as billings or calculated billings.  I prefer the latter because it emphasizes that it’s not a metric that most companies publish, but one commonly derived by financial analysts.

[11] We are testing the limits of my accounting knowledge here, but I suppose if deferred revenue is split into current and long-term you might still be able to get a reasonable guestimate for new ARR sales by calculating billings based only on current, but I’m not sure that’s true and worry that the constant flow from long-term to current deferred revenue will impede that analysis.

[12]  A purist SaaS company — and they do exist — would actually see two problems.  First, potential year-over-year shrinkage due to the write-down discussed in footnote [7].  Second, they’d face a dilemma in choosing between the risk associated with immediately transitioning the acquired company’s business to annual-only and the potential pollution of its otherwise pristine deferred revenue if they don’t.

[13] Minute 1:28 of the same video referenced in the prior link.

[14] Good reasons to do multi-year, prepaid deals include:  (a) they are arguably a clever form of financing using customer money, (b) they tend to buy you a second chance if a customer fails in implementation (e.g., if you’ve failed 9 months into a one-year contract, odds are you won’t try again — with a three-year, prepay you might well), (c) they are usually a financing win/win for both vendor and customer as the discount offered exceeds the time value of money.

[15] You do get one new form of complexity which is whether to count payments as renewals, but if everyone is doing 3-year, annual payment deals then a norm will be established.

Is Another SaaSacre In The Offing?

I’m not a financial analyst and I don’t make stock recommendations [1], but as a participant and observer in the software investing ecosystem, I do keep an eye on macro market parameters and I read a fair bit of financial analyst research.  Once in an while, I comment on what I’m seeing.

In February 2016, I wrote two posts (SaaS Stocks:  How Much Punishment is in Store and The SaaSacre Part II:  Time for the Rebound?).  To remind you how depressed SaaS stocks were back then:

  • Workday was $49/share, now at $192
  • Zendesk was $15/share, now at $85
  • ServiceNow was $47/share, now at $247
  • Salesforce was $56/share, now at $160

Those four stocks are up 342% over the past 3 years and two months.  More broadly, the Bessemer Emerging Cloud Index is up 385% over the same period.  Given the increase, a seemingly frothy market for stocks (P/E of the S&P 500 at ~21), and plenty of global geopolitical and economic uncertainty, the question is whether there is another SaaSacre (rhymes with massacre) in the not-too-distant future?

Based just on gut feel, I would say yes.  (Hence my Kellblog prediction that markets would be choppy in 2019.)  But this morning, I saw a chart in a Cowen report that helped bring some data to the question:

cowen

I wish we had a longer time period to look at, but the data is still interesting.  The chart plots enterprise value (EV) divided by next twelve month (NTM) sales.  As a forward multiple, it’s already more aggressive than a trailing twelve month (TTM) multiple because revenue is growing (let’s guess 25% to 30% across the coverage universe), thus the multiple gets deflated when looking forward as opposed to back.

That said, let’s look at the shape of the curve.  When I draw a line through 7x, it appears to me that about half the chart is above the line and half below, so let’s guesstimate that median multiple during the period is 7x.  If you believe in regression to the mean, you should theoretically be a bearish when stocks are trading above the median and bullish when they’re below.

Because the average multiple line is pretty thick, it’s hard to see where exactly it ends, but it looks like 8.25x to me.  That means today’s multiples are “only” 18% above the median [2].  That’s good news, in one sense, as my gut was that it would be higher.  The bad news is:  (1) when things correct they often don’t simply drop to the line but well through it and (2) if anything happens to hurt the anticipated sales growth, the EV/NTM-sales multiple goes up at constant EV because  NTM-sales goes down.  Thus there’s kind of a double whammy effect because lower future anticipated growth increases multiples at a time when the multiples themselves want to be decreasing.

This is a long way of saying, in my opinion, as a chartist [3] using this chart, I would conclude that multiples are somewhat frothy, about 20% above the median, with a lot predicated on future growth.

This exercise shows that looking only at price appreciation presents a more dangerous-looking picture than looking at prices as related to revenues:  looking across the whole chart, prices are up a lot since April 2014 but so are forward-looking revenues, and the multiple is roughly the same at the start as at the end:  8x. [4]  Looking at things differently, of the ~350% gain since April 2016, half is due to multiple expansion (from a way-below-median ~4x to an above-median ~8x), and half is to stock revenue growth.

For me, when I look at overall markets (e.g., PE of the S&P), geopolitical uncertainty, price appreciation, and SaaS multiples, I still feel like taking a conservative position.  But somewhat less than so than before I saw this chart.  While it’s totally subjective:  SaaS is less frothy than I thought when looking only at price appreciation.

Switching gears, the same Cowen report had a nice rule of 40 chart that I thought I’d share as well:

r40 cowen

Since the R^2 is only 0.32, I continue to wonder if you’d get a higher R^2 using only revenue growth as opposed to rule of 40 score on the X axis.  For more on this topic, see my other Rule of 40 posts here.

# # #

Notes
[1] See disclaimers in my FAQ and terms of use in the blog license agreement.

[2] Nevertheless, 18% is a lot to lose if multiples instantly reset to the median.  (And they often don’t just drop to the median, but break well through it — e.g., in Jan 2016, they were as low as 4x.)

[3] And chartism doesn’t work.

[4] If you ignore most of the first month where it appeared to be falling from 10x to 8x.

Are You Counting Payments as Renewals?

Enterprise SaaS has drifted to a model where many, if not most, companies do multi-year contracts on annual payment terms.  How did we get here?

  • Most enterprise SaaS products are high-consideration purchases. Buyers typically perform a thorough evaluation process before purchasing and are quite sure that the software will meet their needs when they deploy.  These are not try-and-buy or wing-it purchases.
  • Most SaaS vendors will jump at the opportunity to lock in a longer subscription term. For example, with an 85% gross retention rate you can offer a 5% discount for a two-year contract and end up mathematically ahead [1].  Moreover, with a default annual increase of 5 to 10% built into your standard contact, you can offer a “price lock” without any discount at all (i.e., the customer locks in the price for two years in exchange for a two-year commitment).

When you combine the vendor’s desire to lock in the longer term with the customer’s belief that the solution is going work, you find a fertile ground for doing two- or three-year contracts.  But these multi-year deals are almost always done on annual payment terms.

Most SaaS vendors don’t want to take the next step and ask for a multi-year prepayment.  The upside for the vendor would be to eliminate the need for collections in years 2 and 3, and eliminate the chance that the customer — even if unhappy — won’t make the out-year payments.  But most vendors refrain from this because:

  • It’s seen as an unusual practice that’s frowned upon by investors
  • Most investors believe you could better maximize ARR by simply raising more capital and sticking with annual payments
  • It can lead to lumpy renewals and cash flows that are both hard to manage and understand
  • It can lead to large long-term deferred revenues which can hinder certain M&A discussions.  (Think:  large balance of cashless revenue from suitor’s perspective.)
  • It complicates the calculation of SaaS metrics, sometimes confusing investors into believing that good metrics are bad ones. (I think I am literally the only person in Silicon Valley who is quick to point out that a 75% three-year retention rate is better than a 90% one-year one [2].)

Thus, we end up in a situation where the norm has become a two- or three-year contract with annual payments.  This begs a seemingly simple “if a tree falls in the forest and no one hears it, did it make any noise” kind of question:

Quick, what’s the difference between a one-year contract that’s renewing for the first time and a three-year contract that’s coming up for its first downstream annual payment?

I’ve often quipped that they’re both “renewals,” but in the former case they’re handled Customer Success and in the latter they’re handled by Legal. [3]

But let’s be clear, regardless of the process you use to manage them [4], they are not the same, and should not automatically be treated as such for the purposes of calculating SaaS metrics. One is the voluntary renewal of a subscription contract; the other is the payment of a contractual commitment.

If you don’t want to renew your subscription, there’s nothing I can do to force you.  If you don’t want to make a contractually committed payment I can sue you.

Let’s consider an example.  We have six customers, Alpha through Foxtrot.  The first three did one-year deals, the second three did three-years deals.  The simple question is:  what’s your gross dollar retention?  A merely acceptable 83% or a very healthy 95%?

payment renewal

If you calculate on an available-to-renew (ATR) basis, the rate is 83%.  There were 300 units up for renewal and you renewed 250 of them.  If you include the payments, the rate is 95%.  1,050 units were up for renewal or payment, and you invoiced 1,000.

This is a case that feels a little bit wrong both ways.  Including the payments uplifts the rate by mixing involuntary payments with voluntary renewals; to the extent you want to use the rate as a satisfaction indicator, it will be over-stated [5].  However, excluding the payments seems to fail to credit the company with the auto-renewing nature of multi-year deals.

One thing is clear:  payments certainly cannot be included in any ATR-based rate.  You cannot view making a contractually required payment as the same thing as voluntarily renewing a contract. 

Because of prepaid multi-year deals, I have always calculated retention rates two ways:  ATR-based and ARR-based.  The former is supposed to give you an idea of how often, given the chance, people want to renew their contacts.  The latter is supposed to show you, mathematically, what’s happening to your ARR pool [6].

I have an issue, which is highly subjective, when it comes to out-payments on non-prepaid, multi-year deals:

  • On one hand, I can argue they are contractual commitments that the vast majority of customers will honor and thus are effectively – save for a few rare cases – identical to prepaid multi-year deals. Think:  the money’s good as in the bank.
  • On the other hand, I can argue that a dissatisfied customer – particularly one who blames the vendor and/or the software for their failure – will not want to pay, even if the contract says they’re supposed to. Think:  it’s a toothless contract that the vendor will not likely not enforce against an angry customer.

Philosophically, I can argue that these out-year payments are either “good as in the bank” or I can argue that they’re “basically renewals that will ‘churn’ if the customer is not happy.”  The first argument says to treat them like prepaid multi-year deals and put them in ARR-based retention rates.  The second argument says they’re effectively voluntary renewals and should be counted as such.

In reality, you need to know what happens at your business.

I believe for the vast majority of businesses, customers honor the contracts and we should treat them like prepaid, multi-year deals in ARR-based rates — and you should always publish in parallel ATR-based rates, so people can see both.  However, if your company is an outlier and 10% of those payments are never collected, you’re going to need to look at them differently – perhaps like renewals because that’s how they’re behaving.  Or get better lawyers.  Or stop doing non-prepaid, multi-year deals because, for whatever reason, your customers are not honoring the commitment they made in exchange for you to give them a price lock.

# # #

Notes

[1] Over 2 years you get 190 units versus an expected 185.  (Not counting any expansion.)

[2] 0.75 > 0.9^3 = 0.73 – you need to compound annual rates to compare them to multi-year ones.

[3] Or, really, Accounts Receivable but that doesn’t sound as funny.

[4] I’d argue that when you define your customer success process that you should treat these two customers identically.  Whether it’s a payment or a renewal, in a good customer success process you should constantly monitor customer progress with the hope that the renewal (or the payment) is not some big decision, but merely incidental.  (“Yes, of course, we want to keep using the software – is it just a payment year or do we need to renew the contract?”)  This might increase your cost to renew a bit – because you’ll be paying CSMs or renewals reps to do collection work that could theoretically have been done by Accounts Receivable – but it’s still the right answer if you want to maximize ARR.

[5] While payment does not necessarily indicate satisfaction, it probably does indicate the absence of intense dissatisfaction.

[6] e.g., I’d use the the churn rate (1 minus the retention rate) as the discount rate in a present value calculation.

What It Takes to Make a Great SaaS Company

I’ve been making a few presentations lately, so I thought I’d share the slides to this deck which I presented earlier this week at the All Hands meeting of a high-growth SaaS company as part of their external speaker series.

This one’s kind of a romp — it starts with some background on Kellblog (in response to some specific up-front questions they had), takes a brief look back at the “good old days” of on-premises software, introduces my leaky bucket concept of a SaaS company, and then discusses why I need to know only two things to value your SaaS company:  the water level of your bucket and how fast it’s increasing.

It kind of runs backwards building into the conclusion that a great SaaS company needs four things.

  1. An efficient sales model.  SaaS companies effectively buy customers, so you need to figure out how to do it efficiently.
  2. A customer-centric culture.  Once you’ve acquired a customer your whole culture should be focused on keeping them.  (It’s usually far cheaper than finding a new one to back-fill.)
  3. A product that gets the job done.  I like Clayton Christensen’s notion that customers “hire products to do jobs for them.”  Do yours?  How can you do it better?
  4. A vision that leaves the competition one step behind.  Done correctly, the competition is chasing your current reality while you’re out marketing the next level of vision.

Here are the slides: