Check out the article in the Growth Journal published by Winning By Design
WHAT YOU’LL LEARN IN THIS ARTICLE
That GTM is a system, not a set of functions.
AI amplifies whatever already exists, both the good and the bad.
There is a right sequence for deploying AI. Most companies are doing it backward.
Revenue Operations is a system discipline, not a departmental one.
GTM ownership is a CEO decision.
Every CEO has an AI strategy. Almost none of them have answered the question of who actually owns the system it creates. Not who picks the vendor. Not who runs the pilot. Who owns the architecture: the data, the workflows, the agent layer, the feedback loops that increasingly determine whether your go-to-market actually works. AI will either absorb Revenue Operations (RevOps), automating away reporting, process documentation, and tool administration, or elevate it to the chief architect of the entire go-to-market system. There is no middle path.
The work RevOps does today is the work AI is best at eliminating.
The only version of the role that survives is one that fundamentally transforms. That transformation, and the ownership question it creates, is what this piece is about.
RevOps didn’t start as a strategic function. It started as CRM administration. Someone had to keep Salesforce from catching fire, so a team formed around data hygiene, report building, and making sure the dashboards said something useful before the Monday meeting. Then go-to-market got more complex. Marketing automation, multi-touch attribution, product-led growth signals, expansion revenue models, customer health scoring.
Each layer of complexity created a new process that needed an owner, and RevOps absorbed it. The CRM administrator became the process owner. The process owner became the system owner. The scope kept expanding as the go-to-market model became harder to operate. This is the pattern, not the exception. RevOps grows because go-to-market complexity grows. AI is the largest complexity jump yet. Which means RevOps is either about to have its biggest expansion, or its last.
The System No Longer Runs on People
Most executive teams have not fully internalized what their go-to-market has become. It is no longer a people-and-process operation. It is a system. And it is becoming a system that humans can no longer operate by hand. A modern go-to-market motion requires real-time signal detection across hundreds of accounts. Dynamic lead scoring that adapts to behavioral patterns. Automated workflow routing based on segment, intent, lifecycle stage, and deal velocity. Cross-functional handoffs that need to happen in hours, not days. Customer health models that synthesize product usage, support tickets, NPS data, and billing patterns into a single score that triggers the right action at the right time.
The problem is not the number of tools. It is the number of potential connections between them. The average company runs 106 SaaS applications as of 2024. In a stack that size, the number of possible pairwise integration points grows quadratically. Add one tool, and you do not add one unit of complexity. You add 106 potential interconnections. The management infrastructure most companies have built is linear. That gap is where go-to-market systems break. Not just at the tool level. At the interaction layer between them.
Figure 1. Number of tools vs. integration complexity
With the advent of AI, most executives believe they are on a path to consolidation. What we experience in practice suggests otherwise. Two things are happening simultaneously in most companies. RevOps is using AI to consolidate in one department, while another department adopts eight new AI tools without telling anyone. The result is complexity that quietly grows at the interaction layer as AI tools are added outside any governance structure. No single team has visibility. No dashboard tracks the whole. That is the gap where RevOps lives. Not in the tools. In the system that governs their interactions.
No human team, regardless of talent, can manage that interaction layer manually and keep pace with it. Most signals get missed. Most handoffs happen late. Most health scores trigger action after the moment has passed. AI is not enabling this transition. It is forcing it. The companies adopting AI-driven go-to-market motions are setting a pace that manually operated teams cannot match. This is not a theoretical future state. It is a competitive reality already playing out in pipeline generation, deal velocity, and retention economics. Someone has to architect and orchestrate this system. Someone has to be the translation layer between business objectives and machine execution. The question is who.
AI Does Not Fix What Is Broken. It Scales It.
AI is a multiplier, not a corrector. It amplifies whatever it touches. Clean processes, agreed-upon definitions, and healthy data become dramatically faster and more effective. Broken processes, inconsistent definitions, and messy data become dramatically worse, at scale.
An AI layer dropped onto a broken foundation produces outputs that look authoritative and say nothing accurate. The AI is not malfunctioning. It is doing exactly what it was designed to do: synthesizing the inputs it receives. When those inputs are garbage, the outputs are confident garbage.
I watch companies make this mistake over and over. They skip straight to the application because it has a compelling demo and a visible ROI story. What they are actually doing is betting on the short term — starting at the end of a sequence that has to be earned from the beginning.
Four stages have to be in place to enable AI to deliver its best work: data, process, system, and application. The companies playing the long game move through that sequence deliberately. They do not perfect each stage before connecting to the next. They get each stage connected quickly enough that the system can start teaching them what needs to improve. Learning happens across connections, not in any single stage.
Figure 2. The sequence AI requires to deliver its best work
The companies betting on the short term do the opposite. They skip to the application, patch backward when it fails, and wonder why the gains never compound. A disconnected system cannot learn. A system built right-to-left will always need fixing left-to-right. Playing the long game means building in the right order. AI scales what works. Betting on the short term means skipping the sequence and counting on AI to figure out what it needs to scale. It usually scales the wrong thing.
The Role That Has to Exist
Every major platform shift creates a new executive role. Not an upgraded version of what existed before. Something genuinely new. The CTO emerged when technology became a competitive differentiator. The CMO emerged when marketing became a system. The CRO emerged when go-to-market became too complex for sales leadership alone. Each time, a function that had been treated as operational suddenly became strategic. The market created a new seat at the table to reflect that.
AI is creating a new executive role that most do not yet have a name for.
We have started calling it the VP of Growth. Not a rebranded Head of Demand Generation. Not a marketing leader with a new title. A dedicated revenue operations role, someone who owns the growth model, the data architecture, the system, and the AI layer that connects functional teams around shared outcomes. This is the role Revenue Operations must grow into. Not exclusively, but the function that has spent a decade sitting across acquisition, conversion, and expansion is well-positioned to leap.
The market is already pricing it accordingly. LinkedIn shows 6,000 openings as of April 2026, with a base compensation range of $250,000–$350,000 and total compensation packages up to $550,000. That is not a coincidence. That is a market recognizing a function for the first time at its actual strategic value. Here is the provocative part. The Chief Customer Officer was created to unify customer-facing functions under one executive.
But that unification was organizational, not architectural. It connected reporting lines, not systems. The VP of Growth does what the CCO was supposed to do, but with actual system authority. A new executive has entered the room.
Go-to-Market as a Product
Once go-to-market is understood as a system, the organizational implications follow directly. A system needs a product organization, not a support function.
The best RevOps teams are already moving in this direction. Not by design. By necessity. They form cross-functional pods: a data engineer, a workflow automation specialist, and a go-to-market operator with deep domain knowledge. They run sprint cycles. They maintain backlogs. They do release management. They have arrived at product development vocabulary because the work demands it.
The team that owns the GTM system as a product is the team that owns growth.
The shift is to formalize what is already emerging. RevOps stops being a centralized service desk that takes tickets from Sales and Marketing. It becomes an embedded systems organization that builds and maintains the go-to-market architecture. The same transition product engineering made, from building what the business asks for to owning the product, is the transition RevOps is now positioned to make.
Figure 3. Revenue Operations as a system — responsibility by ring
The CEO sits at the center, not because they operate the system but because they make the ownership decision that gives everyone else the authority to do their job. The VP of Growth owns the architecture. The Data Architect and GTM Engineer own the infrastructure. The AI Agent Layer is the interface of the go-to-market product. It sits at the edge of the infrastructure, serving as the translation layer that protects the functional teams from the underlying complexity of the stack. The functional teams operate in the outer ring. They are not subordinate to Revenue Operations. They are the generators the system is built to serve.
The ownership question is not about reporting lines. It is about the gap between responsibility and governance. Revenue Operations carries the responsibility. They feel it when the system breaks. But without governance authority, agreed-upon rules, shared definitions, and system-level accountability, they can diagnose the problem but cannot fix the structure that keeps producing it. That gap belongs on the CEO’s desk.
The Capability Gap Is Real
This transition will not happen by reorganizing an org chart. It requires a genuine capability upgrade and an honest assessment of who can make the leap. The divide is real. If not uniform. Some RevOps professionals are already trending toward systems thinking and AI fluency. They are building automations, experimenting with AI tooling, and thinking in terms of architecture rather than administration. They will evolve into the systems architects this moment demands. Others are deeply skilled at the current jobs, reporting, tool management, and process documentation, but have not yet built the capabilities required for what comes next. The gap is not about intelligence or work ethic. It is about capability. And capability cannot be changed by motivation alone.
The RevOps role is not being eliminated. It is being elevated.
Elevation has a talent requirement that most companies have not yet considered. For the CEO, this resolves into three decisions. First, assess honestly which RevOps people are trending toward the system architect role, and what investment accelerates that trajectory. Second, build specific capabilities, data architecture, workflow design, and AI literacy, not generic AI awareness training. Third, accept that some of this capability will have to come from outside the company and cannot be developed from within.
The GTM Ownership Decision
Everything in this argument leads back to the question it opened with: “Who owns the GTM system?” And in most companies, the honest answer remains: nobody owns it. Pieces are owned by Marketing. Pieces by Sales. Pieces by IT. Pieces by nobody. The system as a whole is an orphan. You can feel it in the broken handoffs, the conflicting metrics, the tools that don’t talk to each other, the AI pilot that worked in the demo but failed in production.
The solution is not talent. It is governance.
If AI is going to become the execution layer of your go-to-market, and the pace of change makes that a question of when, not if, then system ownership becomes an executive-level decision. It determines org design, talent strategy, competitive positioning, and whether AI investments compound into structural advantage or scatter into point solutions that nobody maintains. This is not a tooling decision. It is not a department decision. It is the gap between having AI capabilities and having someone accountable for the system in which those capabilities live. That problem belongs on the CEO’s desk. So, who owns it?