Of the 300+ services that Amazon Web Services (AWS) has released over the years, not a single one has needed to be rolled back from being priced incorrectly.
That’s no accident.
Usage-based pricing (UBP) delivers very high levels of revenue growth and product adoption. Any company operating in the cloud can (and should) adopt a usage-based pricing model enabled by best practices and frameworks that optimize the value being provided to the customer.
I worked for a few years as a general manager at AWS, where I personally oversaw Amazon CloudSearch and some of the attached services as they scaled to over a billion dollars in revenue on the back of a usage-based pricing model. Later, when we launched Amazon OpenSearch, the same model contributed to its massive success and adoption.
The usage-based model is the only one that makes sense in the cloud. Given the elastic nature of the underlying infrastructure, anything that gets layered on top needs to be just as flexible — and that includes pricing. Below, I lay out seven steps to get started with a usage-based pricing model at your business.
The single most important reason metering exists as its own artifact is because of what it is specifically designed to do — track usage.
Step 1: Implement usage metering
Many companies make the mistake of starting with a pricing model and then trying to backpedal into measuring usage.
This is the wrong approach. The first step needs to be metering all of your technology artifacts. If you are a startup building from scratch, implementing metering right at the outset will give you a tremendous advantage.
Knowing who is using what, when, where, and how much will help you unlock valuable insights across all functional groups and teams, and make determining pricing much more straightforward.
Seek a purpose-built metering service
Do not fall into the trap of metering (usage instrumenting) only the items the pricing plans dictate. Meter your technology stack holistically. You should be thinking about metering first and then moving forward into pricing and billing, not backing into metering from pricing and billing.
Here’s a good way to internalize this:
Let’s say you know you want to charge on API calls, and you begin by considering a tiered pricing model for the API calls by count. Working your way backwards from this into metering, you will arrive at the conclusion that you need to meter the number of API calls.
Contrast this with the metering forward approach. First you determine you need to usage instrument API calls because it is one of the core features of how your customers engage with your product. Then, you ask yourself, what is a holistic way to usage instrument an API call?
