Slides from my SaaStock Dublin Presentation on GTM Efficiency

Just a quick post to share the slides I presented at SaaStock Dublin today on driving go-to-market (GTM) efficiences over the coming 24 months.  I chose this topic because extending runway is on everyone’s mind and — because it’s usually the single largest contributor to overall operating expense — sales & marketing (S&M) is where companies turn to do so.

After a brief review of the problem, I look at two popular approaches that don’t work:

  • The Excel-induced hallucination, where you make seemingly small but unsupported tweaks to your GTM funnel model that result in massive (and totally unrealistic) productivity gains.
  • Everyone for themselves!  A Lord of the Flies approach, which sales usually wins, resulting in too many mouths to feed with too few supporting resources.

Newly hired sales reps waiting for pipeline

What does is work is to adopt a three-musketeers attitude across sales, marketing, customer success, and professional services.  (Yes, there actually were four muskeeters; they picked up d’Artagnan along the way.)

All for one and one for all to maximize ARR

I then run through a punch list of ideas, some obvious and some less so, structured in four groups, about how you can drive GTM efficiency:

  • Work better together
  • Shoot at richer targets
  • Forward-deploy more resources
  • Improve operating efficiency

The slides are embedded below.  Note that the Slideshare previewer sometimes doesn’t mix well with the Balderton fonts, so I uploaded only a PDF to Slideshare.  If you want it in PowerPoint, go to Google drive here.

 

 

The Mental Mapping from Annual to Monthly and Usage-Based SaaS Metrics

A guy walks into a bar and orders a $17 Martini.  Is it MRR (monthly recurring revenue)?

The potentially surprising answer:  maybe, and often yes.

  • If he’s a tourist who happened to walk in, then no, it’s not MRR.
  • If he’s lived here for two years and comes in every Thursday for a Martini, yes.  He represents $68 of what I’d call empirical MRR [1].
  • If he just moved in next door, says every Thursday he drinks a Martini, and he’s selected our bar as his new spot, then I’d also say yes.  I might call this intentional MRR, much like signing up for a SaaS service on a month-to-month basis [2].
  • If the bar’s in a club with a $2000 annual membership and a quarterly food and beverage (F&B) minimum of $221, I’d say yes.  It’s contractual MRR.  I’d probably even call it $2,884 of ARR, not MRR, to reflect the annual nature of the contract [3].

I’m writing this post to help readers who (like me) grew up in an annual subscription SaaS world adapt to the new and increasingly popular world of usage-based pricing [4], including month-to-month contracts and variable fees [5].

In this new world, people still use terms like ARR and MRR.  For example:

SaaStr Discussing Snowflake’s ARR

Meritech Showing Implied ARR

But what does this mean in a usage-based world?  Specifically, what does “recur” mean?  Why does the phrase “recurring revenue” appear exactly zero times in Snowflake’s 10-Q?

And what’s the impact on your other SaaS metrics?  What’s your CAC ratio if I don’t know what your ARR is because I don’t know what the recurring means?  What’s your churn rate? What if a customer fluctuates across months: do I count churn each month they shrink and expansion each month they expand?  If ARR is a forward-looking metric [6], what do ARR-based metrics like net dollar retention (NDR) mean [7] in a world without fixed forward commitments?

What Does Recur Mean?
So many questions.  But since I like to start with the basics, let’s go back to our bar and think about Martinis and the meaning of the word recur.  In the annual world, “recur” seemed pretty clearly defined.  Unlike perpetual software license revenue, which was largely one-shot in nature [8], SaaS subscription revenue would recur.  A customer would purchase a subscription to a service for a time period.  At the end of the period the customer could, and usually would, renew the subscription to the service.  Hence, the revenue recurred.

The subscription period varied typically as a function of contract size and target market.  A $200/month product might have a month-to-month contract with monthly billing, whereas a $2,000/month product might have an annual contract with up-front billing, and a $20,000/month product might have a three-year contract with annual billing [9] [10].

