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…
Ask HN: Handling customers that want feature previewing?
21–30 of 68 posts
Re: Ask HN: Handling customers that want feature previewing?
#22Sounds 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…
Re: Ask HN: Handling customers that want feature previewing?
#23Re: Ask HN: Handling customers that want feature previewing?
#24Feature 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…
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?
#25I 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?
#26I 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…
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?
#27Re: Ask HN: Handling customers that want feature previewing?
#28Most 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.
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?
#29Earlier 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.
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?
#30Most 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…