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

...we’ll also no longer publish separate Early Access Release Notes. Instead, we’ll focus on sharing the most current information at the time of release, when features are ready for customers to use.

Did someone ask ChatGPT what an “efficient” method for releasing updates would look like and not proof-read the output before marketing it?

I’d love to know the reason behind not publishing these notes before release, because as others have said this will most certainly lead to confusion and distrust. It’s already resulted in frustration and the first release hasn’t even gone out.

Having those Early Access Release Notes allows me to review what to expect and what to relay to my stakeholders. It also allows me to get in front of any changes that will affect my stakeholders before panic comes about. And as a sole admin I need all the time I can get.

Please, reconsider providing the Early Access Release Notes so us admins can continue doing our jobs to the best of our abilities.

I’m also interested why the decision to remove Early Access notes - you kind of already had weaponized us nerds to QA everything to avoid any whoopsies in miscommunication or catch an early oversight, that’s the dream for all parties involved, no?

Many other things were said already

+100 echoing what all other admins are saying here.

I really value the Early Access Release notes as they are, particularly the ability to comment on the working Google doc with the Gainsight team before it is published/live. This not only gives us a heads up for what's coming and enables us to take appropriate action (or provide appropriate warning for the features we have no choice in turning on), but I strongly believe it also allows the Gainsight Product & Development team to get crucial insight from “boots on the ground” users of the downstream impact and wider implications of the feature launches. As Angela noted in her comment, we’ve seen adjustments made prior to releases based on the feedback that admins are providing which strengthens the trust between Gainsight and its users. Removing admin ability to have a clear communication channel with product seems like a step in the wrong direction.

+1 to what my fellow admins said above. This seems kind of like a step backwards from where we’ve been with quarterly releases + advanced release notes. 

Especially want to echo Britt’s point here:

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 really would expect to fully understand what is coming out prior to the release.  If we are planning out our work, in similar cadences, often 2 week sprints with our own release windows, we need to be able to plan for changes, including what impact those things have on our systems, and understand if there is anything we need to adjust in our plans to do this.  

If the release notes will still come out, like the Early Notes did, then I think this is similar to what’s been happening, but it doesn’t sound like it.  We should have time to plan for changes, so that we can share with the teams using the system, otherwise we’ll start getting tickets from users about something not working right before we’ve even had a chance to read the 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 we be told what is changing before release so that we can prepare our instance and teams? 

Knowing what is changing prior is key to good enablement and product adoption.

A few additional concerns I have with this change:

Six weeks already seems like a very short amount of time for admins to review a release, understand the impact to our existing configuration and processes, test changes, communicate them to users, and make any necessary accommodations. Removing the Early Access Release Notes makes that window even smaller if the detailed information is not available until the release actually goes live.

I'm also concerned about how fixes will work with this new cadence. Historically, releases have sometimes introduced issues that required patches or follow-up fixes. With significantly more frequent releases, it seems like there is also the potential to introduce issues more frequently. How will patches, hotfixes, and other fixes fit into this six-week cycle? Will fixes continue to be released as needed between releases, or will some fixes wait for the next scheduled release?

I also think there needs to be a way for customers to control when newly released functionality is exposed to their users. The Beta Feature Center helps while something is in Beta, but if the toggle is removed when a feature becomes GA, that doesn't give admins a way to hold a new GA feature while we test it and prepare our organization.

Could there be some type of release or feature gating that allows an admin to keep new functionality disabled for a defined period of time and enable it on our own schedule? That would give us time to validate changes in our environment, update documentation and training, communicate with users, and identify any issues before introducing the functionality broadly.

A predictable six-week release schedule is helpful, but predictability of the release date doesn't replace the need for advance visibility and control over adoption.

This is going to be challenging for our larger organization where adoption of Gainsight continues to be a blocker - bottom line for us is that change is hard and dealing with resistance to change is even harder.

Different areas or features within Gainsight can mean everything or nothing to a user or group of users. It seems like, with this decision, Gainsight is banking on those features that they hope mean nothing to users. But I imagine it could be different from one GS customer to the next.

I echo the sentiment of my colleagues in that there needs to be a toggle built in for each feature change broken out by release.

• Q4 2026 Updates
  • Feature Area 1
    • Toggle 1
    • Toggle 2
  • Feature Area 2
    • Toggle 1
    • Toggle 2

Either that, or GS needs to start cataloguing custom releases somehow with each customer where a customer opts in or out to the new release features (sounds like a nightmare though).

This information is very helpful to see, because it wasn’t previously made clear in the email communication or release webinar that all of this would be changing along with the cadence of releases.

First, the good:

• Beta Feature Center - assuming this will be in-product, this will help to address one of the clear blind spots for admins today--what features are in beta, how we learn about and enable new beta features
• Simple, predictable release schedules are helpful for admins to prepare.

Now, to echo many of the concerns raised here where it feels like we are regressing:

• Losing the Early Access Release Notes is extremely unfortunate. Admins like us rely on these to get an early heads up of what’s changing, how it may impact our users, our tenants, and our business, and how to plan incorporating the changes into our roadmaps and to our people. I hope that Gainsight re-considers this decision and listens to the feedback from their community of customers here.
• “Admins will continue to have visibility into what’s changing and what, if anything, they need to do before a feature is available to users.” → This is unclear. Does this mean we will still have a heads up of features that will require admin configuration, but not others?

Many of us admin teams run extremely lean and are tasked with managing a large amount of responsibilities to ensure platforms like Gainsight CS are driving value forwards for our businesses. 

As an admin I’d like to see more ways introduced to make release schedules easier, allow us to feel more prepared, and given controls to allow us to introduce the new features while considering all of the nuances of our businesses.

This feels like a step backwards, not forwards. 

A step forwards could be allowing admins to receive early access to the new features in sandbox, and maintaining the early access release notes to allow us to review the supporting documentation for changes and new features before they hit our production environments.

Agree with my colleagues. We need to know in advance what’s coming to be able to ensure it isn’t breaking something within our workflow or violating our Security/Privacy policies.

With no advanced notice, we don’t have the opportunity to adjust workflows and rules to allow that feature to be used, We also don’t have the ability to help get our CSMs ready for changes and training on how to use new features.

I will also say that we need the ability to turn things on as we are ready for them and have them approved through our internal security and privacy channels. We have internal policies that sometimes will limit us being able to use certain features.

On updates being shared with all users in-app. I second the notion that this is bad policy. Some of these features may be reliant on other capabilities that we have not configured and aren’t using. We (the admins) need to be able to designate what updates are published to our users.