How to price your SaaS product
lennysnewsletter.com
lennysnewsletter.com
The logic behind it is that a lot of businesses give employees the power to buy stuff under this $50 limit without having to get it approved from their boss/deptt.
At an early-stage b2b SaaS catering to a rather cautious clientele, I feel this could affect adoption/activation negatively. Conversely, pricing per-seat creates the "I have paid for this, I should adopt and evangelize this in my org. as deeply as possible".
Does anyone have experience with switching from seat-based to value-metric based pricing?
But this assumes the thing does not offer greater value to you in return. In that case, why are you paying for that service at all?
I think the first part of the article made an excellent point about this, which was that if you're going to price based on a value metric, that metric should be tied as closely as you can to the quantifiable value you're providing to the customer, preferably something that is practically measurable or, if that's not viable, a proxy that is a reasonable approximation.
I think the bigger problem with value metrics is, as others have already noted, that they have to be readily understandable. I know plenty of people whose businesses no doubt could run on AWS, and possibly cheaper than their current hosting arrangements, but they won't go anywhere near it because of the complex pricing model and/or the lack of facilities to cap the spend in case of accidents or abuse.
Value-based pricing works well if your product is aligned to revenue or cost savings, and you can attach a clear business objective to the product.
AWS is of course completely horizontal and therefore can serve an infinite number of business objectives excellently; and it does.
It can be very natural. Look at Stripe's pricing. It's a nightmare to explain, but makes sense when using the platform.
I like that way of thinking; it has a lot of resonance and power.
Stripe now seems to have several distinct services, each with their own pricing. It's moved some functionality that used to be inclusive into those other services at extra charge. It's grandfathered, but not forever, some customers on different rates and different functionality shifts. It's stopped waiving some fees in cases of reversed transactions. There are different possible fees for international payments depending on locations, on top of any currency conversion fees and exchange rates. I could no longer tell you, without looking things up, what we're paying to Stripe for any given transaction now or how much of it Stripe would keep if for example we later decided to refund that transaction.
I do know that the added complexity has resulted in higher overall fees for us, and that has certainly had a deterrent effect within my own businesses and professional network. For example, while it wasn't the only factor in our decision, my new business has looked elsewhere for payment processing. A few years ago, all of the founders would probably have just assumed by default that we'd use Stripe, because we'd all had generally positive experiences with it before.
The pricing discrepancies between Lightsail and the rest of the platform seem to support this point of view.
Its about making the customer feel good about using your product vs making them do a business calculation every time they use your product.
If you sold me a compiler and charged me every time I ran it(assuming no other compilers exist for this use case), it would certainly create value for me. BUT, I would run the compiler as little as possible. I would invest in linters / develop one in house. I would put processes and tooling around the compiler so that we ran it as little as possible.
Instead, if I paid a flat one-time/monthly fee for the compiler, I would get as much use out of it as possible. I would love that fact that I have a great tool at my disposal. I would evangelize it to my coworkers, since "we already paid for it".
Say there is a SAAS that provides CRM features used by customer support teams. If you're a user of that SAAS, maybe it's saving you 25% of the time you used to spent handling customer support enquiries with your previous software and process. That's clearly a win. If it's also priced per enquiry, but at much less than that 25% saving rate, using it is still clearly a win. Are you really going to invent whole other systems and processes to try to minimise how much you're using the one that you already have and that is demonstrably much better than what you had before? Are the front-line customer support staff whose time it is saving?
IME, this kind of argument usually arises from a sense of fairness or feeling like you ought to be able to get a better deal with some other pricing model elsewhere. But in business, good management is logical and evidence-based, and that includes investing in good tools and improving processes if these offer a good RoI.
Indeed, with that same logical, evidence-based approach to the management of the SAAS product itself, users who are going to be swayed by a negative emotional reaction to a pricing structure that objectively offers them good value for money may be more trouble than they're worth. If your pricing model sends them somewhere else then that may also be a win.
In this situation, there would likely arise a culture of "don't do extra queries". The people who can close a ticket in less queries gets to brag about cost savings at the next salary review, even if such a practice is detrimental.
Its not about being stingy, its about the user experience. Even if it is the exact same $/month, charging upfront is a better experience and sets up better incentives than nickel and diming the customer throughout the month.
I have gone through this exact thing with AWS. Where I work uses AWS, but the "pay as you go" model creates a sort of adversarial relationship. We have engineers creating tools that finds the cheapest instances given certain parameters. We have people spending time tuning configurations and build jobs to be as cheap as possible to run. Yes, it is worth it for the company to pay someone to 'optimize' our use of AWS. And that both lowers the amount of money AWS makes from us, but also makes AWS frustrating to use.
Also, please remember that AWS was exactly the example I gave originally of a pricing model that has a deterrent effect because it's so hard to understand.
I think you're confusing "value-based" with "metered". There's another model which is a hybrid model, not strictly metered, but not strictly seat based. An "hourly package" like gitlab-runner minutes is an example. The trick is that you can incentivize usage by giving them leeway to exceed their per-seat cap without penalty (to a certain degree--which signals to you that they've outgrown their current plan), in fact you want them to, but not to the point where you take a loss. If they're seeing the value in the service enough to push the limits of their plan then they just need some time to internalize that value. You can then approach them about upgrading to a better fit package. You can also provide what are considered 'demand drivers' for 'free'. These are features that increases the value of the original service and actually drive increased demand as well.
Ex: Analytics tools often charge utility fees along the lines of "per byte", but customers hate it because it prevents passive collection for core business functions (see: Splunk). However, when utility fee are more aligned to active use, e.g., for scaleout tools like Spark, 1:1 match on AWS spend, it seems ok, and closer to perceived value: you're using it.
Also, re:seats... in the age of SSO/2fa, doesn't the objection around seat sharing largely go away?
AWS pricing works well, because it aligns with how sysadmins and operations folks used to -- and still do! -- buy hosting space and datacenter resources. It's more granular to be sure, but the model is identical: you're buying so many units of rack or compute space, so much network bandwidth, so much memory, and so on.
As such, value-based pricing only works if either the market already understands it, or if you have the sales resources to educate your potential customer base -- which nominally means you're selling to large orgs and enterprises.
Which also means you're probably not a startup. Enterprise sales cycles are long.
If your product promises to boost sales, revenue-share pricing is a value-based pricing option worth considering. "We don't get paid unless you make more money" is a solid sales tactic, but it also depends on your clients' willingness to share revenue or revenue-proximate data.
But if you don't directly add to the bottom line, that's a hard sell. You are much better off with a simpler model (per-seat, per-month, etc.) that aligns with the market and with your customer expectations, and iterating from there with generous grandfathering.
Per-seat pricing can be value-based as well. "value based pricing" in the context of a per-seat license is about identifying the value of the 'seat' to the user, rather than calculating the pricing based on your own costs plus some projected profit margin.
Regarding seats and SSO, check out https://sso.tax. Many companies will have a seat based license that has a free tier and as soon as you need/want SSO (because you see the value) you're now cast into a very expensive pricing model. Personally I hate being on the receiving end of this, but they're using the free feature-set as a demand driver, and as soon as you want to rely on the service in an authenticated master, they've now got you locked in.
RE:Output, I like that view -
* Passive (data ingest, ...): bad; and data gravity & analytics value + dropping storage prices means you want to encourage collection vs discourage (up to data liability hazards)
* Active usage based, esp. user-visible: You're using CPU/GPU hours to run something. Except agreed, the further you are from a dev, the more annoyed they are. An active user can be a proxy for this ("Editor", "Viewer", "Creator", ...), but users make it hard to get more scalable pricing, e.g., 1 power user should be able to get insane value, and be charged proportionally.
* Output: If the result of a task is an artifact, like a project/model/etc., it's a proxy for unit of value achieved. In a sense, Slack's "Free tier conversion to get search history of recent chats" comes from recognizing this.
I find it interesting companies like Figma are by User, not Project...
Usage-based sounds like the ideal solution. Although I haven't figured how to set that up yet. Your don't want to encourage low usage.
As an end user of some B2B software priced using this model, I can vouch for this. It's been frustrating for me and my coworkers, and it does do what you say: encourage low(er) usage. (Especially if it's variable pricing rather than being split into different tiers based on usage ranges.)
The perspective I and others have felt is that "you're punished for using the product".
There are different ways usage could be measured, but for some information security products that process or analyze logs/events, for example, the more things you log, the more your costs increase linearly. There are many instances where a valuable logging initiative could increase costs by 2x - 10x. I remember having to spend time away from actual work in order to find log sources to cut to reduce the extremely hefty costs we were paying.
As a business owner I'm the opposite of you; I want more services to have usage-based pricing like S3.
Take your logging example. It seems fair that if I log 2x more I pay 2x more. If there's business value in that logging then it's a no-brainer.
With fixed pricing tiers I know that's when I'm at the lower usage end I'm paying over the odds, and when I'm at the upper end I have the problem you describe of not wanting to exceed my usage and move up a tier with a large price increase.
True, that can be an issue, as well, but once you're an enterprise at a sufficiently large size and are pretty much always guaranteed to be in the highest tier anyway, the flat monthly price can often be a lot less costly.
For the record, the main product I'm referring to in this case is Splunk. Excellent product that I love using (and still often use the free tier of for personal use), but I know a lot of companies have moved away from it due to the cost.
I think logging doesn't necessarily scale that closely with company size, revenue, how many people are using the product, how many actual machines you have, etc. A competent, motivated, small team at a small company with not that many systems could end up logging a lot more events per day than a much bigger team at a much bigger company with many more systems. Especially if the team is specifically focused on logging for security purposes.
And in this case, the variable pricing is arbitrary rather than a response to an actual increase in cost: the product is hosted on-site and maintained internally, with us also covering costs for the server cluster and resources, so it's not like there's any kind of marginal cost for the company based on how much we log.
I don't think it's necessarily a bad pricing strategy in terms of what can generate the most revenue for their company, or that it's unfair or underhanded or that they don't deserve it or anything like that, but I and some other people who spent most of our day working with it just began to find it frustrating.
Don’t assume the consumer of your product is also the buyer.
If you had a widget solver, you could charge per widget solved. This way a one widget solve request or a csv upload of a million widgets are priced accordingly.
You can also charge per mb, if your service is some sort of data piping. Or if it's a ML translation service, you charge per word.
That kinda thing.
For solutions like Adobe Photoshop as an example, I would not care who used it in our company, I just care about the result. Managing licenses for it is just annoying burden and I can see how people would like to have one account and pay for usage. It is also quite easy to abuse because output is not tied to person work as in accountability/who changed what/ way.
I would say one has to understand his product and how it is used instead of "never do X" advices.
We could either move from 40k/instance to 40k/cpu (so in this case - pay 8x more), or, they would be willing to work with us on a low 'per client' fee.
Unfortunately, the system in question was a network management system for many 1000s of devices, and they were attempting to treat each device & each person in the organization touching any software connected to the system as a 'client' ...
management quickly started to investigate the viability of postgres/enterprisedb ... though I think in the end we were able to renegotiate oracle back down to this planet.
It’s super annoying when vendors try to price gouge you by restricting number of products / databases / etc.
A flat fee approach would be most reasonable to me. I don’t mind paying a bit higher but I don’t want to limit how many users I can give access to or how much of the software we can use!
The issue I think is sky high valuations are forcing many SaaS to charge very high profit margins to cover their cost of capital.
These days if you go against that grain, unless you are one of those people who are destined to be a household name due to their wild success and domination of anyone doing SaaS right now, you are accepting that a competitor is going to beat you. I don't want to sell a SaaS to my customers. I don't. But my desire to not be eaten by the competition is greater and the game is the game until the meta changes. But boy do I eagerly await for the day the meta changes so we can start making better products for people.
But a system that doesn't rely on VCs and their metrics like CAC, CAGR etc. is a prerequisite which demand consistent quarterly or monthly results that indicate hockey stick trajectories, not instant bounces one month of the year on the back of a flat fee. That is the metrics most are playing to get access to capital. To change this we need a post VC economics. But I don't see where that going to come from.
Edit: Part of the basic due diligence in any enterprise considering any software product, but especially a SaaS product, is how likely the vendor is to still be there in a number of years. Unusually low prices tend to make people suspicious of long term viability.
Edit: I do admit to being a bit suspicious about anything that promises unlimited availability of any resource for a fixed price.
If you pay a flat fee, it's possible that your business eventually outgrows the SaaS in some shape/form leading you to switch to a more mature product that charges more. I think this balance is why well aligned value based pricing keeps everyone aligned for the long term.
Of course as a customer I want the best deal for the lowest price, so I guess one should take the view of a customer with a grain of salt unless there are competitors who can beat you on price and adequate quality.
Submitted here https://news.ycombinator.com/item?id=26563358
Essentially, you'd add a few lines of code and then use our dashboard to:
* Set up pricing campaigns (with rules: e.g. show $29/mo for month 1, show $99/mo for month 2 etc) * Set up localised pricing, so you'd stop leaving money on the table by charging US-prices in lower-income countries
I've announced it here: https://bychgroup.com/price-unlock/ — Would be curious to hear other people's opinions as it relates to Lenny's article
Eg
“Value based pricing” seems to be a term from the perspective of the Saas company because there’s an unlimited amount your customer can spend with you. From a Customer POV I’d say “seat based pricing” is the true “value” because you have fixed predictable spend.
What do you think they should change to make more money?
In any case, that formula doesn't mean much if you need to adjust it to a fixed, competitive price point.