Comment by Silhouette | Hacker News Reader

Comment by Silhouette | Hacker News Reader

Parent Full thread

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.

AWS prices on a cost basis, not value. That is you only pay for the input, not the output.

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.

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.

Reply on news.ycombinator.com