GTM Doesn’t Need a Service Desk. It Needs a Product Manager.

Most GTM systems are run like a help desk. Ticket comes in, ticket gets closed, queue refills. What they need is a roadmap.

Ten teams of eight to twelve people. That’s the current shape of a software delivery org, according to McKinsey’s May 2026 research on agentic engineering: product owner, business analyst, tech lead, engineers, testers, roughly a hundred people total.

Run the same org on an agentic SDLC and the shape inverts. Sixteen teams of three to four, a product owner, a tech lead, and what McKinsey calls an “AI-enabled engineer,” someone whose job stopped being writing code and became supervising the system that writes it. The business analyst and the tester didn’t make the cut. Total headcount drops by roughly 40 percent. Total output goes up, because more, smaller pods run in parallel.

Read that twice. The number that matters is which roles disappear and which one gets redefined. The business analyst and the tester spent their days taking a ticket, doing the task, closing it out, and that’s precisely the work that disappeared. What got rebuilt, and rebuilt around, is judgment: deciding what to build, how it should be architected, whether the system that builds it is actually working. McKinsey’s own framing of the surviving engineer says it plainly: “their role is less about producing artifacts and more about supervising and improving the system that produces them.”

That is not a software engineering story. It is the clearest version of a story happening in your revenue org right now, and most GTM and RevOps teams haven’t clocked that it’s the same story.

The system was always there. Now it has a name.

Strip away the job titles and what’s actually running your pipeline, your funnel, your retention motion, your forecast, is a connected stack, process, data, tooling, wired together, producing outcomes whether anyone is managing it deliberately or not. Call it what it is. It’s a system. It was a system when it was a spreadsheet and a shared inbox. It’s a system now that it has a CRM, a marketing automation platform, a handful of point AI tools, and a RevOps team stitching the seams.

You already have a system. The open question is who owns it.

Here’s how most RevOps teams actually spend their week, and I’d bet money you recognize this even if the org chart calls it something nicer: build this report, fix this routing rule, clean this list, reconcile these two systems that don’t talk to each other, answer why a lead didn’t route correctly on a Tuesday afternoon. That’s a ticket queue. It has a queue depth, an average resolution time, a backlog of requests from sales and marketing and finance that never actually empties. It looks like work. It is work. It’s also exactly the layer AI eats first, because it’s request-shaped and rules-based, and an agent that can build the report, write the routing logic, and dedupe the list doesn’t need a human standing between the ticket and the fix.

I sat in on a planning meeting a few weeks back, cross-functional, product and revenue leaders in the same room, working through the next two quarters. The group agreed decisions had been made. Priorities were set. Everyone nodded. Then someone asked a flat, unadorned question: what got traded off to make room for what’s on there now. Silence. Nobody could produce the list. The roadmap tool showed what was in. It had nothing on what got bumped, or why, or who decided. The room figured out in real time that alignment happens in the meeting, but there’s no mechanism that tracks whether it survives the meeting. That’s the ticket-queue failure mode in its purest form: activity happens, decisions get made, and none of it is versioned or owned in a way that outlives the room it happened in.

Every company already has a working model for what comes next, sitting two floors down: the IT help desk. You submit a ticket. Someone closes it. The queue empties, refills, empties again, forever, measured in resolution time rather than outcomes. That works fine for password resets. It falls apart for the system that produces your revenue, because a help desk has no roadmap, and nobody on one is asking what the system should become in two quarters. They’re asking what’s broken right now.

What “own it like a product” actually means

Product management is not a vibe. It’s a specific discipline with specific artifacts, and every one of them has a direct GTM and RevOps translation.

A roadmap. This quarter we’re improving lead routing accuracy and rebuilding the ICP scoring model. Next quarter we’re instrumenting the handoff between sales and CS because that’s where NRR is leaking. A sequenced set of bets tied to outcomes, written down and published somewhere the whole GTM org can actually see it. A project list is whatever’s loudest this week, living in one operator’s head, and calling it a roadmap doesn’t make it one.

A backlog. A request inbox gets triaged by whoever’s loudest or most senior that week. A backlog is prioritized against a stated set of criteria, revenue impact, risk if left alone, effort to fix, and someone with actual authority decides what gets built next instead of the org’s political weather deciding it for them.

Ask your RevOps lead a simple question: what version is the lead scoring model on right now. Four? Eleven? Most can’t answer, because software ships v1, then v2, with a changelog, and most GTM systems have no version history at all. Nobody can tell you what the model looked like six months ago, or what changed the week conversion rates moved. Deliberate versioning fixes that. No version history means no way to learn, because there’s nothing to compare against.

