Menu

When your SaaS Scaleup can't scale, I can help

Category: SaaS Metrics

Pumping A Leaky Balloon – The Reality of SaaS Business Models

In crm, SaaS MetricsTags Publish Date58 ViewsLeave a comment jeffpsherman

The SaaS Business Model can be confusing to anyone not intimately familiar with how it works.  For developers, this makes it hard to understand priorities, see the levers, and understand their impact.  This post is going to try a simple metaphor.

The SaaS Business Model is like pumping air into a balloon with a leak.

The pump represents new customers, the leaks are churn, and customers are the air in the balloon - the life breath of the SaaS.

You want to pump as hard as possible to get as many customers as possible.  But the more customers you acquire, the more the balloon fills, the more pressure there will be pushing against the leaks.

SaaS Always Needs New Customers

A SaaS company can never stop acquiring new customers, because it can never stop losing customers.  Through no fault of their own, the SaaS customers' needs will change and some will go out of business.  Without a steady stream of new customers, the balloon will deflate and the SaaS will go out of business

The Pump And The Leaks Are Tradeoffs

The Pump is the force that brings in new customers.  There are many ways to acquire new customers - marketing, sales, and referrals are some of the major ones.

The Leaks are the things that cause customers to churn.  Some are outside of your control; customers go out of business.  Most are things you can control like price, easy of use, and buggyness.

The pump has a huge impact on the leaks.  A SaaS that brings in customers via Enterprise Sales is much more immune to issues with performance, ease of use, and bugs than a SaaS that brings in new customers through referrals.

Features And Quality Can Be Tradeoffs

A common confounding example is when a SaaS brings in new customers through a steady stream of new features.  This sets up a model where Features and Feature Quality have become tradeoffs.  For developers, this manifests as strange and confounding choices - create lots of features very quickly, and then occasionally go back and fix bugs.

Features bring in new customers, they optimize the pump.  Quality reduces churn, it helps patch the leaks.  Depending on the pressure in the balloon it may make sense to pump harder, or it may make sense to slow the leaks.  Churn is a laggy indicator, problems take a while to drive customers away, and fixing the problem doesn’t immediately reduce churn.  Developers also aren’t usually privy to the data so the switch from features to quality can appear with little warning.

Referrals Make Quality Additive

Alternatively, when the pump is driven by referrals, that can drive developers to prioritize Quality and make Price the tradeoff.  Software can be made easier, faster, prettier, and more reliable by throwing money at the problem.  Referrals come from happy and satisfied customers, great service at a great price.

Conclusion - The SaaS Model Requires Tradeoffs

The SaaS Business Model can be confusing because the drivers can be obscure.  Business tradeoffs aren’t static, they change based on the source of new customers and sources of churn.  This can be especially confusing for developers because churn is a lagging indicator and the switch from working on acquiring new customers to reducing churn can be sudden.

Above all else, churn is inevitable and you must always be working to acquire new customers!

Your SaaS Has Scaling Bottlenecks – Do You Know Where?

In SaaS MetricsTags , Publish Date72 ViewsLeave a comment jeffpsherman

Scaling bottlenecks choke SaaS growth.  Bottlenecks can prevent you from onboarding customers fast enough, make supporting your largest customers impossible, and even leave you saying no to giant deals.  Scaling issues impact your annual recurring revenue (ARR), net dollar retention (NDR), and customer lifetime value (CLTV).  Imagine telling paying customers that they’ve grown too big and need to move to another platform!  It is not only extremely frustrating, it weighs down all of your major metrics.

The rate at which you can onboard new customers is knowable.  So is the maximum customer size that has delightful experiences.  Customers don’t get too big overnight, they grow with you for years.  You can write tools to discover the system maximums.  Knowing the limits won’t prevent you from hitting them, but it will prevent you from being surprised.

Scaling bottlenecks are a form of tech debt; bottlenecks are the result of your past decisions, regardless of whether those decisions were intentional.  Accidentally creeping up on the system’s limits requires not knowing where they are in the first place.  

Do you know where the limits are?  Was it not worth investigating because it wasn’t maxed out?

If you don’t know, you will end up turning away customers and limiting ARR growth.  Capping customer size also caps CLTV.  Saying goodbye to long term customers tanks your NDR and hurts your ARR.

All systems have bottlenecks.  The only question is: How do you want to find them?  You can seek them out, or you can find them in your bottom line.

Reducing Latency Won’t Increase Throughput Of Streaming Systems

In SaaS Metrics, software designTags , Publish Date94 Views1 Comment jeffpsherman

A counter intuitive property of streaming systems is that latency has no long term impact on throughput.  Increasing or decreasing latency will give a short term change, but once the system stabilizes in its steady state, the throughput will be the same as before.

How can latency and throughput, two important performance metrics, be unrelated?