The important point here seems forgotten by time:  recur didn’t mean a company gets $10K per month from a $120K annual contract [11].  Recur meant the $120K contract had a fixed duration and periodically came up for renewal [12].  Recur never meant contractual.  The revenue didn’t recur contractually across contract periods.  The fact that it might, however — unlike perpetual license — meant that it recurred.

I’ll say it again.  Recur never meant contractual.  Which is why I think the Martini revenue in the second and third examples is MRR.  There’s no contract that says the guy has to come in every Thursday.  But, empirically, he does.  There’s no binding commitment that our new neighbor will come in every Thursday going forward, but he said he would.  That’s as “recurring” as an annual SaaS renewal.

The Usage-Based Model
To make our Martini bar more reflective of usage-based SaaS, let’s change our example a bit:

  • After a few trial visits, you are no longer admitted to the bar until you sign a contract.
  • The bar sells credits, which you can buy purely à la carte but they now cost $20.
  • If you buy 20 credits or more, they cost $17.  More volume discounts exist beyond that.
  • Overage credits can be purchased at $19, a price designed to incent purchasing more regular credits up front, possibly even hitting the next discount level where they are $16.
  • Unlike many other bars [13], unused credits may be rolled over into the next year’s agreement.

Our customer signs a deal for 52 credits at $884 to cover his weekly Martini.  Some weeks he either brings a friend or has a hamburger and spends two credits, so his monthly credit usage ends up looking like this:

He’s spent 32 credits in the first half of 2022, on pace to spend 64 on the year, well above his 52 credit plan.

What is the MRR?
If you come from the annual world, you might be tempted to break the 52 purchased credits across the year (especially if they don’t rollover) and say his baseline spend is one credit per week, thus 4.3 per month.  At $17/credit, that’s MRR of $73.66.  But he spent 15 credits in 1Q, so you might bill him for 2 overage credits ($38) and then spread that across the three months to arrive at MRR of $86.30.

I think the psychological issue here is that you’re fighting to stay in the MRR mindset, thus allocating the credits by month, and then applying overages as you go along.  You’re doing that, I believe, because you view the baseline as “recurring,” but not the overage.  You’re stuck on MRR, and that’s potentially based on the faulty notion of recurring that’s discussed above.  Now imagine doing this with multiple products and a hybrid pricing model that includes both monthly subscriptions and multiple different consumption fees (e.g., compute, storage, API calls).

Trailing Spend Calculations to the Rescue
Let’s send in the external financial reporting team to save us.  What do they see?  Simple.  They see quarterly revenue of 15 credits x $17/credit = $255 in 1Q22. They would not report it as baseline and overage revenue, but aggregate it to F&B revenue [14].

This is a better way to view things.  The problem is less that it’s usage-based pricing and more that it’s monthly-varying pricing.  Much like our bar, a customer’s monthly spend bounces around so we’re never quite sure what’s fluctuation vs. churn/expansion and we don’t know what they’re going to spend in the future.  MRR thus becomes an inferior unit to quarterly spend.

What is the Net Expansion?
When we think about expansion (or churn) let’s stick with trailing spend and not fuss about trying to first calculate MRR and then see how it changes.  With that in mind, what is customer A’s net expansion in 2Q22?  $34, right?  He spent $289 in 2Q22 and $255 in 1Q22, and the difference is $34.

Wrong.  At least in the traditional SaaS world where the correct answer is unknown.  Why?  Because we don’t have last year’s 2Q21 data in the spreadsheet and in the traditional SaaS world, churn is a year-over-year metric [15].  Monthly SaaS tends to silently slip your brain into a quarter-over-quarter mindset, as you see with metrics like lazy NRR, which is quarterly, compared to NRR, which is annual [16].  Note that this is not a bad thing — in the usage-based world, you need to watch customers and their usage like a hawk — it’s just a different thing if you grew up in the annual SaaS world.

Let’s provide the 1Q21 data we need and then answer the question.

