Usage-based pricing isn't always best(chrisreuter.me)
chrisreuter.me
Usage-based pricing isn't always best
https://chrisreuter.me/2023-02-16-usage-pricing/
13 comments
> The problem comes with cost estimation. Because there are so many axes, we can't just take our size and figure out a cost estimate, we have to model out different scenarios. Does a traffic spike for us equal a logging spike?
In the case of Datadog it’s even worse that they don’t allow you to cap costs. If you have an accidental spike (e.g. some deployment gone haywire and relaunching containers and suddenly you have 100x the amount of containers as usual in a 1 hour time span), they will not refund it. I had to plea a lot for me as a solo developer, and they ended up locking me into a 1 year contract in order to be reimbursed.
I’m convinced it’s entirely deliberate and they prey upon these types of things. It was a terrible, hostile experience, because I had to pay a huge sum I did not get any value out of. I was so scared of using their product for the rest of the year that I simply wrote off the yearly subscription as a loss.
In the case of Datadog it’s even worse that they don’t allow you to cap costs. If you have an accidental spike (e.g. some deployment gone haywire and relaunching containers and suddenly you have 100x the amount of containers as usual in a 1 hour time span), they will not refund it. I had to plea a lot for me as a solo developer, and they ended up locking me into a 1 year contract in order to be reimbursed.
I’m convinced it’s entirely deliberate and they prey upon these types of things. It was a terrible, hostile experience, because I had to pay a huge sum I did not get any value out of. I was so scared of using their product for the rest of the year that I simply wrote off the yearly subscription as a loss.
> I’m convinced it’s entirely deliberate
I'm sure it is too.
My colleagues are investigating Datadog as a vendor and I think they're off their heads. We're meant to be tightening our belts and I think we'll waste a metric fuck ton of money on Datadog for a gram of value. Hopefully we don't go with them.
I'm sure it is too.
My colleagues are investigating Datadog as a vendor and I think they're off their heads. We're meant to be tightening our belts and I think we'll waste a metric fuck ton of money on Datadog for a gram of value. Hopefully we don't go with them.
In my experience, Datadog requires non-trivial active account management internally to ensure a cost effective usage, rather like a cloud infrastructure provider.
If you've got 20+ people, it's a no-brainer, the value is immense. Fewer than that and it's a tricky call.
It's a great product though, and it's in my list of "things I'd sign up for immediately" if starting a new company.
If you've got 20+ people, it's a no-brainer, the value is immense. Fewer than that and it's a tricky call.
It's a great product though, and it's in my list of "things I'd sign up for immediately" if starting a new company.
You might want to have a look at SigNoz, https://github.com/SigNoz/signoz
> e.g. some deployment gone haywire and relaunching containers and suddenly you have 100x the amount of containers as usual in a 1 hour time span
To be fair to them, I believe they bill at something like a 98% high water mark for the month, so you can spike briefly like this.
I completely agree with the point though.
To be fair to them, I believe they bill at something like a 98% high water mark for the month, so you can spike briefly like this.
I completely agree with the point though.
It's true that with Datadog, a spike in your usage can have a dramatic impact on your bill. This feels true though of any usage model. We've all read stories about out of control AWS bills. Datadog does at least provide some guardrails to prevent things from getting out of control: https://docs.datadoghq.com/account_management/billing/usage_...
With these usage metrics and a little bit of automation (for example the Webhooks integration: https://docs.datadoghq.com/integrations/webhooks/), you could stop shipping telemetry at a certain threshold.
Disclosure: I work at Datadog.
With these usage metrics and a little bit of automation (for example the Webhooks integration: https://docs.datadoghq.com/integrations/webhooks/), you could stop shipping telemetry at a certain threshold.
Disclosure: I work at Datadog.
My issue isn't necessarily that a usage spike impacts the bill, that's fine!
The problem is that because of the billing complexity, it's hard to predict how billing will scale with usage. There are just too many axes. Even steady-state billing is hard to price out before signing up, so much so that the answer we received from sales was to just try it and see what the bill is.
This becomes a road block. "I'd like to move us to Datadog! – Oh yeah, how much does it cost? – I won't know until after we've moved." – these conversations are hard to have internally.
The product is fantastic, I'm a big fan. And the total price isn't necessarily bad, it's just opaque, and required a lot of work on my side to model out the pricing, present the business case, get sign-off, and manage the contract over the years. Not something that I, as one of ~8 engineers, wanted to spend my time doing.
The problem is that because of the billing complexity, it's hard to predict how billing will scale with usage. There are just too many axes. Even steady-state billing is hard to price out before signing up, so much so that the answer we received from sales was to just try it and see what the bill is.
This becomes a road block. "I'd like to move us to Datadog! – Oh yeah, how much does it cost? – I won't know until after we've moved." – these conversations are hard to have internally.
The product is fantastic, I'm a big fan. And the total price isn't necessarily bad, it's just opaque, and required a lot of work on my side to model out the pricing, present the business case, get sign-off, and manage the contract over the years. Not something that I, as one of ~8 engineers, wanted to spend my time doing.
As a rule, if I can't understand the pricing in two minutes, I do not do business with a vendor. Also, if there is not a stop-loss, I view the vendor as predatory.
> Stripe's usage-based pricing works well because it's so direct – it's just X% of revenue.
For what it's worth, that's how Stripe Payments works. But if you want to also use billing, invoicing, other additional functionality, then it's X% + Y% + $Z/month.
For what it's worth, that's how Stripe Payments works. But if you want to also use billing, invoicing, other additional functionality, then it's X% + Y% + $Z/month.
You're right, but they're all typically fractions of the revenue figure, so really very easy to price out. They may not be worth it for some businesses, but my point isn't about price, it's about the complexity in figuring out that price.
Yeah, agreed that it's all along the "dimension" of revenue. But the details of how Stripe prices its add-on functionality is different than competitors like Chargebee or Recurly (for subscription management) or QuickBooks Online (for invoicing), so it does make it hard to make "apples to apples" price comparisons.
Why not offer two types of pricing, a flat (expensive) one and a usage-after-the-fact (cheap) one.
Like in Electricity markets - you can either get market pricing (cheaper, but very volatile) or fixed price.
Like in Electricity markets - you can either get market pricing (cheaper, but very volatile) or fixed price.
That most likely is an option, where DataDog (and others) will happing sign an enterprise contract with you and take more of your money than what you end up using. The issue is that you're still going to be bound to a maximum logging/metrics/etc budget, so you still end up needing to estimate your usage to avoid going over your pre-paid limits.
Let's take the simplest example of flat pricing for a logging service: You pay $X and you get all the service you can consume. A salesperson tries to intelligently set $X for you. We'll even spot the salesperson full knowledge of the previous year of usage, and we'll even stipulate that the purchasing company is 100% honest about their intent to consume, but that they do not have a 100% accurate prediction of the future.
The problem here is the statistical distribution of the usage will bankrupt you as a company if you try that. People mentally want to model everything as nice, polite distributions through a combination of all the statistics classes they've ever taken using them (where the "uniform" distribution is the default and "gaussian" is if you want to get fancy) and internal cognitive biases around the nice distributions generally encountered in most real life and a general lack of experience with pathological ones, but the real distribution of consumption is grotesquely pathological and has huge spikes in the tail. The probability of one of your 10 biggest customers, which collectively account for ~90% of your business, getting an unexpected 10x or greater spike, isn't negligible like a naive high school statistical analysis might suggest. It is instead virtually certain.
I've simplified this problem down just to concentrate on that bare statistical problem, which is something engineers should try to develop an intuition for. However, as we de-simplify the problem by re-introducing back all the real world complications, they all tend to make this problem even worse. For instance, give a company an all-they-can-eat deal, and if they accidentally spike your usage because the intern accidentally committed a debug logging message that spiked their usage by 50x, they have no particular incentive to fix that.
Naturally, in the real world you'd put limits in the contract... but if you think about it, flat pricing with limits that you can realistically hit because the limits really ought to be thought of in logarithmic terms, rather than linear ones, is just usage based billing with extra steps.
I've also taken advantage of the local topic of conversation being a logging service. Other businesses are not necessarily so pathologically distributed. Email is more reasonable to charge per seat, partially because people are used to the pathological part of the resource consumption distribution being cut off... or to put it in the terms everyone is used to, people are used to being told they can't attached a 3.5 terabyte attachment to their email and that emails to a few thousand people at a time generally cause trouble. Since the number of emails an account can use is bound to some degree by human attention and the size and therefore resource consumption of the email is bound by size limits, it tends to be less pathological. Email also permits throttling, and indeed, if someone is suddenly receiving millions of emails per hour they may be happy that you are throttling their inbox. Although in the end it's probably still more pathological than you may intuit.
Even here though, when you return the real world back into the picture it doesn't mean a flat pricing model perfectly works. Give them an $X/month all-you-can-eat, and one of your customers will find a way to provide email addresses to every resident in a country or something. Put limits on that and it's just usage with extra steps. There is a sense in which usage-based-billing is the only real option, it's just a matter of the details of how you price and market it.
The problem here is the statistical distribution of the usage will bankrupt you as a company if you try that. People mentally want to model everything as nice, polite distributions through a combination of all the statistics classes they've ever taken using them (where the "uniform" distribution is the default and "gaussian" is if you want to get fancy) and internal cognitive biases around the nice distributions generally encountered in most real life and a general lack of experience with pathological ones, but the real distribution of consumption is grotesquely pathological and has huge spikes in the tail. The probability of one of your 10 biggest customers, which collectively account for ~90% of your business, getting an unexpected 10x or greater spike, isn't negligible like a naive high school statistical analysis might suggest. It is instead virtually certain.
I've simplified this problem down just to concentrate on that bare statistical problem, which is something engineers should try to develop an intuition for. However, as we de-simplify the problem by re-introducing back all the real world complications, they all tend to make this problem even worse. For instance, give a company an all-they-can-eat deal, and if they accidentally spike your usage because the intern accidentally committed a debug logging message that spiked their usage by 50x, they have no particular incentive to fix that.
Naturally, in the real world you'd put limits in the contract... but if you think about it, flat pricing with limits that you can realistically hit because the limits really ought to be thought of in logarithmic terms, rather than linear ones, is just usage based billing with extra steps.
I've also taken advantage of the local topic of conversation being a logging service. Other businesses are not necessarily so pathologically distributed. Email is more reasonable to charge per seat, partially because people are used to the pathological part of the resource consumption distribution being cut off... or to put it in the terms everyone is used to, people are used to being told they can't attached a 3.5 terabyte attachment to their email and that emails to a few thousand people at a time generally cause trouble. Since the number of emails an account can use is bound to some degree by human attention and the size and therefore resource consumption of the email is bound by size limits, it tends to be less pathological. Email also permits throttling, and indeed, if someone is suddenly receiving millions of emails per hour they may be happy that you are throttling their inbox. Although in the end it's probably still more pathological than you may intuit.
Even here though, when you return the real world back into the picture it doesn't mean a flat pricing model perfectly works. Give them an $X/month all-you-can-eat, and one of your customers will find a way to provide email addresses to every resident in a country or something. Put limits on that and it's just usage with extra steps. There is a sense in which usage-based-billing is the only real option, it's just a matter of the details of how you price and market it.
> flat pricing with limits that you can realistically hit because the limits really ought to be thought of in logarithmic terms, rather than linear ones, is just usage based billing with extra steps.
In a sense, yes. But the difference is that with flat pricing, you can at least easily predict what your charges will be. With usage-based pricing, you can't unless your use case is very simple.
In a sense, yes. But the difference is that with flat pricing, you can at least easily predict what your charges will be. With usage-based pricing, you can't unless your use case is very simple.
IMHO the key to usage-based pricing is that the usage metric that pricing is based on must always be a fraction of the value metric in the customer's head. Otherwise customers start thinking about how to game the pricing system, which leads to them using your product less and also getting annoyed that they have to think about pricing so much.
For example, let's say you have a product that manages AWS cloud spend in a way where you can always reduce AWS costs by 10%, and you charge 2% of cloud spend for this product. This is a great example of usage based pricing: whenever the customer is paying you 2%, they are saving 8%. This is a no-brainer, and the customer will use your product as much as possible.
On the other hand, lets say your product can sometimes save 30% on AWS spend, and sometimes it can't save anything at all. For example, maybe it's great at optimizing spot instances but not reserved instances, or it's good for some AWS locations but not others. Now pricing based on cloud spend sucks because you're forcing your users to think hard about whether to apply your product to each individual piece of cloud infra. This is a crappy user experience, and customers will leave if something friendlier comes along.
On a side note, a more subtle example here is Heroku. When you're a small Heroku customer, paying a 200% premium on cloud spend is fine because you save so much by not hiring a team to manage your cloud infra. However as you grow, the price you pay increases much faster than the value you receive. As a result, lots of customers graduate once they hit a certain size.
This is a general pricing principle I've been thinking about: you want your price to be proportional to your value. Doesn't matter if you're charging by usage, or per seat, or a flat price -- you want the decision to be a clear win for your target customer all of the time.
For example, let's say you have a product that manages AWS cloud spend in a way where you can always reduce AWS costs by 10%, and you charge 2% of cloud spend for this product. This is a great example of usage based pricing: whenever the customer is paying you 2%, they are saving 8%. This is a no-brainer, and the customer will use your product as much as possible.
On the other hand, lets say your product can sometimes save 30% on AWS spend, and sometimes it can't save anything at all. For example, maybe it's great at optimizing spot instances but not reserved instances, or it's good for some AWS locations but not others. Now pricing based on cloud spend sucks because you're forcing your users to think hard about whether to apply your product to each individual piece of cloud infra. This is a crappy user experience, and customers will leave if something friendlier comes along.
On a side note, a more subtle example here is Heroku. When you're a small Heroku customer, paying a 200% premium on cloud spend is fine because you save so much by not hiring a team to manage your cloud infra. However as you grow, the price you pay increases much faster than the value you receive. As a result, lots of customers graduate once they hit a certain size.
This is a general pricing principle I've been thinking about: you want your price to be proportional to your value. Doesn't matter if you're charging by usage, or per seat, or a flat price -- you want the decision to be a clear win for your target customer all of the time.
I think your pitch here really just ties back to simplicity in pricing. Simplicity in pricing is a strong customer desire. When your service is so valuable that it’s a no brainer, the pricing is de facto simple; pay the final bill and be done. When the value add is thinner or more uneven, it’s ok, but pricing becomes complex and customer preference will be for simple pricing structures such as all-you-can-eat.
Simplicity is definitely part of it! But the value/price alignment piece is also important.
Take Hacker News. If they charged $50/mo, I'd pay that. But if HN charged $1 per homepage visit, I'd start visiting a lot less. Maybe once or twice a day, but not 20x/day. Both $50/mo and $1/visit are simple pricing methods, but my value is not the same with each visit given the homepage doesn't change much hour by hour. So maybe it's really worth $5 for the first visit of the day and 25 cents/visit after that, and thus the $1/visit system wouldn't work well (for me).
Take Hacker News. If they charged $50/mo, I'd pay that. But if HN charged $1 per homepage visit, I'd start visiting a lot less. Maybe once or twice a day, but not 20x/day. Both $50/mo and $1/visit are simple pricing methods, but my value is not the same with each visit given the homepage doesn't change much hour by hour. So maybe it's really worth $5 for the first visit of the day and 25 cents/visit after that, and thus the $1/visit system wouldn't work well (for me).
I agree. I avoid usage-based pricing in favor of a flat fee whenever possible because of this. It's very rare that the hassle of having to work out the charges is worth it to me.
As a general principle, the best pricing structure for a product is one that most closely matches the value that the customer derives from a product. Usage-based pricing is best when each time you use it, you're saving your customers money. The company I work for makes software that helps to speed up the process of reviewing real estate appraisals. We help a human check for important issues in the appraisal much more quickly than they could do so themselves. That makes usage-based pricing perfect - every time our customers use us for an appraisal, they pay us. That's ideal, because the amount of time they save by using our software has a greater dollar value than the amount they pay us. It also means that when the market turns down and they need our software less, they're not stuck with large, fixed bills.
For many tools, this isn't the case. I've worked on a lot of enterprise software that charges on a per-user basis. This makes sense for something like enterprise content management and CRMs - the number of people using them is roughly going to correlate for their value. If you hire a new salesperson, you expect to make more sales and thus have a willingness to pay a little more for a tool that helps with that.
For many tools, this isn't the case. I've worked on a lot of enterprise software that charges on a per-user basis. This makes sense for something like enterprise content management and CRMs - the number of people using them is roughly going to correlate for their value. If you hire a new salesperson, you expect to make more sales and thus have a willingness to pay a little more for a tool that helps with that.
>I've worked on a lot of enterprise software that charges on a per-user basis.
I hate them the most, after seeing them in companies with 10^2 - 10^3 of employees.
whenever you get an intern, or when an employee could help on a job that isn't his, you have to get them a license. And by the time the licensing process has happened, someone would have found a solution without using the software.
Then, instead of getting new licenses, some employees will just waste time to find someone who can access the right functionality on the software.
Eventually, if your company doesn't have a strict whitelisting policy for the software that is being used, employees will just end up using their own open source software or free smartphone apps, and will ditch the software that will charge on a per user basis. If your company has a strict policy, they will just hate it.
I would prefer to have a bundle, and a salesperson that properly estimates the value for each company, so that each employee can have the proper tools.
I hate them the most, after seeing them in companies with 10^2 - 10^3 of employees.
whenever you get an intern, or when an employee could help on a job that isn't his, you have to get them a license. And by the time the licensing process has happened, someone would have found a solution without using the software.
Then, instead of getting new licenses, some employees will just waste time to find someone who can access the right functionality on the software.
Eventually, if your company doesn't have a strict whitelisting policy for the software that is being used, employees will just end up using their own open source software or free smartphone apps, and will ditch the software that will charge on a per user basis. If your company has a strict policy, they will just hate it.
I would prefer to have a bundle, and a salesperson that properly estimates the value for each company, so that each employee can have the proper tools.
> Eventually, if your company doesn't have a strict whitelisting policy for the software that is being used, employees will just end up using their own open source software or free smartphone apps
We're definitely thinking of different kinds of software here, as this would never be the case with the kind of stuff I'm talking about. Whatever CRM your company uses, every salesperson is using. It would be incredibly obvious if they were using something else (their manager is regularly looking at reporting in the CRM), and it wouldn't ever fly. To your point, many people do hate it, but you can't find a way around it.
Similar with services like Box, Zoom, ServiceNow, JIRA, etc. If it's important that each person have their own account, then a per-user model is generally pretty reasonable. You'd typically need this if you need to easily track which user is doing what and/or if you need user-level access controls.
We're definitely thinking of different kinds of software here, as this would never be the case with the kind of stuff I'm talking about. Whatever CRM your company uses, every salesperson is using. It would be incredibly obvious if they were using something else (their manager is regularly looking at reporting in the CRM), and it wouldn't ever fly. To your point, many people do hate it, but you can't find a way around it.
Similar with services like Box, Zoom, ServiceNow, JIRA, etc. If it's important that each person have their own account, then a per-user model is generally pretty reasonable. You'd typically need this if you need to easily track which user is doing what and/or if you need user-level access controls.
This is especially true if, as if often the case, only a segment of the company uses the software in question. Engineering probably doesn't use Salesforce. Sales probably doesn't use JIRA.
A flat fee based on some tiered size of the company might still make sense and reduce some friction. But the amount has to work for both the buyer and seller and per-user pricing is just a natural fit in a lot of circumstances.
A flat fee based on some tiered size of the company might still make sense and reduce some friction. But the amount has to work for both the buyer and seller and per-user pricing is just a natural fit in a lot of circumstances.
I worked for a B2B SaaS outfit which charged by month by seat. Some customers demanded usage-based charges and our sales and PM said yes, without checking in with dev.
As the guy who knew the app's logs best, it fell to me to code up and then maintain the monthly report to generate those customers' usage data and send it to billing. (The things we do for love.)
Our app's log data wasn't complete and predictable enough to generate completely accurate usage data, so some assumptions were needed. (The problem was sometimes-missing timestamps for "usage session complete". Yeah I know, WTF? I inherited that code.)
Things got a tiny bit ugly. Customers -- whales of course -- started demanding weekly, then daily, usage reports. They demanded backing data for their bills. And, it became really hard to actually fix the defects in the app's logging so it was possible to generate accurate usage -- it would change the billing too much, and we'd have to explain it to the customer. It was a pain in the you-know-what. Especially for a guy like me who prefers to write really accurate software where other peoples' money is involved. This didn't threaten the business, it wasn't nearly that serious. But, wowee, it was unpleasant.
Lesson: If you're going to add a new SaaS pricing model to an existing service, think of it as a BIG change. Make sure you can capture accurate and commercially defensible metrics for your pricing model. Get devs to think it through. Get testfolk to think it through and work out some system tests. Sales people, don't just tell customers they can have their own pricing model, but only if they sign up by the end of the quarter.
As the guy who knew the app's logs best, it fell to me to code up and then maintain the monthly report to generate those customers' usage data and send it to billing. (The things we do for love.)
Our app's log data wasn't complete and predictable enough to generate completely accurate usage data, so some assumptions were needed. (The problem was sometimes-missing timestamps for "usage session complete". Yeah I know, WTF? I inherited that code.)
Things got a tiny bit ugly. Customers -- whales of course -- started demanding weekly, then daily, usage reports. They demanded backing data for their bills. And, it became really hard to actually fix the defects in the app's logging so it was possible to generate accurate usage -- it would change the billing too much, and we'd have to explain it to the customer. It was a pain in the you-know-what. Especially for a guy like me who prefers to write really accurate software where other peoples' money is involved. This didn't threaten the business, it wasn't nearly that serious. But, wowee, it was unpleasant.
Lesson: If you're going to add a new SaaS pricing model to an existing service, think of it as a BIG change. Make sure you can capture accurate and commercially defensible metrics for your pricing model. Get devs to think it through. Get testfolk to think it through and work out some system tests. Sales people, don't just tell customers they can have their own pricing model, but only if they sign up by the end of the quarter.
Tangential comment - but that Netezza appliance was really cool. I was able to use one early in my career, circa 2008. It had a nice cli query interface similar to psql (maybe it spoke postgres protocol, I don't remember) - and was blazing fast. I ran totally rookie-mistake filled, unoptimized queries on tables w/ billions of rows and got results back in ~seconds. Of course, not so impressive now, but was really impressive 15 years ago!
They had a really wild architecture with FPGAs that, if I remember correctly, sat in between the CPU/disk and was used to offload some of query execution.
It was wildly expensive + expensive to maintain, so the company ended up (unsuccessfully, I think) jumping to Hadoop. Crazy times :)
They had a really wild architecture with FPGAs that, if I remember correctly, sat in between the CPU/disk and was used to offload some of query execution.
It was wildly expensive + expensive to maintain, so the company ended up (unsuccessfully, I think) jumping to Hadoop. Crazy times :)
Within the data world, I am especially confused by usage-based pricing _and_ the push towards data mesh. In a data mesh you now have hundreds of data analysts in your company… all needing access (and driving consumption) to the data lake and all the tooling around it like on demand spark clusters, notebooks, lakehouses, dbts, dashboarding, catalogs, governance and so on… it gets really expensive to run what 90% of the times is good old sql. Most importantly, none of the vendors are going to help you optimize resources. You got a standard, highly predictable, BI job each Monday? Vendors will push you to use everything they got, while maybe an on prem server is all you need and it will be cheaper.
Until you have ran your full etl load in snowflake or bigquery, you can never estimate the cost. You may answer some questionnaire about your projected usage, data volume, frequency, etc. but until you execute all your models with any warehouse you can estimate nothing.
Usage based pricing is fine when it’s on predictable metrics, number of logs sent, number of rows sent, number of emails/sms/etc sent, number of seats, users, licences, etc. When it’s on abstract terms like credits or abstract resources like warehouses (with no idea what resource a medium warehouse utilizes) or error prone metrics like scanned gigabytes per query, it might become problematic at some point.
Usage based pricing is fine when it’s on predictable metrics, number of logs sent, number of rows sent, number of emails/sms/etc sent, number of seats, users, licences, etc. When it’s on abstract terms like credits or abstract resources like warehouses (with no idea what resource a medium warehouse utilizes) or error prone metrics like scanned gigabytes per query, it might become problematic at some point.
Totally agreed - vendor specific constructs like credits are particularly opaque. They burden the user with the complexity of managing cost without clear levers that directly correspond to a known metric describing their usage.
Charge for what you sell. Do you sell RAM and CPU, or do you sell data processing? Which do your customers prefer? How do the model their need?
This is true, but my point is that it’s not predictable.
e.g. I have 1 TB db with 50 tables and a specific i/u/d pattern. Until i replicate the whole db incrementally and run this with some warehouse, there is no way i can make an estimation about #credits per year. I want to add some new big dbt model? There is no way i know how much time will a warehouse be running because the query planner cannot create a sensible query execution plan. And so on.
Charging e.g. by # of processed rows is more predictable from end-user/admin perspective. That’s all. But obviously they make more money the way they price, what do i know? :-)
Charging e.g. by # of processed rows is more predictable from end-user/admin perspective. That’s all. But obviously they make more money the way they price, what do i know? :-)
I agree with the premise - not all situations benefit from usage-based pricing. However, this discussion misses many dimensions of what makes usage-based pricing valuable.
It’s akin to a poorly developed benchmark that doesn’t consider all the real world factors but tries to win on one vector.
Here are some other intangibles:
(1) Subscription pricing is difficult to scale upwards. The concepts of upsells and new products are difficult to execute and increasingly result in lower and lower adoption. Each new capability needs to be “sold in” with a new sales motion creating endless amounts of feature creep and unused features.
(2) If your costs are variable and your revenue is fixed, you better hope your customers don’t like you or your product is really simple. Otherwise, you risk more margin compression as customers use you more and more beyond what you modeled. The difference between your ARR and the cost to serve gets smaller. Like a perverse Innovators Dilemma.
(3) Innovation tends to be simpler with usage based pricing, when done right. In a subscription model, product teams tend to be much more conservative. Each new sellable feature needs to be fully supported with training and enablement for sales teams. When the product fails to grow like the first product, then the sales team becomes increasingly more conservative. It’s a viscous cycle.
Usage- based pricing makes a lot of the above moot. If any existing or new benefits of the product are offered to all customers, then it actually aligns the incentive of your company and your customer. Use more to drive revenue (you) or use more to get more value.
Of course, marginal value isn’t always the same, so that’s when usage tiers develop.
Now how you quantify all this I’m not sure. But there are far more simplification benefits to usage based pricing.
It’s akin to a poorly developed benchmark that doesn’t consider all the real world factors but tries to win on one vector.
Here are some other intangibles:
(1) Subscription pricing is difficult to scale upwards. The concepts of upsells and new products are difficult to execute and increasingly result in lower and lower adoption. Each new capability needs to be “sold in” with a new sales motion creating endless amounts of feature creep and unused features.
(2) If your costs are variable and your revenue is fixed, you better hope your customers don’t like you or your product is really simple. Otherwise, you risk more margin compression as customers use you more and more beyond what you modeled. The difference between your ARR and the cost to serve gets smaller. Like a perverse Innovators Dilemma.
(3) Innovation tends to be simpler with usage based pricing, when done right. In a subscription model, product teams tend to be much more conservative. Each new sellable feature needs to be fully supported with training and enablement for sales teams. When the product fails to grow like the first product, then the sales team becomes increasingly more conservative. It’s a viscous cycle.
Usage- based pricing makes a lot of the above moot. If any existing or new benefits of the product are offered to all customers, then it actually aligns the incentive of your company and your customer. Use more to drive revenue (you) or use more to get more value.
Of course, marginal value isn’t always the same, so that’s when usage tiers develop.
Now how you quantify all this I’m not sure. But there are far more simplification benefits to usage based pricing.
"There are only two ways to make money in business: bundling and unbundling"
[deleted]
This is an interesting post and an interesting discussion! But for me (a lowly algorithm developer far removed from IaaS pricing) the most confusing part of it is the meaning of "you". The author and comments seem to use it in critical equations assuming it is obvious from context and benefits whether this "you" is a service provider or a consumer (company buying IaaS).
It would be much easier for us if folks liberally sprinkled IAAS "buyer" / "seller" or "provider" / "consumer" in their opinions.
It would be much easier for us if folks liberally sprinkled IAAS "buyer" / "seller" or "provider" / "consumer" in their opinions.
"Google also spent a long time in the early 2010s focusing on something other than SQL which, while it may seem bananas now, was not that crazy when everyone thought Java was going to be the data engineering language of choice."
Anyone know what this is referring to?
Anyone know what this is referring to?
Hi there! Author here. What I was referring to was MapReduce/BigTable. While I think BigQuery always had SQL support, some customers in the early 2010s had the perception that Google was more interested in building a new language for queries rather than support something for SQL.
Mike Stonebraker talked a little bit about this in the context of MapReduce on the dbt podcast recently: https://roundup.getdbt.com/p/ep38-a-romp-through-database-hi...
Mike Stonebraker talked a little bit about this in the context of MapReduce on the dbt podcast recently: https://roundup.getdbt.com/p/ep38-a-romp-through-database-hi...
Usage based pricing is never the best, outside of a handful of use cases. I can't believe people who work in tech waste hundreds of dollars on a service they could get for 5 dollars anywhere else.
An example from my experience: Datadog. It makes sense that we pay for usage, after all things like logging and metrics scale in wildly different ways from product to product, and charging flat rates or per-user rates doesn't factor this in well enough. The problem is that for a feature-complete Datadog deployment, there may be 10-20 axes of pricing – how much log data, how many unique metrics, how much of your logs do you want to index, and so on.
The problem comes with cost estimation. Because there are so many axes, we can't just take our size and figure out a cost estimate, we have to model out different scenarios. Does a traffic spike for us equal a logging spike? or Metrics? How does it impact second order pricing like log indexing or archival? Even when you know exactly how much, e.g. logging you generate, it's still all approximated modelling, and many teams won't have the necessary input numbers at the beginning anyway.
Stripe's usage-based pricing works well because it's so direct – it's just X% of revenue. Datadog's is a pain because there are many factors, all of which are quite far removed from revenue.
I understand that at some level this is required. They're pricing for compute and storage, essentially, and a cloud provider offering those wouldn't price them at a flat rate or per-user rate, but it always felt much harder than it needed to be. I'd almost have rather paid more, but a known amount.
However,