Let’s define some terms

Latency is the amount of time between when a message is sent and when it is fully processed.  This includes the time spent getting the message onto the stream, in queue waiting to process, and process time.

Throughput is the number of completions in a time period.  It could be 1 million messages a second, 5 per hour, or anything else.  Throughput doesn’t include processing time, that’s part of latency.  The million messages/s could have taken 10ms or 10 minutes each to process; so long as 1 million of them finish every second, the throughput is 1 million/s.

Steady State is when the system is fully warmed up and taking on its full load.  For a streaming system, this means that it is consuming the full stream, it is producing its maximum output, and the work in progress is being added to as rapidly as it is finished.

Example

Imagine two systems that receive 1 million events per second.  The first system takes 5s to process a million messages, the second system takes 2s to process the same messages.

The latency is different, the throughput is the same!

Implications beyond Latency and Throughput

Besides latency and throughput, there are 3 other notable differences between the two systems.

  1. Higher latency means more events in flight.  When it gets to steady state, the first system will be working on 5 million events at a time, the second system will only be working on 2 million.  This usually means that the first system will require more resources - bigger queues, more workers, a higher degree of parallelism, etc.
  2. Higher latency means slower startup.  It takes 5 seconds for events to start emerging from the first system, but only 2 seconds for the second system.
  3. Higher latency means slower shutdown.  At the other end of the lifecycle, systems with higher latency take longer to drain and safely shut down than systems with lower latency.

Summary

Why doesn’t latency matter?  Because streaming systems have constrained inputs.  So long as the system has enough capacity to handle 100% of the inputs, then latency doesn’t impact throughput.

Latency still controls the system requirements; slow is expensive!

You Can’t Change Your Answers

In iterative delivery, SaaS Metrics, software designTags Publish Date66 ViewsLeave a comment jeffpsherman

Without showing your work. 

When you have customer reports, you will eventually want to change how and what you measure.  That’s fine!  You have to explain the differences. 

Especially if the change is because the old system’s measurements were wrong.

Your customers calibrated their business decisions around the old system. Changing it, even for the better, throws off their calculations. 

Always improve your systems, and when calculations share, you need to overshare.

Remember the golden rule of SaaS: Do unto others as you would have AWS do unto you.

Cost To Serve For Staff+ SaaS Developers

In dev teams, SaaS MetricsPublish Date234 ViewsLeave a comment jeffpsherman

Cost To Serve is a critical metric for Staff+ SaaS Developers to understand because it shapes your understanding of the business.  Extremely oversimplified, Cost To Serve is the cost of  everything that goes into producing, running, and supporting software, divided by the number of customers.

Cost To Serve = [The cost of everything] / [Number of Customers]

This is extremely inaccurate, but it helps to point out two major concepts.  First, a large part of Cost To Serve is fixed.  Developer salaries, aka producing software, do not change based on the number of customers.  This leads to the second concept, SaaS pricing models work on leverage.  As the number of customers goes up, the fixed costs to serve each one goes down.

So, the path to success is to get as many customers as possible right?  No, because not all costs are fixed, and not all customers are profitable.

Not All Customers Are Profitable

The first problem with the oversimplified view is that not all customers cost the SaaS the same amount of money.  This is why SaaS pricing includes feature and usage tiers.  The problem is that the features and tiers don’t exactly align with usage and cost.

Pricing based on Contacts is standard for CRMs, charging for imports is rare.  A customer who imports 1 million contacts once has a lower cost than one who reimports a million contact list every week.

Webhooks never make it into pricing models, but their costs add up.

There are dozens of legitimate usage patterns that can make the difference between profitable and unprofitable customers.  You won’t find them on the pricing page, but chances are your finance department has at least a vague model.  It is expected that some customers will be more profitable than others; and that some will even be unprofitable.

You Need A Model For Cost To Serve

It doesn’t matter what your company’s Cost To Serve is and you don’t need to know the fixed costs.  What you need is a model to evaluate customer usage.  You need to be able to explain which usage patterns are expensive and estimate the potential costs of new features.

If your SaaS is complex, try breaking it down like Big-O notation.  What costs scale linearly, which ones are exponential?

Your model can improve over time, the important thing is to start today.  Cost To Serve is a critical metric for SaaS companies; as a Staff+ Developer you need to understand it, and how it differs from your company’s pricing model.

Understanding Churn Rate For Subscription SaaS Developers

In SaaS MetricsTags Publish Date143 ViewsLeave a comment jeffpsherman

Churn Rate is one of the most important metrics for a Subscription based SaaS.  Churn is the term for a customer not renewing their subscription and ceasing to be a customer.  The Churn Rate is the percentage of customers you lose over a year.

Ie - if you had 100 customers paying for a subscription at the start of the year, and 95 of them renewed their subscription, your churn rate would be 5%.