Forty tickets closed in a week feels like a good week. It’s activity. A product team asks a harder question: did the thing we shipped move a number that mattered, pipeline velocity, time-to-value, NRR, the actual bowtie metrics Winning by Design uses to frame acquisition and retention as one motion instead of two departments. That’s the measure that counts.

A named owner. This is the one that actually matters, because the other three don’t happen without it. Somebody has to be able to say, out loud, in a room with the CRO: this system’s health is my job, here’s the roadmap, here’s what shipped last quarter, here’s what it bought us. Can’t point to that person today? Then what you actually have is a collection of tools with a budget line and no one accountable for whether they work together.

Why there’s no comfortable middle path

The uncomfortable part of the SDLC data isn’t the headcount number. There was no version of the future where the team stayed the same size and did the same work, just with an AI copilot bolted on. The request-shaped work either got automated, or it stayed manual and got outcompeted by whoever automated it first. Standing still was the one option the technology didn’t leave on the table.

RevOps is walking into the identical fork. The honest read of where most teams sit today: still fielding the request queue, still measuring resolution time, still without anyone who could produce a roadmap on demand. Nobody planned it this way. The function grew this way because every past complexity jump, a second product line, a new channel, a CRM migration, made RevOps bigger, someone had to wire the new pieces together, and that work accreted onto the team.

AI is the first complexity jump that doesn’t work like that. It doesn’t hand RevOps more work to absorb. It automates the ticket-taking work RevOps already had. The historical growth engine runs in reverse.

A team whose entire charter is field tickets, ship the weekly dashboard, is describing precisely the layer an agent plus a decent data model closes out. The team that owns the data model, decides which workflows run as agents versus humans, and owns the roadmap and the outcomes gets more valuable every time the underlying AI gets better, because someone still has to decide what it’s allowed to do and whether it’s actually working. Same fork the software engineers are standing in. Different function.

I know how this sounds coming from someone telling RevOps to promote itself. Fair pushback. I’d take it seriously if the mechanism weren’t identical to what’s happening in an entirely unrelated discipline, for entirely unrelated reasons, verified by a firm with no stake in how GTM organizes itself. McKinsey isn’t writing about revenue operations. They’re describing a fork every execution-heavy function hits once AI can do the execution. Software engineering hit it first because code is the most legible thing to automate. RevOps is hitting it now, for the same underlying reason: the execution got cheap and the judgment got scarce, in the same stroke.

The generalist the role actually needs

The person who can own this doesn’t look like the RevOps hire of five years ago. The old profile rewarded depth, the Salesforce admin who knew every trigger, the marketing ops manager who lived inside HubSpot workflows. That’s a specialist bet, and it stops paying off the moment an LLM can configure the tool, write the trigger, and draft the workflow at close to zero marginal cost.

What’s left is a generalist question: which tool, which trigger, which workflow, and how does it all fit together as one system. Someone who can move across product telemetry, the data warehouse, the CRM, and the customer journey without needing a translator at each border. I’ve watched this play out inside a $200M+ ARR healthtech company I worked with, where the operators who mattered most weren’t the ones who knew one platform cold. They were the ones who could see how a change in one corner of the stack showed up three steps later in a completely different metric.

There’s a maturity ladder I use to place people on this: Tourist, Resident, Architect. Most people start as Tourists, using whatever tools get handed to them without ever asking how the pieces connect, and graduate to Resident once they’ve gone deep on one corner of the system, the CRM, the outbound motion, the CS playbook, deep enough to know it cold but still stopping at its edges. The Architect is a different animal, someone who sees the whole stack, owns the roadmap, and is willing to answer for what it produces. It’s a posture people grow into, and the growing only happens if someone actually hands them the authority that goes with the job, not just the workload.

The twist worth sitting with

The request queue never actually goes away. Tickets still come in. Something will always be broken on a Tuesday. A team running a product still has fires. It also has a roadmap that exists independently of them, and enough authority to say no to some of the fires so the roadmap ships anyway.

Most GTM leaders I talk to can tell you their pipeline number cold. Fewer can tell you the version number of their lead scoring model, or what changed in it since Q1, or who owns the decision to change it again. That gap is the whole argument. You already run a system. The only open question is whether anyone’s actually driving it, or whether it’s driving itself while everyone stays busy closing tickets.

So here’s the exercise, and it takes less than an hour. Pull up your GTM stack and ask, out loud, in a room, with whoever runs RevOps: who owns this system’s roadmap, and when did we last ship a version of it we could name. Then sit with the harder one. What outcome did the last quarter of RevOps work actually move. If you’re coming up blank, you know exactly what needs a name: an owner.

-- J