Customer A used 13 credits in 2Q21 and 17 units in 2Q22, so he expanded by 4 units.  But, he negotiated a better price per credit in 2022 ($17 instead of $18) so his spend went from $234 in 2Q21 to $289 in 2Q22, an expansion of $55, reflecting a net expansion rate of 124%.  Had the customer’s spend been the other way around and shrunk to $234 from $289, it would be churn of $55, reflecting a churn rate of 19%, or a net expansion rate of 81% [17].

What is Net Revenue Retention?
Isn’t net expansion rate the same thing as NRR?  Well, as I’m using the terms here, no.  Above, we calculated net expansion rate using year-over-year quarterly spend.  In the traditional world, NRR is supposed to be a year-over-year ARR comparison.  But in the monthly SaaS world, we don’t really have ARR [18], so what can we do?

We can rely on trailing spend calculations to save the day.  For example, we can define NRR, as Snowflake does, to be trailing one-year spend divided by trailing year-before-that spend for customers who started on or before the first month of the year-before-that period.  Here’s how Snowflake says that:

We need more data in our Martini bar example to calculate NRR, so here it is:

Let’s calculate NRR for customer A as of 12/31/22 using the Snowflake NRR formula.  In the trailing year (2022), he spent $1,131.  In the year before that (2021), he spent $936.  Thus NRR is 121% (= 1311/936).

Please note that this makes NRR — and every other metric that substitutes trailing spend for ARR/MRR — more backward looking than their ARR/MRR counterparts.  Why?  Because in an annual subscription world, NRR would compare 2023 to 2022, not 2022 to 2021.  That is, NRR would compare the ARR value of the renewal we signed on 12/31/22 for the coming year (2023) to the one we signed on 12/31/21 for the then-coming year (2022).

Before moving to other topics, let’s quickly review how other leaders calculate NRR.  Twilio defines NRR in line with how I defined net expansion rate, above (i.e., quarter over prior-year quarter).  Note that, oddly, when calculating it for a year instead of comparing two trailing 12-month periods, they instead use a (presumably unweighted) average of the quarterly rates.

Datadog, often described as a usage-based pricing leader (e.g., in the OpenView Usage-based Playbook) seems to rely more heavily on subscriptions than the hype suggests.

Datadog calculates NRR using a rather traditional ARR-based formula.

Finally, Hashicorp, a company known for both land-and-expand and usage-based pricing, defines NRR as follows, which includes their definition of ARR (which is roughly annualized spend):

So, basically, in a monthly or usage-based SaaS world where ARR doesn’t really exist, you can either look at trailing spend or annualizing periods.  And, as we’ve seen, there really aren’t any standards here so caveat emptor when comparing the NRR reported by different companies.  Personally, in the absence of actual ARR, I prefer tracking actual spend as it reduces the risk associated with annualizing seasonally strong (or weak) periods and getting an over- or under-stated result [19].

What is Implied ARR?
All public SaaS companies report revenue.  Few report ARR.  Thus, long ago public investors and financial analysts created new SaaS metrics to try and approximate the SaaS leaky bucket:

  • Implied ARR, which estimates the size of the ARR pool and is calculated by multiplying last-quarter’s (subscription) revenue by 4 [20].
  • Billings.  Revenue plus change in deferred revenue, which is designed to estimate bookings (i.e., new sales).  If payment terms and contract lengths are constant, this one works pretty well, but can break when they’re not.

You might wonder, in a monthly or usage-based SaaS world, if you couldn’t just use implied ARR and then calculate SaaS metrics like the CAC ratio off that.  Sometimes the answer is yes:  CAC ratio (and magic number) and CAC Payback Period are often calculated off changes in implied ARR.  Sometimes the answer is no:  you can’t do NRR because you can’t get the cohorts, and you can’t do churn rates because you don’t see the offsets between new-logo, expansion, and churn ARR.  But the real reason is that these tend to be investor metrics, not calculated by public companies but calculated for (or about) them by financial analysts.  Internally, since they have all the non-disclosed ingredients, I think they look at the real thing.

