Live data from Hacker News

Ask HN: Handling customers that want feature previewing?

news.ycombinator.com

61–68 of 68 posts

Re: Ask HN: Handling customers that want feature previewing?

#61
post #23

Most of the discussion here will be technical, especially around feature flags and friends. That’s fine, but please don’t miss out that this is a clear signal to charge these customers a lot more money.

> 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 managemen…

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.

Re: Ask HN: Handling customers that want feature previewing?

#62
You need to consider the blast radius and how long features may be in preview. Ideally, you would scope the preview to just a subset of users. When you go to a complete customer base you start to get into the situation where the customer has failed to communicate with their users, and have more people raising issues. This isn't bad necessarily, but you have to be prepared to handle it.

If you keep something in preview for a long time then there can be a divergence from the main product. Make sure that data or work from users is migrated across when you finally release.

It makes sense to think about the opportunity for support to participate in the preview. Let them listen in to customer calls and learn about the problems. Providing a dedicated support person for previews is tempting, but long-term it's better to avoid this specialization and enable the whole support team to participate. This shares knowledge and avoids certain people being granted special privileges while others toil on average support tickets.

Microsoft publish some of their methodology at https://docs.microsoft.com/en-us/microsoft-365/admin/manage/.... The key point is that they have set out the boundaries for their program so that customers know what to expect and it can be repeated for every customer.

You will have to learn how to do your previews, but you should lay down some rules. Set it up so kudos from participants can be used for marketing after. You are the one to decide when the preview ends, but setting some minimum time in preview gives customers more confidence and time for you to process feedback. Make it clear if features are locked when you enter the preview and what feedback you are after.

Once the preview is over, thank the participants. Call them out if you have a public forum. Participation can become a mini case study for your marketing efforts.

Re: Ask HN: Handling customers that want feature previewing?

#63

Earlier quoted context omitted.

> 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 managemen…

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.

Re: Ask HN: Handling customers that want feature previewing?

#64
post #23

Most of the discussion here will be technical, especially around feature flags and friends. That’s fine, but please don’t miss out that this is a clear signal to charge these customers a lot more money.

I'll offer an illustration. We sell our SaaS at X. We have a customer that needed stronger SLAs and servers located in Europe. They pay 8X and (I think) both sides feel like they got a great deal.

So to paraphrase Arubis, this is a business question,not a tech question. At what price point is the technical investment covered ?

Re: Ask HN: Handling customers that want feature previewing?

#65
post #9

Feature flags is usually how we handle this. We have the flags anyway for developer use, so making them user specific was not that much incremental effort though we have had a few cases where old workflows were not removed when they should have been. We did once have a customer with their own environment with a different version deployed, as they were initially a major client with such demands but after a few years i…

That's about the only answer, although feature flags are hell. Once you have a feature flag, you now have 2 versions of your product. 2 feature flags, that's 4 versions to maintain, etc. Make sure you don't conflate "feature flag" and "setting", and make sure you clean up these flags when they're uneeded (and actively push the business to make them unneeded!).

Fowler has a good write-up about different types of feature flags: https://martinfowler.com/articles/feature-toggles.html

Re: Ask HN: Handling customers that want feature previewing?

#66
post #23

Most of the discussion here will be technical, especially around feature flags and friends. That’s fine, but please don’t miss out that this is a clear signal to charge these customers a lot more money.

> 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 managemen…

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

Re: Ask HN: Handling customers that want feature previewing?

#67
post #12

Context: financial SaaS of interest to banks, brokerages and RIAs; no direct-to-consumer at this time. We have two special case preview environments. They're set up just like production, but with lower capacity and no SLA. The first one is general previews of what we're planning on releasing; it's a normal part of our release process and every release is there for 2-14 days before going to production. All customers h…

I would seriously consider not allowing special treatment in cases like this. In my experience things like this can be a slippery slope. Decide what is most broadly reasonable for both your company and your customers, communicate it well, and then spend time and energy on your core product.

Re: Ask HN: Handling customers that want feature previewing?

#68

I also had a handful of customers like this. We ended up creating an opt-in “beta” channel that we treated as a first-class citizen along with “prod”. Basically we had 2 production stacks with CI/CD for each. The only shared thing was the AWS ALB. Our customers each have their own subdomain so we used that to point to different EC2 ASGs. We would continue pushing bug fixes to “prod”. Once a beta period ended, we merg…

Do the two stacks each have their own database? Have you had customers wanting to move back and forth between channels?
Post reply on HN