Comment by JoshTko
2 days 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.
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.
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.
7 replies →
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!)
2 replies →
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.
2 replies →
> 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.
2 replies →
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.
Some things are sure. But not most. You wouldn't expect to go to McDonald's and they tell you (or even know) how much the fertilizer to grow the corn that feed the pigs that made the bacon contributed to the price you pay for a burger
If McDonald's insisted on having a long sales phone call to sell me a burger, then yeah, I'd expect them to be able to provide me that information.
3 replies →
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