Conclusion
Well, this turned out to be a lot bigger than I’d thought when I came up with the Martini bar analogy. Hopefully (particularly if you were raised in the annual SaaS world) you’ve appreciated this walk over the long and rickety bridge that connects traditional SaaS metrics to the world of monthly and usage-based SaaS.  I think I’ve answered all the questions I posed at the top, though admittedly in a somewhat unstructured way.  If you think I missed one, or this post has prompted another, please let me know.

# # #

Notes
[1] Let’s pretend every month has four Thursdays to keep MRR simple here.  (Later we’ll use 52 weeks per year.)

[2] Arguably deserves the MRR moniker more than the month-to-month SaaS service, where the customer might must just be trying it out.  In this example, the customer has stated this will be their Thursday night Martini spot.  He’s ours to lose.

[3] I am somewhat fanatical that ARR isn’t just MRR multiplied by twelve.  Why?  Because if al your contracts are month-to-month, I think it’s misleading to talk about ARR.  Conversely, if all (or the majority) of your contracts are annual, I think it’s silly to talk about MRR.  Yes, math wise, one is 12x the other, but the choice of unit does make an implication about the nature of the contracts.

[4] At least for now.  The downturn may well reveal the Achilles’ Heel of usage-based models — it’s great when usage is always going up.  When it’s not, well, not so much (and those annual commitments start to look a whole lot better).

[5] Also known as consumption-based pricing.  I tend to use the terms interchangeably.

[6] While I’m not sure people think about this way, in reality, ARR is a forward-looking metric.  It’s about what people are promising to pay you in the future.

[7] In the annual subscription world, NDR is also forward-looking.  You’re looking at what customers are promising to pay you in the coming year vs. what they promised to pay you in the then-coming year, one year ago.  

[8] There’s ostensibly considerable irony in the word “perpetual” meaning one-shot, but remember perpetual was describing the duration of the license, not the nature of the revenue.

[9] This varying period made it hard to interpret some SaaS metrics.  Should a company that does exclusively two-year contracts calculate churn rates based on the entire ARR pool or on an available-to-renew (ATR) basis?  It’s a factor of 2 difference with a company that does purely annual contracts, yet people will often unknowingly compare them.  See Churn is Dead, Long Live NDR.

[10] Salesforce started out with months as the contract and billing period, but quickly moved to years to avoid the hassle of monthly invoicing for enterprises, who generally preferred the simplicity of annual contracts, and to avoid running out of cash by billing a year up-front.

[11] That’s just revenue recognition.

[12] Which is why some perpetual license companies first moved to term licensing (e.g., selling three-year term licenses) as a discounting alternative and, while not widely recognized at the time, pretty strongly resembled SaaS companies, with the major exception that they didn’t run the software.

[13] I’m not sure how many companies allow rollover, but I think it’s not that common, though Snowflake is an example of someone who does, provided your next-year commitment is bigger than this year’s.

[14] Or, as Snowflake calls it, “product revenue.”

[15] The standard definition of churn compares ARR/MRR at this year’s renewal to last year’s initial contract or renewal.  Not last quarter’s.

[16] If you say NRR is 108%, it’d sure be helpful to know if that’s classic year-over-year (in which case it’s just OK) or lazy quarterly, which compounds to 136% year-over-year (in which case it’s amazing).

[17] Note the subtlety here that we’ve quietly switched the units of churn to simply dollars (for a period) as opposed to MRR or ARR dollars.  In the rates, the units cancel out.

[18] Except for Implied ARR, which we’ll discuss in a minute.  But I’m not in love with using a calculated or implied metric as an input to a formula.

[19] As a dramatic example, if you annualized December bookings at most software companies, you might get 2-3x the actual annual result as a typical enterprise software company might get 20% of its annual bookings in the last month of the year.  Tracking trailing twelve months of any metric that shows annual (or shorter) seasonality will tend to damp that out.

[20] This works pretty well in enterprise SaaS where new bookings are generally quite backloaded.  Thus, last quarter’s ending ARR is the heavy-majority source of this quarter’s subscription revenue.  (Few contracts stop before quarter’s end because they were backloaded when signed, and few new contracts get signed before quarter’s end.)  This, however does mean that implied ARR is effectively one quarter phase lagged.

