6 Questions To Ask Before Adopting Usage-Based Pricing

Usage-based pricing (aka consumption-based pricing) is a popular pricing strategy, especially among developer-focused startups. Amazon AWS, Twilio, and Datadog are three great examples of this model.

Companies with usage-based pricing. Source: Kyle Poyar at TechCrunch

Usage-based pricing is popular because it is a win-win for both sides: the customer avoids committing to a large purchase that may or may not work, while the product can have quick lands and real expands.

If usage-based pricing is good enough for AWS, Snowflake, and Stripe, should you adopt it as well? It depends. In this post, I share a framework for deciding whether you should use usage-based pricing.

This framework is based on my experience unsuccessfully deploying usage-based pricing at Split, a developer-focused company. While the model didn’t work for Split, its learnings should be valuable to others.

First, a quick summary of the post:

• An important part of usage-based pricing is the pricing axis. A good axis will have the following properties:
• ____ Customers should experience more value if their usage increases.
• ____ If customers throttle usage, they should experience a decrease in value.
• ____ If customers throttle usage, it should not go against the growth strategy of the company.
• ____ Customers should be able to predict their future usage.
• ____ The axis should be of sufficiently large scale, preferably tens of thousands of units.
• Has your buyer bought usage-based software in the past?

Now, here are the six questions you should ask before adopting usage-based pricing

Question #1: Does value increase with usage?

Pricing should always align with business value. In other words, a customer will happily pay more for your product if they get more benefit from it today than yesterday, #pricing101.

When choosing a pricing axis for usage-based pricing, ask yourself whether a customer experiencing increased value from your product will reflect in increased usage along that axis?

For instance, let’s look at Datadog which prices per host. If a customer doubles its infrastructure footprint, it experiences double the value from Datadog as every host is being monitored for performance.

Alternatively, if Datadog charges a fee per monitoring event and the monitoring events double — while the number of hosts remains the same — it is unclear if the customer experiences twice the value. Monitoring events could have doubled because of a software update to the Datadog agent or a weird traffic pattern.

Thus, it makes sense for Datadog to charge for usage by hosts, not by events.

Question #2: If the customer throttles usage, is the value reduced?

Developers use Split through an API call that calculates whether a feature is on or off. Since an increase in API calls reflects an increase in customer value, I charged by API calls.

However, there was a flaw in my thinking. A customer could temporarily cache the result of an API call in memory, throttling their use of Split, without reducing Split’s value. This made API calls a bad usage axis for Split.

Let’s look at Twilio in contrast. Can a customer throttle their use of Twilio without reducing value? No. If they want their text messages delivered to customers they have no choice but to use Twilio. Hence, Twilio can charge for usage by text messages.

As a rule, if a customer can throttle usage along an axis without reducing value, you don’t have a good usage-based pricing axis.

Question #3: If the customer throttles usage, is that ok for your strategy?

It is an axiom that whatever you tax, it doesn’t grow at the rate it used to. It is true in pricing as well.

Companies often charge usage by a primary entity: a host for Datadog, a contact for Mailchimp, or a Kafka message for Confluent. At Split, the primary entity was a feature flag or experiment.

One idea I considered at Split is to price usage by experiments. The problem with this idea was that, strategically, I never want my customer to ask: “is this feature worth putting behind Split?” I want every feature to go behind Split, so I can train every engineer and product manager to think about product development in a new way; the Split way. I didn’t want to tax the growth of experiments.

Similarly, Salesforce does not charge by Opportunities because it is in their interest to have every opportunity tracked within Salesforce. Salesforce does not want to tax Opportunity growth.

So, when choosing a usage pricing axis, ask yourself whether it is more important for your company’s long-term strategy to let the axis grow unfettered than charging for it.

Question #4: Is usage predictable for the customer?

A benefit of usage-based pricing is that you can land a customer small and watch them grow over time. This growth is acceptable to customers as long as they can predict the growth rate. At a bare minimum, they need to predict the usage and price of your product next year for budgeting purposes. Your buyer will be incredibly unhappy if they have to go back to the Finance team multiple times within a budgetary cycle because of unexpected increases in product usage. If your product is in the top 5 expenses in your buyer’s budget, the need for predictably is even higher.

This need for predictability also elongates the sales cycle. Split’s customers would try to predict usage; however, it was a complex exercise that would require multiple stakeholders to model a few variables. This friction elongated the sales cycle and also led to a few losses.

Lack of predictability was the primary reason I moved away from usage-based pricing at Split.

In contrast, Stripe charges per successful card charge. Any e-commerce site can predict growth in their card charges if they want to use Stripe, making it a good axis for usage-based pricing

Question #5: Is the pricing axis large-scale?

This is a niche concern, but some customers will estimate how much you are charging per unit. If your pricing axis is such that you will only ever have a few hundred units, the price per unit may be large, which can be a psychological barrier for some customers. Alternatively, it can put a cap on the most you can charge for your product ever.

The biggest names in usage-based pricing — AWS, Snowflake, and Twilio — all charge along a large-scale axis.

Question #6: Is your buyer used to buying by usage?

Engineering is a buyer profile that is very comfortable with usage-based pricing. However, if you are selling to the Sales or Finance teams, they may not be used to buying this way. While there is always an opportunity to educate your buyer, ask yourself whether this is a risk you are willing to take.

Summary

Usage-based pricing is a fantastic driver of land-and-expand. When done right, it reduces the sales cycle and lets you meet your customer where they are today. It also builds in a promise of future growth.

However, before you adopt this model, take a look at the questions I posed. A “no” to any question should help you dig a bit deeper before committing to usage-based pricing.

I am sure I did not cover other important considerations. If you feel like I missed something, do share your thoughts.