Hacker News Reader

Comment by ambivalents | Hacker News Reader

> a clear signal to charge these customers a lot more money.

Interesting, can you explain this a little more? Some of our customers chomp at the bit for particular features, and when we can we give them early access. We do not charge them more for arguably huge amounts of value add to the product.

I wonder how to have these types of conversation, internally and with users. I'm a PM but have a direct line to management. I'm frustrated with how much money I believe we are leaving on the table, even if it doesn't directly benefit me.

View on HN

I don’t think this is about charging for new features - it’s almost about the opposite.

I read this as “A customer that asks for advance notice of feature changes is likely to be a big enterprise customer that values stability and predictability, and the fact that they’re asking suggests your product is important enough to their process to matter, so you should take this opportunity to charge them a ton of money for an ‘enterprise support plan’ which includes advance notice of new releases, etc.”

As the GP said, it’s a signal that they’re a certain type of customer.

If you also have a direct line to your users, you could try asking them how much they'd be willing to pay for either some new feature that's about to come out, or for the right to early-access. Get maybe 3–5 data points and you should have a pretty solid case to management (either to charge retroactively for existing features, to charge new users for existing features, or to charge all users for upcoming features).

rather than ask "how much they'd be willing to pay", it might be more compelling to simply say "It will cost $X for early access, limited to X slots, in exchange, {we do such-and-such}."

If they say "OK, great", you've got immediate revenue to bring back to your management, and a strong case to continue doing more of the same.

Customers routinely over-and-under-estimate future value, compared to what they're then willing to pay.

They're often wrong in both directions, they usually won't pay as much as they think they will, _and_ they'll often pay far more than they think you will.

There are many, many reasons for both kinds of errors, many of which can be de-risked in advance and safely ameliorated.

As a smaller-scale contractor I just tell people what I charge. If they're not willing to play ball* get to premium compensation, no deal. It's cliché but BATNA is everything.

*I'm willing to play ball too, e.g. for a staff position I might take extra vacation in lieu of more cash, tradeoffs like that. But basically I'm not gonna take on extra hassle without being incentivized — because I don't have to and don't want to, all there is to it

If a customer requests a changelog in advance that’s one thing (should be as simply as fine-copy-paste-email), but setting up a preview sandbox is work that should be negotiated by a contract if it wasn’t already signed or in the terms of service.

You are right that previews can be a time sink. It justifies some strategic thinking because the blast radius can be big.

Someone can forget to have a separate set of terms and suddenly the support team are on the hook for supporting previews to a greater degree than expected. If features aren't locked then suddenly features get jammed in because the preview is a good hook for customers who haven't yet acquired your product.

I think the ways to approach it are:

- this incurs real costs, so we should charge for this. (The charge doesn't have to be related to the costs! But if you're doing something extra there should be an extra line on the invoice)

- this customer wants something that other customers don't have. There's all sorts of real-world services where you can pay to board the plane first or get to the front of the concert. These may be several times more expensive than the regular service. That lets you phrase it in fawning terms ("you can join our Super Elite Ultra Platinum Preview Fellows") and thereby extract much more money.

enterprise support contracts provide access to early release builds / feature flags / etc, or require signing up to be a design partner (ex: logo + joint talks)

That's customer support effort: you have to have a separate feature release communication for these beta users, and very probably some support when things go wrong because they're using a beta product.

That's also engineering effort: you need to maintain feature flags or a different environment, which is not cheap in the long run

Reply on news.ycombinator.com