You Can’t Fix a CAC Payback Period: The Operator vs. Investor View of SaaS Metrics

Just a quick post to share the slides for the presention I gave today at SaaS Metrics Palooza, entitled You Can’t Fix a CAC Payback Period: The Operator vs. Investor View of SaaS Metrics.  (For those with Slideshare issues, Google Drive share is here.)

The presentation discusses:

  • The ways VCs can use metrics in discussions with founders and CEOs.
  • A deep dive into CAC payback period (CPP) itself, how it’s defined, what it measures, and how its often “corrected.”
  • How investors like compound metrics (e.g., CPP, Rule of 40) whereas operators are best focused on atomic metrics — e.g., you should set accountability and OKRs around atomic metrics.
  • How some metrics are stealthly more compound that you might think — e.g., CAC based on net-new ARR or gross profit (or both).
  • Why I like to say, “you can’t fix a CAC payback period.”  It’s a compound metric which can be driven by at least 5 different factors.
  • How to apply my observations to everyday SaaS life.

The slides are below.  Thanks to Ray Rike for inviting me to the palooza!

Lazy NRR is Not NRR. Accept No Imitations or Subtitutes.

The other day I was looking at an ARR bridge [1] with a young finance ace.  He made a few comments and concluded with, “and net revenue retention (NRR) is thus 112%, not bad.”

I thought, “Wait, stop!  You can’t calculate NRR from an ARR bridge [2].”  It’s a cohort-based measure.  You need to look at the year-ago cohort of customers, get their year-ago ARR, get that same group’s current ARR, and then divide the current ARR by the year-ago.

“Yes, you can,” he said.  “Just take starting ARR, add net expansion, and divide by starting ARR.  Voila.”

Expecto patronum!  Protect me from this dark magic.  I don’t know what that is, I thought, but that’s not NRR.

Then I stewed on it for a bit.  In some ways, we were both right.

  • Under the right circumstances, I think you can calculate NRR using an ARR bridge [3]. But the whole beauty of the metric is to float over that definitional swamp and just divide two numbers — so I inherently don’t want to.
  • My friend’s definition, one I suspect is common in finance whiz circles, was indeed one shortcut too short. But, under the right circumstances, you can improve it to work better in certain cases.

The Trouble with Churn Rates
For a long time, I’ve been skeptical of calculations related to churn rates.  While my primary problems with churn rates were in the denominator [4], there are also potential problems with the numerator [5].  Worse yet, once churn rates get polluted, all downstream metrics get polluted along with them – e.g., customer lifetime (LT), lifetime value (LTV), and ergo LTV/CAC.  Those are key metrics to measure the value of the installed base — but they rely on churn rates which are easily gamed and polluted.

What if there were a better way to measure the value of the installed base?

There is.  That’s why my SaaStr 2019 session title was Churn is Dead, Long Live Net Dollar Retention [6].  The beauty of NRR is that it tells you want you want to know – once you acquire customers, what happens to them? – and you don’t have to care which of four churn rates were used.  Or how churn ARR itself was defined.  Or if mistakes were made in tracking flows.

You just need to know two things:  ARR-now and ARR-then for “then” cohort of customers [7].

A Traditional ARR Bridge
To make our point, let’s review a traditional ARR bridge.

Nothing fancy here.  Starting ARR plus new ARR of two types:  new logo customers (aka, new logo ARR) and existing customers (aka, expansion ARR).  We could have broken churn ARR into two types as well (shrinkage and lost), but we didn’t need that breakout for this exercise.

Now, let’s add my four favorite rows to put beneath an ARR bridge [8]:

