One of the best advice that I've read on this very forum is always make sure that you start at $47 if that makes sense for your product.
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.
For me, it's about submitting expense reports. No receipt is required for expenses under $50. I'm 1000x more likely to try a tool under $50 than a tool over $50. I want to spend as little time as possible on expense reports and not needing a receipt helps.
My quip with value-metric based pricing has always been that by making your user pay for the useful thing, you disincentivize usage since it instantly means a higher cost for them.
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?
My quip with value-metric based pricing has always been that by making your user pay for the useful thing, you disincentivize usage since it instantly means a higher cost for them.
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.
> 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?
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".
The problem with analogies is that by their nature they're rarely entirely realistic.
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.
> 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...
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.
I was imagining a pricing model based on what you're calling tickets, so I'm not sure quite what your hypothetical culture would achieve, but I suspect we've misunderstood each other there.
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 would argue that AWS does not price outgoing bandwidth on cost-basis, or at least prices it in a way that is not obviously-to-me related to their costs. That's priced more on lock-in or "because we can"basis.
The pricing discrepancies between Lightsail and the rest of the platform seem to support this point of view.
How AWS pricing works in practice is complicated, which is the problem I was trying to illustrate. It's mostly based on usage/capacity, but hopefully for a SAAS product, the demand for chargeable AWS resources is strongly correlated with levels of user engagement and that in turn with levels of revenue.
I agree with you. I think the lesson we're meant to take on the value-based pricing is you can have complex pricing if it is aligned tightly to the value perceived.
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.
I think we probably do disagree to some degree here. In particular, Stripe was actually my next choice as an example of how not to do transparent value-based pricing, precisely because its pricing used to be simple and clearly tied to the value in processing a transaction, but over time it has drifted away from that into something that I (running a long-time Stripe merchant) don't find natural or easy to remember.
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 'value metric' can be a seat-based license. It simply means that you price the seat based on the value it brings to the customer, not based on a cost+ (your costs plus a margin) valuation or a competitor- (your competitors price minus some amount to make you stand out).
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.
It's easy to say "value based pricing" and "don't do per-seat pricing", but what are good examples when not directly tied to revenue/savings, and generalize beyond some niche domain?
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?
I think a better answer is to first build a pricing model that your customers can understand.
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.
Agreed with this, would not recommend trying to do metered/per unit pricing (that developers may be used to) if your customers aren't familiar with that. We've found that customers readily accept/understand tier based pricing. We literally just changed higher plans from usage based to blocks/tiers of usage based e.g. up to X units per plan
In the example you brought up, I'd try to meter (and value-price) the output, not on the collection. You have to make sure that your margins on the output of the service covers the cost of passively collecting and storing the data.
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.
I see the assumption of SSO/MFA as defeating the SSO tax: If we assume SSO/MFA, there is no base price vs premium tier price distinction wrt SSO -- all customers get it. For free auth modes (SSO, but probably not MFA due to SMS costs?), esp. b2b, it's easy to extend into free not-a-customer tiers. As SSO in turn eliminates account sharing, everyone wins: all users get more security, and providers see less account abuse/sharing (and hacks). And hopefully, there's something more valuable & enterprise-aligned to charge for wrt security than everyone-grade-SSO, e.g., audit logs, AD, & training.
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...
A lot of this is obvious now but not as much 8-10 years ago. Don't price your SaaS per seat, ever. It will be abused. My tiny, niche SaaS uses X 'resources' configured in the product. If you have X resources configured for your business it means you're big enough to pay more.
This seems obvious, until you’re trying to sell large enterprise deals and contract negotiation goes to procurement teams. Who have little idea what your custom units of measurement are, or how to forecast reasonable future capacity planning around team. Meanwhile headcount (seats) is easy for them to understand. With a well established model and hiring planning for the coming 12mo.
Don’t assume the consumer of your product is also the buyer.
Head count makes sense in some spaces/products. I shouldn't have been so definitive. However, the units of measure used should always be something the target enterprise understands. For example, the company I work for in healthcare prices contracts by number of beds, which is a number ever hospital understands. Im so glad I don't have to tell someone that they can't be added to use the product cause their seats are maxed out.
I have to say there are SaaS solututions that work just fine to be priced per seat. For example JIRA where it is part of job of each person to handle tickets/tasks and they have to have separate accounts. There is also basically no feasible way to abuse JIRA unless one does not care about who did what and when so throwing tracability/accountability out of the window.
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.
On the flipside, i once experienced a 'fun' renegotiation with oracle (surprise) when we were migrating to core-dense architectures and they changed their licensing model -
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.
>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.
Is this down to who has authority to approve spending, and it's easier to get approval for a larger chunk at once?
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.
>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 large price-step.
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.
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.
Sorry, just seeing this now. In my scenario, it's number of vesseils available for charters. So you pay so much for first vessels and some more for additional vessels. Companies with more vessels have more revenue so they can pay more.
As an end user of SaaS, I hate having to pay per license and would prefer firm wide licenses without too many contrived restrictions.
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.
Unfortunately it's basic Darwinism. At first there were a mix of companies that did upfront licenses and service based. But over time, the service based companies had more consistent revenue, lock in and faster customer turn around. Then, with their competitive advantages, they either ran rings around the competitors that didn't or bought them with the bigger profits.
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.
Thanks - great to have the perspective on the other side, you have to do what you have to do to survive and as you said, if you don’t play the SaaS game, then you are at significantly more risk because your competitors will.
As a customer that definitely makes a lot of sense from a pure cost POV, but as a business (depending on the SaaS) they technically are unlocking a ton more value for you as you scale. To not price accordingly feels like it would be bad overall for both businesses. CAC is only increasing as competition grows, the SaaS needs to devote revenue to both marketing and product, successful customers can help fund the SaaS so they can continue to build more value for your business, unlocking again more potential revenue for both sides.
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.
Yes it’s a very difficult balancing act, (I assume CAC means Customer Acquisition Cost) and there are a lot of overheads they need to cover. Figuring what the right price is to be competitive but also cover all marketing and other costs is not easy.
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.
You'll love https://www.bitrix24.com/prices/ then. CRM, Project Management and Collaboration tools priced exactly how you want, including unlimited plan for $199/mo. I think I've seen only one or two vendors with similar pricing, everything else is per user.
How sustainable is that though - I've worked places that had thousands of CRM users with lots of integration and storage requirements. I'd be fairly suspicious of a vendor saying they could host that for $99.50 a month. Maybe its possible, but I'd have my doubts.
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.
I've worked with/for Bitrix24 plenty in the past. The company behind it is 20+ years old. The service itself was launched in 2012. Profitable, self-funded, never needed to raise VC money.
I wasn't mean to get at them specifically, just to indicate that when you were used to what the high end CRM SaaS companies charge, $99.50 for unlimited users does seem exceptional. Mind you, if they can deliver on that for that price good on them!
Edit: I do admit to being a bit suspicious about anything that promises unlimited availability of any resource for a fixed price.
Well, you can't offer unlimited hosting for $99/mo . But Basecamp offers unlimited projects and unlimited users and they've been around for 15+ years - https://basecamp.com/pricing. So you can do unlimited user pricing easily, if it's something that's not resource/hosting intensive. They do limit storage to 500GB.
my experience is that is very very hard to actually sell "value metric" SaaS products above 500€/month because charging somethign else every month doesnt fit into most (maybe its a german thing?) companies budget calculations. they dont get "maybe 6000 maybe 12000 euros" for a year to run your software they get an exact budget. unless you are directly involved intro their payment/sales funnel and get a percentage of this i doubt this is applicable for typical B2B SaaS yearly pricings.
When you get into the realm of enterprise sales you have to find a way to predict a fixed top-end price and it has to fit into their perceived value of your product even if they use less of the service than you or they predict. An enterprise customer will tolerate a higher per-unit cost for the assurance that they won't experience cost overruns. This is because they're budgeting large line items once a year and they can not overrun. This would mean that you'd price the product at 12000 euros per year and hopefully the value of the product is still high enough to justify this in their minds.
"Per seat" I can handle, but one Kanban board SAAS we use drives me nuts with its gated features - like many cilummdyou can create 5 "business rules" to move cards automatically, but on the 6th one, someone with no approval to upgrade the licence gets an error message, then a committee in Germany talks about it and decides not to pay more for the "feature" as we're already paying them a goodly sum.
Pricing should be easy to understand for your target customer. I am surprised the article does not make mention of it. Startups who focus on value metrics too much may lose sight of it.
So I agree with this on a personal level, but I wonder if this is true for certain markets. There are a lot of businesses out there with opaque pricing (AWS is a good example, but there are smaller ones) and it seems like there are some areas where you can get quite far with very opaque pricing as long as the person buying is not the person signing the check, and the product is Mission Critical (tm) (even if it really isn't).
As a side-thing, I'm building PriceUnlock, something that would help people price their SaaS products (aimed specifically at SaaS products)
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
It’s interesting to think about some of these terms in the article and their meaning from the SaaS company perspective or the Customer perspective. Because many times the terms are different based on who you are.
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.
Easy. Cost of production * 3.14. If that price isn't competitive either take less profit or find a way to limit costs without offering a lesser product than before.
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.