Hacker News Reader

Comment by lmeyerov | Hacker News Reader

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?

View on HN

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...

Reply on news.ycombinator.com