Here’s a description:

  • Net new ARR = New ARR – churn ARR. How much the water level increased in the SaaS leaky bucket of ARR.  Here in 1Q21, imagine we spent $2,250K in S&M in the prior quarter.  Our CAC ratio would be a healthy 1.0 on a new ARR basis, but a far less healthy 2.1 on a net new ARR basis.  That’s due to our quarterly churn of 8%, which when annualized to 32%, flies off the charts.
  • Expansion as a percent of new ARR = expansion ARR / new ARR. My sense is 30% is a magic number for an established growth-phase startup.  If you’re only at 10%, you’re likely missing the chance to expand your customers (which will also show up in NRR).  If you’re at 50%, I wonder why you can’t sell more new logo customers.  Has something changed in the market or the salesforce?
  • Net expansion = expansion ARR – churn ARR. Shows the net expansion or contraction of the customer base during the quarter.  How much of the bucket increase was due to existing (as opposed to new) customers?
  • Churn rate, quarterly. I included this primarily because it raises a point we’ll hit when discussing lazy NRR.  Many people calculate this as = churn ARR / starting ARR (quarter).  That’s what I call “simple quarterly,” and you’ll note that it’s always lower than just “quarterly,” which I define as = churn ARR / starting ARR (year) [9].  The trace-precedents arrows below show the difference.

Lazy NRR vs. Cohort-Based NRR
With that as a rather extensive warm-up, let’s discuss what I call lazy NRR.

Lazy NRR is calculated as described above = (starting ARR + net expansion) / starting ARR.  Lazy NRR is a quarterly expansion metric.

Let’s look at a detailed example to see what’s really being measured.

This example shows the difference between cohort-based NRR and Lazy NRR:

  • Cohort-based NRR, a year-over-year metric that shows expansion of the two year-ago customers (customers 1 and 2).  This is, in my book, “real NRR.”
  • Lazy NRR, simple quarterly, which compares net expansion within the current quarter to starting ARR for that quarter.

The point of the trace-precendents arrows shows you that while the result coincidentally might be similiar (and in this case it is not), that they are measuring two completely different things.

Let’s talk about the last row, lazy NRR, cohort-based approximation, which takes starting ARR from year-ago customers, then adds (all) net expansion over the year and divides by the year-ago starting ARR. The problem?  Customer 3.  They are not in the year-ago cohort, but contribute expansion to the numerator because, with only an ARR bridge, you can’t separate year-ago cohort net expansion from new-customer net expansion.  To do that, you’d need to have ARR by customer [10].

Lazy NRR is not NRR.  NRR is defined as snapshot- and cohort-based.  Accept no substitutes or imitations.  Always calculate NRR using snapshots and cohorts and you’ll never go wrong.

Layer Cakes Tell No Lies
While I’m usually quite comfortable with tables of numbers and generally prefer receiving them in board reports, this is one area where I love charts, such as this layer cake that stacks annual cohorts atop each other.  I like these layer cakes for several reasons:

  • They’re visual and show you what’s happening with annual cohorts.
  • Like snapshot- and cohort-based NRR, they leave little to no room for gaming.  (They’re even harder to survivor bias as you’d have to omit the prior-period ARR.)
  • Given my now-distant geophysics background, they sometimes remind me of sedimentary rock.  (Hopefully yours don’t look like that, as unmetamorphized, sedimentary rock represents an NRR of only 100%!)

The spreadsheet for this post is available here.

(The post was revised a few times after initial publication to fix mistakes and clarify points related to the cohort-based approximation.  In the end, the resultant confusion only convinced me more to only and always calcuate NRR using cohorts and snapshots.)

# # #

Notes
Edited 10/8/22 to replace screenshots and fix spreadsheet bug in prior version.

[1] Starting ARR + new ARR (from new logo and expansion) – churn ARR (from shrinkage and lost) = ending ARR

[2] I probably should have said “shouldn’t.”  Turns out, I think you can, but I know you shouldn’t.  We’ll elaborate on both in this post.

[3] Those conditions include a world where customers expand or contract only on an annual basis (as you are unable to exclude expansion or contraction from customers signed during the year since they’re not sepearated in an ARR bridge) and, of course, a clear and consistent definition of churn, playing fairly with no gaming designed understate churn or overstate expansion, and avoidance of mistakes in calculations.