Because the rate is based on existing subscribers, it can only be between 0% (everyone renewed) and 100% (no one renewed).  Churn is a key piece of Net Dollar Retention, another important metric for SaaS developers to understand.

Churn Rate is especially important and simple for developers at SaaS companies with subscription models. Anyone who doesn’t renew their subscription has churned.

What is a good churn rate?

Churn rates differ based on your market and customer type.  For example, small business churns at much higher rates than enterprise.  See this article for an depth discussion.

The 2 most important numbers:

  1. The average churn rate is 13% per year
  2. Sustainable Growth requires a churn rate below 8%/year

The higher your churn rate, the harder it is to grow, or even tread water.

How can developers reduce churn?

Customers churn for all kinds of reasons that developers can’t impact.  Smaller customers go out of business; enterprise customers have internal politics.

There are two places where developers have the greatest impact:

The First 90 Days

The first 90 days are your chance to provide value to your customers.  If customers don’t get value in the first 90 days they lose interest and try something else. 

This isn’t the time to push for long term value, it is critical that your UI guide customers to small, quick wins.

For developers, that means you need to work on two experiences:

  1. Importing data.  The process needs to be easy and fast.
  2. Reports.  Customers need to see the value.

Bugs and Performance Over Time

If you make it past the first 90 days, congratulations, your customer is likely to lock in to an annual subscription.  The 30 days before renewal, however, are not the time when a customer decides to churn.

Long term customers churn because they aren’t getting value anymore, the platform is slow, or they hit bugs.  Circumstances change, when customers are no longer getting value from your service, there’s nothing to do but wish them luck as you wave goodbye.

Is your platform fast and responsive?  Does it get slower over time? These are developer concerns!

Do your customers hit bugs?  That’s a developer concern!  Each bug increases the odds that a customer churns instead of renewing.

Conclusion

For subscription based SaaS, Churn is a simple top level metric.  Higher churn means slower growth or even negative growth.

The two key areas are the first 90 days, and long term performance and bugs.

Make it easy to get started and see value; keep the customer experience from degrading over time.

Last, remember that a lot of churn has nothing to do with your SaaS or your work as a developer!

Net Dollar Retention For SaaS Developers

In crm, SaaS Metrics, software designTags Publish Date393 Views1 Comment jeffpsherman

Net Dollar Retention (NDR) is one of the core financial metrics for SaaS companies, and one where software developers have an outsized impact.  This article explains NDR and how software influences can drive the number down.  Finally, it discusses three areas for developers to focus on in order to bring the number up.  

What is Net Dollar Retention?

Net Dollar Retention is the rate that your existing customers continue to spend money with your company.  Renewals are flat, churn makes it go down, and expansion makes it go up.

As a formula using AAR (Annual Recurring Revenue), it looks like this:

( [Renewed AAR] + [Expanded AAR] - [Churn] ) / [Previous AAR]

Besides being a core metric, NDR is a key metric for companies considering going public.  Typically, a company going public needs an NDR over 107%, and ideally over 120%.

Only existing customers affect this metric!  For Net Dollar Retention it doesn’t matter if you replace every customer that churns with ten new ones, your retention rate will be terrible.

How Developers Impact Net Dollar Retention

There are only two real levers with NDR: Increase spend and reduce churn; and there is little that developers can do that will directly increase customer spend.  

The top 3 developer levers to reduce churn:

  1. Fix any bugs that corrupt or lose data
  2. Make the system more reliable
  3. Make the system faster

Fix Any Bugs That Corrupt Or Lose Data

This is the big one!

Customers come to your service to get things done.  The more often they hit bugs, the faster they will churn.  Only developers can fix bugs and prevent data corruption.

Make The System More Reliable

Close second to data corruption is reliability.

95% success rates mean that you should expect a daily job will fail at least once a month.  If customers don’t trust your system to work, they will sit and watch the process.  Usually by continually hitting refresh on your site.  This is a massive waste for your customer and makes your SaaS much more expensive.

The less reliable your service is, the faster they will churn.  Reliability is more than just a developer problem, but developers will need to lead the architectural charge.

Make The System Faster

Speed is a distant third because it rarely impacts the value that customers get from your service.  Speed, especially UI speed, has a massive impact on the customer experience.

Slow websites won’t make customers leave, but they will kill your net promoter score and leave them open to a switch.

They don’t want to waste time staring at a blank screen waiting to render.  When the problem is inefficient code, it is something that only a developer can fix

NDR is a Core Metric for SaaS Health

NDR is a core metric for health, and a critical one for companies seriously looking at going public.  Developers can heavily influence the number by reducing churn.

Fix bugs, improve stability and increase performance.

Developers can push these levers and improve NDR; no one else in the company has that power!  Become a hero to your business, pay attention to NDR and how you can reduce churn!

Site Footer