CoreX's Marilyn Nelson recently wrote about a problem that will feel familiar to anyone responsible for a ServiceNow environment: the platform keeps moving whether or not your organization is ready to move with it.
Her recent Insights article, ServiceNow Releases Are Getting Faster. Is Your Operating Model Keeping Up?, makes the case that traditional release planning no longer covers the work. The two family releases a year still arrive on schedule, but meaningful capability now shows up between them through store applications, patches, enhancements, and a steady expansion of AI features.
Her larger point deserves time, because this stopped being an upgrade problem some time ago. It is a question of how the organization is set up to decide. With full credit to Marilyn for the thinking behind it, here are seven signs it may be time to reconsider how you manage ServiceNow.
ServiceNow planning used to have a predictable rhythm. A release approached, the platform team reviewed what was coming, testing began, decisions were made, and everyone emerged on the other side with a reasonable sense of what had changed. That rhythm is harder to maintain when useful capability lands throughout the year. Waiting for the next major release to think strategically leaves you perpetually evaluating last quarter's opportunities.
None of which argues for chasing every new feature. Please don't. It argues for someone continuously evaluating what is changing and deciding whether any of it matters to the business.
Congratulations, you are current, in the narrower sense the phrase can bear. As Marilyn points out, running a supported ServiceNow version tells you very little about how well you are using what the platform can now do.
Plenty of healthy environments still run workflows, configurations, and operating assumptions established years ago. Some of them remain perfectly good, and stability has real value when every change carries planning, testing, communication, and training costs.
Others survive because nobody has had the time to ask whether a better option exists. That is where technical debt gets quiet. Nothing is broken, the platform simply stops improving at the rate of the technology underneath it. So the better question is not whether you are current, but when you last reconsidered how you are using what you already own.
This may be the simplest test on the list. When ServiceNow introduces something meaningful, who is responsible for evaluating it? If the answer involves several people looking at each other on a Teams call, you have found the problem.
Marilyn identifies a consistent pattern among mature ServiceNow organizations: someone is explicitly accountable for paying attention. It might be a platform owner, a center of excellence, an architecture review board, or another governance function, and the box on the org chart matters far less than the accountability inside it.
Without it, improvement becomes accidental. One business unit discovers a capability at a conference, another starts experimenting on its own, and a third hears about it six months later, right up until somebody asks whether you already own something that does this. Always a fun meeting.
ServiceNow has made deploying technology relatively straightforward. Humans remain stubbornly human. A feature can be configured correctly, tested cleanly, deployed on schedule, and still disappoint, because users never folded it into the way they work.
New workspaces disrupt established routines. Automation shifts responsibilities between teams. AI changes how people find information and make decisions. Even a modest interface improvement costs productivity while employees relearn habits they spent years building.
Organizations underestimate all of this because the technical work looks finished at go-live, which is precisely when the user's work starts. That is why adoption capacity belongs in platform planning alongside delivery capacity, and why the question "how quickly can we deploy this?" needs a companion: how much change can this organization reasonably absorb right now? Your developers may be ready Tuesday. Susan in Procurement has other plans.
AI has raised the stakes on all of this, because evaluating a capability now involves considerably more than functionality, licensing, and implementation effort. There is data quality to weigh, along with governance, security, oversight, process maturity, user expectations, and risk. And somewhere, inevitably, someone has already scheduled the demo.
ServiceNow can make an AI capability technically available well before an organization is operationally prepared to use it responsibly, which gives platform leaders a new job: separating availability from readiness. That is an argument for preparing the operating model at the same pace as the technology, rather than an argument for deferring AI.
Skip that work and you can end up deploying genuinely sophisticated technology to accelerate a process nobody has cleaned up since 2019.
If platform innovation is continuous, roadmap management has to become continuous too. In practice that means business stakeholders surfacing emerging needs year-round, architects weighing longer-term platform implications, security assessing new risk, governance groups reviewing priorities, and platform teams continually comparing what ServiceNow can do against what the business needs. Formal release planning still matters, and continuous planning is what makes those windows productive, because the important conversations started months earlier.
Marilyn's original article offers a useful example. One large healthcare organization CoreX works with runs ServiceNow as the operational backbone for clinical, administrative, and enterprise services, and had reached a point where backlog growth and technical debt across the platform and CMDB were outpacing internal capacity. It also wanted to prepare for greater automation and AI adoption without disturbing daily operations.
Having concluded that neither staff augmentation nor project-based delivery could sustain that pace, it moved deliberately to a continuous delivery and optimization model. Enhancement and optimization work now runs in repeatable two-week sprints against product owner priorities, quarterly advisory sessions set roadmap direction, and platform health scans feed the backlog, all inside the change and release governance a regulated environment demands. The roadmap stopped being an event and became part of operating the platform.
This is the hardest sign to spot, because enthusiasm for innovation looks like a virtue, and usually is one. But every new capability creates a decision, and "yes" should not be the default simply because something appeared in the release notes.
Does it solve a problem you actually have? Does it replace something that already works? Will it simplify operations or add another process to learn? Is the underlying data mature enough to support it? Does the business have room to absorb another change this quarter? Is something more valuable competing for the same people?
Sometimes the answer is yes and sometimes it is no. Quite often, as Marilyn points out, the mark of a mature platform organization is comfort with "not yet," which reflects a judgment about timing and sequencing rather than resistance to innovation.
The thread running through Marilyn's article reaches well past release management. ServiceNow environments increasingly need to be run as continuously evolving enterprise platforms, which requires holding room for stability and exploration at the same time, balancing operational demands against optimization work, and weighing new technology against the business's capacity to absorb it.
A platform that evolves deliberately rarely feels dated, because it reflects what the organization cares about now and somebody has done the work of keeping the two aligned.
That balance is difficult for a structural reason: the people expected to evaluate what is coming next are usually the same people keeping everything running today. Which may explain why your strategic roadmap keeps losing to Tuesday afternoon's incident queue.
For CoreX, that constraint is part of the thinking behind CoreXtend, which supplies a subscription-based pod of certified specialists to absorb day-to-day administration and prepare and support upgrade cycles in repeatable sprints.
The roadmap and architecture judgment surrounding those cycles comes through CoreX advisory and governance engagements, contracted separately. Marilyn's original question is still the right one for any ServiceNow leader to sit with: is your operating model keeping up? We would add a second. If ServiceNow keeps getting better throughout the year, why are you only deciding how to use it twice a year?