[4] Churn rates based off the whole ARR pool can halve (or more than halve) those based on the available to renew (ATR) pool, for example if a company’s mean contract duration is 2 or 3 years.  ARR churn rates are probably better for financial calculations, but ATR churn rates are a better indicator of customer satisfaction

[5] Examples of potential problems, not all strictly related to calculation of churn ARR, but presented for convenience.

  • Expansion along the way. Consider a customer who buys 100-unit contract, expands to 140 the next quarter (without signing a new one-year agreement that extends the contract), and then at the annual renewal renews for 130.  The VP of CS wants to penalize the account’s CSM for 10 units of churn whereas the CFO wants to tell investors its 30 units of expansion.  Which is it?  Best answer IMHO is 40 units of expansion in the second quarter and 10 units of churn at the renewal, but I’ve seen people/systems that don’t do it that way.   NRR sees 130% rate regardless of how you count expansion and churn.
  • Potential offsets and the definition of customer – division 1 has 100 units and shrinks to 80 at renewal while a small 40-unit new project starts at division 2. Is that two customers, one with 20 units of churn and one new 40-unit customer or is it one customer with 20 units of expansion?  NRR sees either 80% rate or 120% rate as function of customer definition, but I’d hope the NRR framing would make you challenge yourself to ask:  was division 2 really a customer and ergo belong in the year-ago cohort?
  • Potential offsets and the definition of product – a customer has 100 units of product A, is unhappy, and shrinks to A to 60 units while buying your new product B for 40. Did any churn happen?  In most systems, the answer is no because churn is calculated at the account level.  Unless you’re also tracking product-level churn, you might have trouble seeing that your new product is simply being given away to placate customers unhappy with your first one.  NRR is inherently account-level and doesn’t solve this problem – unless you decide to calculate product-level NRR, to see which products are expanding and which are shrinking.
  • Adjustments.  International companies need to adjust ARR for fluctuations in exchange rates.  Some companies adjust ARR for bad debt or non-standard contracts.  Any and all of these adjustments complicate the calculation of churn ARR and churn rates.
  • Gaming.  Counting trials as new customers and new ARR, but excluding customers <$5K from churn ARR calculations (things won’t foot but few people check).  Renewing would-be churning customers at $1 for two years to delay count-based churn reporting (ARR churn rates and NRR will see through this).  Survivor biasing calculations by excluding discontinuing customers.  Deferring ARR churn by renewing would-be churning customers with net 360 payables and a handshake (e.g., side letter) to not collect unless thing XYZ can be addressed (NRR won’t see through this, but cash and revenue won’t align).

[6] Since I now work frequently with Europe as part of my EIR job with Balderton Capital, I increasingly say “NRR” instead of “NDR” (net dollar retention), because for many of the companies I work with it’s actually net Euro retention.  The intent of “dollar” was never to indicate a currency, but instead to say:  “ARR-based, not count-based.”  NRR accomplishes that.

[7] Some companies survivor bias their NRR calculation by using the now-value and then-value of the now cohort, eliminating discontinuing customers from the calculation.   Think:  of the mutual funds we didn’t shut down, the average annual return was 12%.

[8] If you download the spreadsheet and expand the data groups you can see some other interesting rows as well.

[9] The flaw in “simple quarterly” churn is that, in a world that assumes pure annual contracts, you’re including people who were not customers at the start of the year and ergo cannot possibly churn in the calculations.  While you use the same numerator in each case, you’re using an increasing denominator and with no valid reason for doing so.  See here for more.

[10] In which case you might as well calculate NRR as defined, using the current and year-ago snapshots.

 

Slides from my SaaStock Workshop on US Expansion for European Startups

Just a quick post to share the slides I used at a recent SaaStock member workshop on Rising to the Challenges of US Expansion.  Thanks to those who attended — everyone had great questions and feedback.  My favorite was roughly:  “listen to Dave, I literally have made every one of these mistakes!”  (From someone who happily got it right in the end and now gets 40% of ARR from the US market.)

This material is based on the series of posts I wrote for the Balderton Build site on US expansion, the first post of which is linked to here.