In the early 1990s USI said, “let there be the ASP” and at that very moment the cloud was born, fulfilling the dream of IBM’s 1960s experiments with utility computing. For the first time, the small seeds of SaaS began to grow. Developer collaboration reached new heights and features could be delivered almost instantly, leading the charge for Salesforce, Oracle, and the ever ironic "No Software" movement.
There was a hitch in the steps of progress though - pricing. How should we price software that requires no physical delivery and deploys so quickly and cheaply that competitors and costs no longer matter?
Well, unfortunately, most companies punted and followed what they knew best - per license models, which translated to per user models, causing a flurry of per user pricing that plagues SaaS to this day. Per user pricing kills your growth and sets you up for long term failure, because it’s rarely where value is ascribed to your product and kills your Monthly Active User metric. Let’s walk through this and chat more about what you should be doing with your SaaS pricing.
What is per user pricing?
Per user pricing is a SaaS pricing model that charges a subscriber for each user of its product. For example, some subscription businesses charge $9.99 per user, per month, while others charge a flat fee for unlimited monthly usage.
Per User Pricing is a Value Metric Relic of the 1980s
To understand why per user pricing isn’t good for most SaaS products, we first need to review the concept of a SaaS pricing value metric. Remember, a "value metric" is what and how you’re charging for a product. If you’re selling a pair of shoes, then your value metric is “per pair of shoes” and as customers buy more pairs your business expands.
A great value metric passes three tests: 1. it’s easy for the customer to understand, 2. it’s aligned to where the customer receives value in the product, and 3. grows with your customer’s usage of that value.
![A value metris is what you charge for, and should ; 1. Align to customer needs, 2. Grow with your customer, 3. be easy to understand](jpg/ntjjngq2ntityzkymy00nzk2ltkzzdktotjimjq4odu1ngji_0cfbed0e-55a8-4c45-9ea4-06d690554603_valuemetricsrequirements1e3b.jpg?auto=format%2Ccompress&fit=max&w=1200)
In the case of our shoes, charging per pair fails to fulfill the latter two criteria, because value isn’t derived from the pair in and of itself; it’s derived from the number of days, miles, or smiles the pair of shoes brings. Of course, charging based on the number of miles you wear the shoes seems pretty preposterous, as was any method of charging for software other than per license 30 years ago. There wasn’t a way to easily monitor how much usage was occurring and even then it didn’t make sense in the cost structure of integration or delivery.
Essentially, early software companies were pricing based on similar models to hardware or even a pair of shoes. Doesn’t seem very sophisticated, does it?
When SaaS came along, we just kept going with the same model, even though our software became 10x more sophisticated and provided 10x the value. The barriers described above no longer existed, and for most products you’re building right now, it doesn’t really matter how many users are using the product. Rather, value comes from the number of tests completed, the number of files stored, or even the amount of bandwidth or visitors analyzed.
Number of Users is Rarely Where Value is Derived for Customers
If the logic of being able to throttle and tie your pricing to customer value isn’t working for you, then consider this - most customers don’t actually see value from your product in a “per user” fashion. Over the past year, we’ve tested this with 75 different SaaS companies and tens of thousands of their customer's survey responses.
When asked about which value metrics are most and least valuable to them (using our feature value algorithm), we've seen the below output time and time again (the other value metrics were redacted to protect the customer’s identity). Even our CRM and help desk customers have similar graphs, because value isn’t in the number of users - it’s in the additional sales, contacts, reports, etc.
![Graph shows significant variance in customer preferences for other value metrics](jpg/mti2zdgxn2qtmzdhns00mdziltkznjatmwfmzdrjmge2zje3_67a0c2bc-ce8c-481d-977d-741fd3d60c08_valuemetrics1e3b.jpg?auto=format%2Ccompress&fit=max&w=1200)
This isn’t to say that users can’t or shouldn’t be a part of your model, but more often than not it shouldn’t be your first inclination or the primary metric, especially if you’re selling a marketing or analytics product where the natural max number of users for a product, marketing, or analytics organization is probably only 5 - 10 in most mid market companies and even some enterprise companies. Even then, you need to have product differentiation to push for customer pricing segmentation and to boost MRR and spur upgrades. Salesforce’s pricing is frustratingly brilliant at this, as all the fun features are in the higher plans.
You’re killing your most precious metric: Daily Active Users
What’s scarier with per user pricing though for most analytics, sales, marketing, and product SaaS companies is that pricing on a per user basis actually contributes to your churn rate considerably, because it greatly reduces daily active user numbers. Caring about active users isn’t just reserved for iOS games and social networks. After all, there’s a reason Business Intelligence and Analytics applications typically churn to the tune of 6-12%…per month.
When you naturally throttle the number of people who can access an account, you’re naturally killing the stickiness of the product within an organization. Look at GitHub’s Pricing vs. Preforce’s pricing below (both help development teams store, collaborate, and version code). I’m willing to bet a good sum of money that Github's SaaS metrics and health are much better than Preforce’s because Github is making the user throttles a no-brainer and only charging where customers are actually getting value - the number of repositories for code.
![Preforce subscription tiers are user based](jpg/mdnkyzmxnzmty2fhmy00ztk5lwjlm2mtnjy2ytjmnzk2mmy1_03a7a9ae-d0a2-4ab2-9cb5-64315f6f99a0_preforce1e3b.jpg?auto=format%2Ccompress&fit=max&w=1200)
![GitHub's pricing uses repositories, not users, as its value metric](jpg/mdczotnlm2qtnjhlni00ndmyltg5odetmdfkyjqwzwvmnde4_21dab20e-ab69-4999-ae69-c050b6532fd5_github1e3b.jpg?auto=format%2Ccompress&fit=max&w=1200)
The funny thing here is that Github’s upgrade rate is probably much better than Preforce’s because more people means more repositories and more repositories means a higher plan, thereby boosting MRR and retention. As a SaaS company, retention and churn are all you should care about for the lifeblood of your product. Unfortunately though, the beauty of SaaS goes both ways - churning out is just as quick and seamless as deployment. More people using a product in an organization makes this considerably harder.
The Exceptions and Getting Past Per User Pricing
Yes, there are a number of products where per user pricing makes sense, but it should never be the end all be all of your SaaS pricing. Feature differentiation, additional value metrics (Storage, contacts, bandwidth, reports, etc.), and add-ons need to be an aspect of your overall SaaS Pricing Strategy. The important thing to keep in mind here is that you need to test and truly make your pricing customer and value based.
This is because we have worked with some companies where the graph from above is the complete opposite, with users coming back as the most important value metric. Although, this has only happened a handful of times; hence, why it’s important to test and talk with your customers.
To help you, we’ve written plenty on the steps to value based pricing, as well as how to define and identify your value metric(s). If it still doesn’t make sense though, feel free to reach out to me via email or phone - we’re more than happy to walk you through the concept at no charge.
Ultimately though, it’s time to move on from per user pricing. Not for me. Not for you. For your revenue; your customer; and your growth.