Live data from Hacker News

Ask HN: Handling customers that want feature previewing?

news.ycombinator.com

21–30 of 68 posts

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

#21

I had a similar situation in fintech. We had 3 different release cycles and hosting farms for fast, medium and slow accepting customers. Fast went to the customers who didn't require approvals, and who were flex when it came to errors in the release. Then there was a medium channel where the other customers were fine as long as a couple of the major customers in that pack approved things. The slow channel basically w…

Would this break down if you had 10 customers that would prefer the slow channel of release, but each had their own ever so slightly different desired release pace or training requirements?

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

#22
post #17

Sounds to me like the customer is trying to solve a problem and is coming to you with their chosen solution. My suggestion: Find out what problem they are trying to solve, and address that . Also, you might look at cPanel's notices that they send out where they explain upcoming feature updates well in advance of the rollout. They also have different release cycles, where the newest features are released to the EDGE c…

> Sounds to me like the customer is trying to solve a problem and is coming to you with their chosen solution. My suggestion: Find out what problem they are trying to solve, and address that. This. Problems they might be trying to solve: * want to be able to jump on new features as soon as they are released, but need to plan with the eng team * want to be "in the know" so not surprised by new features * want to be ab…

Honestly some customers I've encountered have asked for stuff like this (and similarly meetings to go over product roadmap) almost as a power play. Either to see if they can get us to do it, or to feel like they have control over our development. If you're small enough and the customer is big enough, you might not have any choice, but I resist it pretty strongly unless it would be financially ruinous to lose the customer (and we have never lost a customer over refusing to do it).

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

#24
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…

+1 on feature flags. Set up your flags so you can disable features for certain customers, or groups/classes of customers. Delivery and release can then be separated. Release frequently, deliver features when it makes sense.

Also recommend making sure customers know that this is time-limited, otherwise you end up supporting too many different configurations of your product.

Also if these are customers you're in regular contact with, you can preview your roadmap or demo features that are coming soon. This helps them feel in the loop, and gives them a chance to provide feedback.

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

#25
post #21

I had a similar situation in fintech. We had 3 different release cycles and hosting farms for fast, medium and slow accepting customers. Fast went to the customers who didn't require approvals, and who were flex when it came to errors in the release. Then there was a medium channel where the other customers were fine as long as a couple of the major customers in that pack approved things. The slow channel basically w…

Would this break down if you had 10 customers that would prefer the slow channel of release, but each had their own ever so slightly different desired release pace or training requirements?

Key word "desired". Make the slow channel the longest reasonable time that any of them want. If they want shorter, well, there's medium channel or slow. You pick. If they want even longer, well, there's slow channel, and it's good enough for these 10 enterprise customers.

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

#26
post #15

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…

Thanks for sharing! Was the beta channel that you had in the pipeline for prod? i.e. prod would have no chance of getting ahead of beta because prod was always deployed based on what was last on the beta release? Hot or bug fixing is an interesting topic because you could end up with diverging histories if you're not careful. Did you try to maintain `master` as the single source of truth or did you make separate rele…

We created rc/xxx branches in git. Developers would merge feature branches destined for beta to the rc. The rc gets deployed to the beta environment. Later, we would merge the rc to master and then deploy master to both prod and beta environments.

Prod would be ahead of beta during hot fixes. Though we try and avoid it, it did happen occasionally.

You are correct that it took some extra effort to keep it all clean and manageable.

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

#27
Difficult to answer without understanding how you are deploying currently. I do think feature flags can be an anti pattern. I would ask the customers why they want it in the first place. Is it a trust issue? Is it an internal process that they require? Ideally you would want to stay flexible, that would mean not tying your company to their schedule. It is a hard application to deploy multiple times for each customer. Perhaps a more lts approach for those customers might work. Just keep in mind the larger the releases get, the more issues it might cause.

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

#28
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 management. I'm frustrated with how much money I believe we are leaving on the table, even if it doesn't directly benefit me.

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

#29
post #21

Earlier quoted context omitted.

Would this break down if you had 10 customers that would prefer the slow channel of release, but each had their own ever so slightly different desired release pace or training requirements?

Key word "desired". Make the slow channel the longest reasonable time that any of them want. If they want shorter, well, there's medium channel or slow. You pick. If they want even longer, well, there's slow channel, and it's good enough for these 10 enterprise customers.

Yes.

There are always requests and negotiations in play. But those three channels sufficed almost all the time. At times we'd combine channels if there was an urgent need and agreement from customers.

The slowest customers were the most enterprise-y. Things almost couldn't go slow enough for them. When there were complications to the release process, they could be a release version or two behind and there'd be a catch-up release.

We also had customers outside all of this, and had custom releases, and we charged very high fees for this. Ultimately, we were able to bring them back into the slow release because the extra work wasn't really worth it. Part of the requirement for these kind of customers is to have additional engagement efforts to make sure their internal teams were really aware of the details and contingencies of releases. Big companies move slow and need over-communication, and you can't trust them to do it themselves. It was more effective to take that responsibility on ourselves.

I preferred to take the things that were difficult and do them more often. Keeping a cadence to things kept everyone together. The minute you break cadence -- and entertain special circumstances -- it's really hard to get back on cadence, and that cadence includes testing, notifications, documentation, feedback, approvals, releases.

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

#30
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…

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.
Post reply on HN