Introducing a New Release Cadence and Beta Feature Center in Gainsight CS

“we’ll no longer publish separate Early Access Release Notes”

​​​​​Does this mean that all new updates/enhancements will become on-demand?  You can’t just release changes without us having advance notice to assess impact to our systems and processes, prepare users internally and shift work where necessary to accomodate, as well as be able to raise concerns ahead of the release.

The whole reason GS originally moved to a quarterly release cycle and Early Access Release Notes process previously was due to significant feedback from the admin community regarding the need for predictibility and allow customers to gauge/assess impact to ensure stability and minimal disruption.  This feels like a large step backwards. 

Salesforce publishes advance documentation and provides sandbox previews weeks ahead of a release for this exact reason.  CS is also a very complex platform that often serves as the connection point between multiple platforms and requires significant rigor and maintenance to build and maintain. And for many customers, like me. a solo admin to manage it. 

 

I’d echo everything Jeff said -- I’m all for consistency and increased speed of releases, but our organizations also need to know what each release will entail so we can best prepare our stakeholders. This is especially true given that Gainsight releases happen on the weekends and there have been plenty of instances where a feature has launched turned on & not gated to admin review.

I’d rather have too much notice and have items slip to a later release if it’s determined that it isn’t GA ready than be caught off guard logging in on a Monday morning to new items that I haven’t had time to review. That was what your early release notes helped with.

+1 to Jeff

This introduces a new source of risk for unplanned changes, especially when items are released enabled by default. When the release is live it is already too late to collect valuable feedback, this is painting a very specific picture to your community. 

When I first started working with Gainsight, there were monthly releases. It was pretty chaotic, because it was extremely challenging to plan - let alone review and do any work with - new features before the next one came out. There was minimal to no advance notice, and you’d have to hunt around to find what broke in your instance or workflows needed adjusting.

It felt like playing whack-a-mole.

After a lot of feedback and collaboration with admins, this was modified to quarterly releases. This was great, because we had time to digest, alter roadmaps, make changes, etc. It was still a bit harder to plan, because aside from the occasional broad strokes, we didn’t know what was coming.

After more feedback and collaboration with admins, we got advanced release notes. This was a great change, because while there were still some issues, we at least had an idea of what was coming so we could plan around it.

Then at some point - we got this: “Until now, Gainsight CS updates have come through different release motions, including standard and On-Demand releases.”

I don’t recall anyone really clamoring for this. It seemed like a solution to a problem that didn’t exist. Now that solution has become its own problem, and we’ve invented a new way to solve it instead of rolling back to what worked before:

“We’re bringing those together into one six-week cadence, which gives you a clearer schedule to follow and removes the extra step of submitting a support ticket to access eligible features.”

I’m not opposed to quickening the pace of releases a bit in general - I get it, the market wants more faster and there can be high quality, usable, quality of life/impactful updates sooner, that’s great.

However, experience has shown that faster usually means “feels rushed”, and in combination with having less visibility on what is coming that seems like a terrible combination and a reversion of a lot of trust built up with the community for years.

Yes, there are product roadmap calls, but those are always much more speculative, and seem more marketing oriented than technical oriented which is the audience here.

I think there would be many members in the community still interested in collaborating with Gainsight on a mutually beneficial approach instead of one that comes across as rebranding a regression as a feature.

Agree with the rest of comments. We need the early access release notes to properly plan and flag any potential issues.  I also want to flag the in app communications - I’m not against admins receiving in app communications, but it’s not a great experience to have end users receive the same communications on the day of release, before admins have a chance to vet the new features. 

A bit confused by the wording here:

With this more frequent release cadence, we’ll also no longer publish separate Early Access Release Notes.

With each release, we’ll share details on what’s included and call out any setup, configuration, or preparation admins should be aware of. 

Will you not be giving us an early heads up to what we will need to configure until at the time of release? I am a definitely perplexed by this move I have not worked with a CRM platform that does not publish early release notes for Admins. What is the rationale for the decision here? Doesn’t Gainsight also get valuable early feedback from these notes? 

We work in sprints and need to plan, and its very inefficient to have a…. “not sure what Gainsight is going to release this sprint and how much time it will take, but we need to plan for it.” story. We plan our work based on what the early release notes show will be in our pipeline. And we can start crafting communications for impacts on our end users prior to the release.

Please reconsider this change! 

Adding my additional comments here. I agree with all of the above, especially in-app comms. This was a HUGE discussion point in a recent product call as a hard “no” that was agreed to for comms that might go out to end users. Can you confirm if it will be admin/primary only users who get it, and if not and it goes to everyone, why the renege on that? Biggest issue here will be that teams don’t adopt all features all the time, especially for AI related features now which are very muddy due to security and privacy and accessibility concerns that have yet to be addressed.  Simply put, GS should not be releasing all feature details to end users.

I would like to know how many changes are made between when advance release notes are published and the release?  It seems there are really good comments and adjustments made prior to releases with the existing process.  How will that information be gathered and implemented with the new release process?

I have several of the same questions asked above. Please let us know more, thanks.

I agree with the concerns raised by others in this thread. Pushing updates directly into production creates real operational challenges for CS admins and operations teams.

As admins, we know our teams and our processes best. A fixed release cadence into live environments—without adequate preview time or control over deployment—directly contributes to tool fatigue and disruption for our end users:

• To properly train our teams, update internal enablement materials, and test configurations, we need a meaningful preview period before code hits production. or at the very least details of what’s changing and how

• One size does not fit all. We need the ability to toggle features on or choose when to roll them out to our teams. 

• End users are already dealing with constant updates across their tech stack. When updates land without our explicit go-ahead, it creates unnecessary confusion and erodes trust in the tool.

A predictable calendar is nice, but admin control and proper preview windows are essential to driving meaningful adoption.