Comment by JoshTko a day ago
I'm confused by this, why would sales team know in detail the vRAM contribution to sales price, and how is it relevant to your purchase decision? I've never heard of enterprise/SAAS pricing to be based primarily using cost plus pricing.
I spend a lot of time on pricing and packaging of SaaS software and the challenge is real. Everybody says they want simple pricing, which often aligns to seats or MAU - but then they want usage-based pricing, but then they're concerned about unpredictable costs and spiky usage.
Unfortunately, there's no such thing as a free lunch - you can have simple and predictable but you will have some users that you pay for that aren't getting value. You can have usage-based billing, but then you run the risk that anyone who uses an antipattern for the product will suddenly cost you a ton (or consume all of their allocated quota and be dead in the water, which is differently bad).
The more flexibility you offer, the more complexity you're putting onto customers and sales teams to understand what's the best way for them to consume the software.
There's also a lot of market pressure to "follow the crowd" - even if you have an option that is (in your mind) more customer friendly/favorable, if you are structuring your pricing differently than the competition, there will be customers who are concerned that they're not getting "a good deal" or concerned that the structure will end up being less favorable to them over time (after all, why does everybody ELSE do it this other way?). Sales reps also prefer pricing strategies that are at least structurally consistent with other products on the market, because it makes their lives easier.
Similarly, it's very difficult to change pricing nad packaging later on - changing price is relatively simple, but changing units of billing or retiring an old offering can be an extremely difficult task.
(disclaimer: these are just my own opinions, everything is hard)
I've seen companies square this circle with capped hybrid billing strategies. Customer gets charged the min of bills. Bureaucratic customers that need specific billing models can pick them but most people will accept the savings.
It's funny, this was actually one scenario that I thought about mentioning but I had to get on a plane and was running out of time.
It is true you CAN do this, but very few do, for a few reasons:
One is, it's bad for margins - when you build a pricing model, you inevitably end up creating a system where some customers subsidize other customers. You assume each user or unit of usage is going to cost you X/unit and you charge X+Y. There is inevitably going to be a distribution of users and their usage patterns and costs, and the 90% percentile is probably going to be 5X, and the 10% is probably going to be .2X. There's not any malice there, it's just that different users have different usage scenarios and they use the product differently.
Another reason relates to the issues with usage-based billing. Even in that scenario, whatever usage dimension you measure on will have users that don't fit the profile and they still end up being subsidized (from a margins perspective) by customers that DO map to the profile. A really naive example - you're a database company, you want to be cheap for people to get started, you go with usage based billing and charge based on storage. For most customers, that works - assuming your product value is apparent and differentiated, I think most people would understand that "I have to pay more because I'm storing more data, and accessing that data can be more expensive, queries more complex, and the utiltiy that I get from the database scales as the quantity of storage increases". Great, usage based billing, let's do it.
But - then you have users who store very small amounts of data but with incredibly high query volumes. Your options are to either just eat the cost of those users (which might be fine for some amount of time) or now start to add additional dimensions on which you meter usage. So now you charge for storage AND cpu time AND maybe concurrent connections if that's a problem AND bandwidth. Congratulations, you have now created the perfect usage-based billing model, which perfectly assigns customer charges to handle the multitude of usage patterns that customers experience.
BUT, it's really complicated to explain to people, and it's really complex to predict costs. That has two implications, one of which is that your value proposition has to be increasingly compelling as complexity increases. To use the database example, at some point someone at a customer will say "honestly, wouldn't it be more predictable if we just spun up a couple of VMs and ran a database instance ourselves?". Complex usage-based pricing works if you've got incredible technology that would be difficult to impossible for a customer to deploy themselves, but if your value prop is convenience and/or abstraction, you're diminishing that value as you make the pricing model increasingly less convenient and less abstract.
The other factor is that someone has to build and manage the metering of all of these things. Even a single dimension like storage is complicated - how do I bill for additional storage? Do I look at the total storage at the end of the month and multiply by X? That hurts users who, say, run end of month batch jobs - but for you, users that use huge amounts of temporary space and then free them before the end of the month, that hits your bottom line (depending on your own architecture). So maybe you want to charge on a daily basis, but now every problem gets more complicated.
Then, if you extend that across multiple billing dimensions, it's just gotten harder and more complicated. Now it's rock and a hard place time - you can stick to one abstract usage measure that is easy to reason about, but you're inevitably going to have some users that underpay based on that usage measure and some that overpay. Or you can add more dimensions and make things more "fair", but everybody's lives are harder, both for the customer and for you and your team.
When you give customers automatic optimization, you get the worst of both worlds - you make less money on the bottom 10% (usage-wise) of users/customers because they end up falling into the usage based billing, and you make less money on the top 10% because there is capped upside for you as the provider. For customers, sure, it saves them money, but what you're really giving them is a price cap (not to exceed X).
I would say for the sales teams, it's also not great, because they have all of the challenges of explaining two different models. For enterprises, it's a mess because 1) they'll probably want to negotiate specific billing terms for their use cases (we don't want to pay X for bandwidth, we want to pay Y) and other structural terms, all of which your billing system needs to support.
At the end of the day, however you charge for anything is an abstraction layer on top of your costs. That's true if you charge per user, or per object, or per gig, or per connection, or whatever else. It's all unit-based pricing even if it's not usage-based procing. You have to decide how much work you want your engineers, customers, salespeople, etc. to do in order to build, explain, and understand how much someone will pay for software.
My general advice is to pick the simplest pricing model that protects your margins and prevents abuse. For infrastructure-y products, things like storage, compute, network, are all reasonable meters. For SaaS products for business users, per-user pricing is well-understood, and there are things you can do if you really want to apply a usage-based element there (bill based on MAU, or have a MAU component separate from seats purchased). But there's really only two scenarios - you pick a small number of meters and understand that some customers will subsidize other customers, or you meter across a bunch of dimensions that align to your costs and create a lot of complexity for your customers. Blending the two gives you worse margins and the complexity of both options combined.
Usage-based pricing makes sense when you’re buying infrastructure products. For (most?) other things, the price is based on value, not material cost.
The cost of that PDF generation might as well round up to zero, but developing the tech cost multiple man-years of work. How do you price that “objectively” unless you’re given a breakdown of the company R&D expenses, operation costs and margins. That is not a reasonable request. Either you’re happy paying $X because it solves your problem and brings equivalent value to your business, or you’re not.
I do agree seat-based pricing is often ridiculous, but that’s a problem for the free market to solve. Alternatives usually pop up given enough demand.
I agree that in general usage-based pricing makes the most sense (particularly as that is a good proxy for measuring how much "value" someone is getting from it), my biggest complaint was that the way they were trying to measure it was dumb and very outdated. It really only made sense in a world where everyone was still running on physical servers or VMs. I would certainly concede that pricing is a very hard problem for a product like this, but whatever pricing they come up with should at least map onto the system it's being used in. Basing it off of number of pages of PDFs generated might would make sense, but they insisted on knowing how many CPU cores I would be allocating (which makes little sense when it's deployed as a highly elastic lambda function!)
You sound like the worst possible customer. Don’t you see? Nobody is obligated to serve cheap people.
> You sound like the worst possible customer. Don’t you see? Nobody is obligated to serve cheap people.
No, I don't see, but it's clear from your personal attack that you do see and that you can help me, so thank you in advance. Please, help me to see.
Can you please point out to me where I'm being the "worst possible customer" ? Is it because I refuse to lie and/or make shit up to jam my extremely square peg into their round hole? (which I might add, would open me to legal liability down the road if I guessed wrong (lawsuit for underpaying license fees), or would mean I drastically overpay and even bankrupt the company if I guess way too high. What if I get one customer and use 500ms of a single vCPU all month, but I guessed 50 vCPU?).
If they want to know things that I don't even know in order to price them, what else should I do? I have a theoretical product that doesn't exist yet, with 0 users, 0 vCPUs, and 0 vRAM because it isn't deployed yet. I have no idea if I'll get 10 users in the first year or 10,000,000. How many vCPUs and vRAM should I tell them so they can price it? Keep in mind this will be deployed in an AWS lambda function so it scales literally on-demand, demand that we have no idea of yet because the product doesn't exist. We also have no idea how much CPU and RAM it will even need, because again it doesn't exist so it can't be profiled or measured. If you can't answer that, I won't accuse you of being "the worst possible customer" ;-)
Maybe a different approach. I have a PDF library that I want to sell you. I typically charge $10,000 per vCPU per month. You are thinking about building a product on top of my library and ask me for pricing (which I don't publish anywhere so you have absolutely no idea what to expect). You have no idea how many users (if any) you'll have, and you plan to deploy this as a lambda function that can scale from 0 to Infinity almost on-demand. I ask you how many vCPU per month you're going to use so I can quote you a price. What is your answer?
Salespeople often misunderstand value-based pricing. If a product costing V dollars is made of N parts, then each part provider claims their value is V, so they deserve V-$1.
A PDF conversion may be required for the end-users, but it doesn’t make the entirety of the value of the product. It just doubles it, as well as the N features before that. But although each feature doubles the value of the product, the order of features doesn’t matter; A PDF export might have been added as the second feature, but the 10th feature still doubled it.
It's uncanny how accurately this maps to departments claiming they contribute V-$1 of the total profits. Sales argues they bring all the money, engineering argues sales would have nothing to sell without the products being made, platform claims no products would run without the infra they provide, support claims everything would grind to a halt without their constant babysitting of the users, etc etc. Only HR and Facilities don't claim to be directly responsible for any revenue, but that's only because everyone needs them anyway.
> How do you price that “objectively” unless you’re given a breakdown of the company R&D expenses, operation costs and margins.
You ballpark how long it would take you to build something similar? You don’t need any breakdown for that, just a marginally competent engineer on staff.
What you described is likely usage-based, in the sense that the (presumably cloud) vendor usually has to reserve a certain amount of resources per user, “just in case”, because they don’t know / can’t predict your activity pattern. Same reason VMs are still charged for when started but idle: they reserve their CPUs.
What people really want, when they say “usage-based billing”, is outcome-based billing. They want to get charged money whenever they hit the button in your software that makes them money (or, for a cost-center, saves them money.)
Think of e.g. tax prep companies. (For the average Joe employee), they don’t charge you money up-front; instead, they take a part of the net-positive return they fully expect to find you. They make you happy, then take a slice of your happiness at the exact point that they’re making you happy. Outcome-based billing.
Yes. There’s nothing more obnoxious to me than products like Figma where my company has a limited number of full licenses. They are super stingy with what my account type can do, so the 2 times per year when I need to get involved inside a Figma document or even a FigJam board I have to go begging for someone else’s license, but it would be way too costly to pay as much per seat for the entire company as we pay for our designers, for whom that’s obviously a core tool.
Isn't that exactly how a lot of things are priced? Ie. Snowflake. Pay for compute, pay for storage, etc.
But McDonalds absolutely can tell you an objective measure of what they charge you based on what you're getting. They charge you x per burger and y per fries and ...
The examples contained CPU and ram but that's not what they say everything should be - just some objective measure.
Snowflake charge by time, storage and size of machine - though they never tell you what the machine actually is underneath. I don't know what their "large" is.
Maybe it's by concurrent users, maybe amount of hours of support, maybe API calls.
I think the key thing was "we'd charge you X because you'd use Y" rather than "we'd charge you X because you look like you might pay it"
Yes especially enterprise software marketed toward platforms/infrastructure usually are priced this way. SaaS products aimed at consumers or high-level business (like HR, Accounting, etc) often don't, so depending on what people's experience is mostly they may think differently
Some products (especially infrastructure) still bill based on (outdated and often irrelevant) core counts and memory count. A few years ago I talked to a seller of a PDF library/toolkit who wanted to know my production and staging core count before they would quote me a price. Explaining to them that it runs in a serverless function on-demand was fun, especially because they would say things like, "well, what's your average?" I would often reply and say my average is defined by a function where you take the number of active users (which itself is highly elastic) and calculate for average runtime at 4 cores per user for approximately 50 ms per page (which page count is highly elastic too) and sum to get "average core use per month". Needless to say it was like pushing a rope.
More common now with SaaS seems to be employee count or some other poor proxy measurement for usage. I love actual usage based billing, but some of the proxies people pick are ridiculous. Like, if I have 5 seats or 500 employees, but 2 users spend 6 hours a day in the software and then 10 others maybe look at it once a quarter, paying the same for those is absurd and is not usage-based billing at all.