What I told 16 CROs about GTM AI transformation

4 changes to make to get 2X revenue per GTM FTE

KKR, the private equity giant, recently had me present to 16 of their portfolio Chief Revenue Officers on GTM AI transformation.

To be honest, I was a bit nervous. Then I realized presenting to a room filled of CROs is as new to me as those CROs actually using AI themselves.

If the impetus for for GTM AI transformation isn’t obvious, reports already indicate that high AI adopters generate 2X more revenue per GTM FTE compared to medium and low adopters. That’s a massive difference.

Like most execs, their urgency to adopt AI equally matched their hesitancy to chart a new course. It’s hard to drive change management when you don’t know how to use the tech yourself. This isn’t their fault. They don’t have nearly as much time to tinker, experiment, and build AI skills.

The above is the reason I started the AI Run Club for GTM Operators:

If you’re a Director+ GTM operator and looking to level up yourself, then you should join the AI Run Club. We’re building an exec AI coaching program that includes highly tailored training to accelerate your skills + how you use AI internally. Our upcoming session will teach you how to build a MEDDICC self learning Agent for your team. Reply to this email if you’re interested.

One of the CROs told the room he was pausing his AI initiative. He wanted to take a step back. Think through where AI should actually fit in their GTM before moving forward.

I kept my face neutral, but was thinking:

This guy doesn’t know how to use AI himself. He’s never automated a single workflow with his own hands. And he’s going to sit down and decide where AI belongs in his organization?

We’ll come back to that one at the end.

When we talk about AI transformation, I’m not talking about whether your team has access to AI uses chat like another search engine. Real AI transformation comes from changing how the entire org operates, the infrastructure we build on, our process for shipping & iterating fast, and route to a more sustainable competitive advantage.

AI GTM Transformation needs to be led at the top and change 4 things:

1. Objective - understand and continually seek GTM alpha.

2. Org design - operate more like product and engineering teams.

3. Infrastructure - new infrastructure & primitives are needed to engineer new GTM systems.

4. Process - ship in sprints, learn, iterate, improve.

You combine these to built modern, AI-native GTM systems that help you scale without increasing headcount. These systems follow a maturity curve:

Everett Berry, Head of GTM Engineering at Clay, and I are working on experiments to build the first GTM Loops. This is the name we’re giving self-optimizing agentic systems that improve overtime by executing GTM plays, analyzing data, improving AI with learnings, and then running the next iteration of the play.

We’re not there yet. So the key is to focus on the 4 elements above to drive more effective AI implementations for GTM.

AI adoption is no longer the story – how companies embed it is. And the gap between deep adopters and everyone else is now showing up in the numbers.

Companies with deeper AI integration are outperforming peers across funnel metrics, quota attainment, and team efficiency. The gains are most visible at the top of the funnel, where AI-influenced pipeline generation is driving meaningfully higher lead-to-MQL and MQL-to-SQL conversion rates– up 11% and 8%, respectively. The impact on active deal cycles is more modest for now, but the pipeline quality improvements are real and compounding.

The organizational implications are becoming clearer too. High AI adopters run leaner GTM teams at every revenue band, suggesting that AI is beginning to drive genuine leverage rather than just incremental productivity. The same revenue is being generated with fewer people, which changes the unit economics of growth in ways that will increasingly separate high-growth companies from the rest.

Let’s dive deeper into each one steps that your org can take today to start your AI transformation in GTM.

ICONIQ 2026 State of Go-To-Market

---

GTM alpha is your North Star

The teams pulling ahead right now aren’t winning because they have better reps or a larger budget. They are winning because of this equation:

Unique data × Unique plays × GTM Engineering capability

Canva detects off-brand content across social channels and sends tailored recommendations directly to design leads. Intercom analyzes the depth of a company’s support documentation to find new verticals. Reddit find recently launched products and then recommends 3 perfect subreddits that the company should advertise within. All of them are on auto-pilot. I personally built the Reddit system.

These aren’t AI experiments. They’re systems that run semi-autonomously.

That’s GTM alpha.

---

Organization design

GTM AI transformation is more of an organizational problem than a technology problem. To solve the org transformation, think of the following:

Broadly speaking, AI has birthed new roles in 3 general areas.

New roles in AI from product building → deployment

1. AI in software engineering - the AI Engineer

2. AI in go-to-market - the GTM Engineer

3. AI in customer deployments - the Forward Deployed Engineer

