Opinions and magic not required
Increasing MRR is a constant battle for SaaS founders. As it increases you can provide more value to your customers by doing things like hiring more people.
When trying to increase MRR people often think about “how do I get more users” and then go about buying ads.
Paid ads work well if you can acquire customers for about 30% of their Life Time Value. If you can consistently do that, then you can go raise a round and pump it into more paid acquisition.
Getting more customers is not the only way to increase MRR. Reducing churn, selling upgrades to existing customers, and reducing how many customers downgrade will also increase your MRR.
MRR can be predicted by looking at how much MRR you get from:
and subtracting MRR that you lose from:
Churn, Expansion, and Contraction MRR can only be gained or lost from existing customers. This means that if you have a lot of customers your Churn MRR will probably be higher than if you had fewer customers. Because of this, Churn, Expansion and Contraction MRR are usually modelled as percentages of your current MRR.
New MRR is gained from customers new to your business. This means that it does not depend on how many customers you currently have, or what your current MRR is. To change it you need to increase marketing efforts, or open . So New MRR is often modelled as a constant each month.
Your MRR for the next month can be modelled as
Next month MRR = current_mrr + new_mrr + mrr_expansion_rate * current_mrr - mrr_contraction_rate * current_mrr - mrr_churn_rate * current_mrr
Since SaaS companies are valued at multiples of their Annual Recurring Revenue, we can also use this formula to predict future company valuation. Improving the parameters above directly affects the long-term valuation of your SaaS company.
In a SaaS business, you can pull levers to change the following metrics:
Depending on your current MRR and metrics, you will get better effort to reward ratio by focusing on different rates. If you have a lot of MRR, then it might be work focussing on reducing churn or increasing expansions. If you have low MRR, then reducing churn will not increase your MRR very much.
Use the chart below to see how changing parameters effects long-term MRR.
If you already have good MRR then you will notice that decreasing churn, contraction or increasing expansion rates can have a pretty big effect.
If your MRR is currently low, then it might be more beneficial to focus on increasing New MRR. This can be done by increasing marketing efforts or opening up new customer acquisition channels e.t.c.
It’s more important to pull the right lever, than to do a perfect job of it.
If you have ever tried to make software run faster, then you may have experienced it the hard way like I did.
Spending days or weeks to implement a state of the art algorithm might not improve things if that part of the software was not the bottleneck anyway. (For me, this was months of my PhD rather than weeks).
Spending two minutes changing the nesting of a for-loop can improve things quite a lot if that was the bottleneck.
Similarly, have you ever tried doing something like changing button colors or copy to increase conversion rates? It’s a big job to change colors of all buttons, or the copy on all Calls To Action, but there are probably only a few really important buttons or CTAs in your product.
Finding the biggest MRR levers in your SaaS business is the top priority. Once you know what they are, then it is easy to focus on them.
Here is one way to find your MRR bottlenecks and optimize them (bonus, same approach works for speeding up software):
When we “find the bottleneck” we should have a very clear idea of what parts of the application need to improve. This might be a Call To Actions that prompts users to start a free trial, or it could be a high payment decline rate that is causing a lot of Dunning Churn.
Don’t worry if it’s sounding really abstract — we will go into the details next.
You can’t manage what you don’t measure — Peter Druker (famous management guy that business folk love)
Our first objective is to find MRR bottlenecks in your SaaS. To do that we need to start measuring things. Fortunately there isn’t too much to measure and we can do it with free tools mostly.
The following events to measure are in order from most important to least important. Honestly, you can get a long way be measuring page views in Google Analytics 4 and looking at your Stripe Dashboard.
Ok, so this is the most important step. If all you do is correctly identify MRR bottlenecks in your SaaS then your job is probably done.
“But finding bottlenecks doesn’t increase MRR” - If you find the bottlenecks then you can ask other people how to fix them. Its amazing how clear things become when you focus on a few very specific pieces of an application.
New MRR and Expansion MRR bottlenecks
The first thing to do is figure out what pages people visit on their way to becoming customers. We want to figure out the most common path for new users. If we have the most common path then we can focus on improving conversion rates in that to have a good impact on MRR.
You can find these paths using Google Analytics 4. Just create funnel charts with the page view paths that you think users will be taking. You want to find the path that results in the most users on the payment page. A good starting point is to try using the path that someone would follow if they land on your landing page.
If you are tracking events on CTAs then you might want to add these steps to your funnel. This will help you figure out exactly what CTAs users are clicking on their way to becoming customers.
If you upsell customers on different plans, then you can follow a similar process to find the most common customer upgrade paths.
Churn and contraction bottlenecks
Figuring out why customers churn is a little more time consuming. We basically want to break down “why users are churning or downgrading”. This will tell us what we can do to reduce churn, and also how much MRR we can expect to gain.
It’s tempting to try fix everything in your product and try to please everyone. But by doing that you are missing opportunity to serve existing customers, who might be a better fit, better.
The easiest way I have found to identify why customers churn is to talk to them on a video call. When a user cancels their account you can send them an automatic email asking them to jump on a 10 minute video call in exchange for an Amazon voucher.
Our main objective on the call is to get an honest reason why someone cancelled. We can do this if we understand why they started using the product, and then asking why they stopped using it.
If we know why they started, then we can use that to validate their reason for cancelling. Some people will give untrue answers to “why did you stop using product” so that they don’t hurt your feelings. On the call, there are two really important questions:
After a while you will hopefully see patterns in the answers to 2. This will help you to estimate how much you could reduce by making changes to your product. As a hidden bonus, the answers to 1 will help you with copy on your CTAs and other marketing efforts.
Another, more difficult, type of churn to identify and fix is Involuntary Churn (or Dunning Churn). This happens when a user’s card declines, resulting in their subscription being cancelled. This can happen when card networks decline payments because they don’t trust you (e.g. you have a high dispute rate, or your Stripe account is in another country). Stripe have an excellent guide on this.
Pulling it all together
At this stage we should know what the important pages or CTAs in our app are for increasing New MRR and Expansion MRR. We should also know a few common reasons why users churn.
The next step is to calculate how much MRR we would gain by improving each conversion rate, and how hard we think it would be to improve.
With the funnel charts, you can figure out how much more New MRR or Expansion MRR you would get by increaseing a conversion rate by x%.
From the customer interviews you can figure out how much you could increase MRR by fixing the product or adding features.
Use the MRR Lab MRR forecast tool to figure out an expected long term benefit of each change you could make
Create a table with each change you could make, how difficult it is to make, the potential MRR increase, and likelihood of success. Most of these fields are ambiguous, but they are still useful to get estimates.
If something is going to be difficult to implement, then we can try simplify it for the test and then only properly implement it if it looks promising .
For example, limiting feature usage might be difficult to implement properly because it involves updating the backend. Instead, we can just store feature usage in the client (e.g. local storage) and see what happens when users hit their limits. Sure, users could circumvent the limit, but most probably wont. So the experiment will still tell you useful things about user behaviour.
If you are stuck for ideas, then you can check out MRR Growth Hacks for case studies of what other companies did. Remember that you want to focus on fixing your bottleneck. The case studies on MRR Growth Hacks were successful because they were fixing bottlenecks in their business.
The table should help you to prioritise tasks. Not all of them will be successful, that’s what experimentation is for. If something is not successful, then you might have just tried the wrong thing and it can still be worth trying again. E.g. if you try to increase upsells by making the buy button more prominent, and it does not increase upsells, then you might just need to try something else.
When we have some ideas on how to increase MRR, then it is time to test them.
Generally, we should run A/B tests. Human behaviour is really hard to predict, and the A/B test will tell you exactly how things went.
If something is clearly a bug, then you might choose fix it without running an A/B test. Without the A/B test it will be more difficult to figure out how much fixing the bug increased MRR though.
Running A/B tests is pretty fun, and it is also the closest you will get to truths. In the past I have run tests that I thought would be sure-fire wins turn out to be flops. The opposite is true as well.
What if an A/B test did not increase MRR
There are lots of reasons for a B variation not to increase MRR e.g.:
It’s important to consider all of these options.
If the B variation did not improve performance then we have still learnt something about what users respond to.
It’s still worth experimenting on this bottleneck in the application if we think we can improve it. It can be a good time to remind yourself and stakeholders of how sensitive your MRR is to conversion rates in this area of the app.
What if the A/B test increases MRR
Well... Congratulations. Celebrate the win and figure out the long term MRR increase.
It’s still important to record what you did and learn from it.
Most importantly - don’t stop experimenting in this MRR bottleneck of the app. Sometimes it can be tempting to say “we improved this, good job, let’s do something else”. If there are still improvements to be had, then you should continue working on them. Any MRR increases from successful experiments can be used to hire more people if the workload is getting too large.
You don’t need to raise a round or do paid marketing to increase MRR. There is a systematic way to do it.
This post is still pretty rough and feedback is always appreciated. If you have any questions or feedback get in touch on twitter @scottgpaulin