Those are the doers, and we’re also seeing the emergence of new leadership types of roles within each category. For example, GitLab just posted 2 new roles:

• AI Transformation Owner, CRO [$139,200 - $235,200 USD]

• AI Transformation Owner, Marketing [$152,800 - $259,200 USD]

(Kind of interesting that the Marketing role pays better)

These are the responsibilities of the AI Transformation Owner in the CRO office:

What are the characteristics of a GTM Engineer?

They typically come from an engineering/technical background and have the slope to learn the business context, or the other way around. You do need both sets of skills.

We look for the following:

The demand for GTM Engineers and Forward Deployed Engineers are exploding in parallel.

We have both teams at Clay. Check out my previous post Rise of the Forward Deployed Engineer and video on the GTM Engineering YouTube channel:

Transition from silos to a platform team

Historically, Sales Ops, Marketing Ops, and RevOps have worked in silos. Separate teams that build for their respective departments and less for the aggregate whole.

At Clay, the GTM Engineering department consolidates these into one function, Revenue Platform.

The team is run under our Head of Revenue Platform. Similar to a software engineering team, the Revenue Platform team builds infrastructure supports the GTM team to reduce friction and ship faster. Platform teams in engineering do the same thing, but for developers.

Many debate whether GTM Engineering is the same as RevOps. At one of our panel discussions, it was debated that RevOps is more about setting guardrails and is reactive, where as GTM Engineers are more proactive and invent new ways of doing GTM.

Loading...

Before our GTM Engineering team builds anything, they must figure out how that system services all segments of the GTM org: Sales, Marketing, RevOps, and Customer Success. The silos are collapsed. The results are systems that are more deeply integrated and have a more significant impact.

If you haven’t caught onto the analogy yet, it’s this…

GTM needs to operate more like product & engineering

Modern GTM orgs operate more like product & engineering teams these days.

The guiding principle here is thinking in systems, not headcount to scale the business. You need to ask yourself: “am I scaling by adding labor or by building systems?”

Architecting and building systems aren’t the operational elements. There’s much more that goes into operating like product & engineering:

Build once, then reuse. Engineers don’t rewrite auth for every feature. They build it once, version it, and compose. GTM still treats every campaign, account plan, and sequence as a one-off. Operating like eng means your enrichment workflows, signal definitions, message frameworks, and research skills become reusable assets that get versioned and pulled off the shelf across accounts and not rebuilt from scratch every time.

Deployment & observability. Engineers ship behind instrumentation. They can see what’s running, what broke, and what changed. GTM ships a sequence into the void and finds out three weeks later when someone notices reply rates cratered. Treat your outbound motion as a deployed system with monitoring, not a set-and-forget artifact. Speed-to-lead is a good place to start: it’s a service-level objective for GTM, and most teams have no idea they’re breaching it.

Spec before activity. Good eng work starts with a clear problem definition before anyone writes a line of code. GTM skips straight to doing. Borrow the PRD habit — what signal are we acting on, what’s the hypothesis, what does success look like — and you kill most of the low-quality motion before it ever ships.

Tight iteration loops. Product runs on build-measure-learn. GTM’s feedback loop is the quarterly pipeline review. Lagging and slow. Compress the loop so a messaging or targeting change returns a signal in days, not a quarter. (This is exactly what Clay’s bi-weekly campaign board does, which you get to below.)

Ownership & on-call. In eng, someone owns the service and is accountable when it degrades. GTM systems too often belong to nobody — the workflow that “just runs” has no owner until the day it breaks. The maturity move is naming who owns the machine. It’s the same reason the function is shifting from RevOps to GTM Engineering: proactive ownership of systems, not reactive guardrails.

So how do you start operating this way?

This is the advice I gave the CRO who wanted to pause AI:

• You don’t need to go all in on GTM Engineering, yet

• Start off with 2 high impact workflows (team + individual you) and figure out how to

  • Automate

  • Apply AI

• The process helps you figure out what’s possible.

• There’s always someone tinkering with AI on the team who is building in their free time. Figure out who that person is and free up more time for them to do that. This person has potential to become your first GTM Engineer

• Start to build buy-in from other stakeholders across GTM

• At the very least, get everyone a Claude or OpenAI subscription. Have a 1 day hackathon where everyone builds a skill. Show and tell at the end of the day. Then decide which one will have the biggest impact and operationalize it.

---

Infrastructure & Process

These are the last 2 changes that go into successful GTM AI Transformation.

I ran out of room in this newsletter, so I’ll cover the 2 topics in the next post.