Your GTM Stack Is an Expensive Mess. AI-Native Companies Figured Out Why.

28% of reps hit quota last year. Down from 44% the year before. Reps are juggling eight tools to close a single deal, spending 72% of their time on non-selling activities, and sales cycles are 38% longer than they were in 2021.

We spent a decade buying tools to make selling easier. We made it harder.

And the typical response - swap vendors, retrain the team, hire another SDR - is treating symptoms whilst the actual disease spreads. Because this isn't a tooling problem. It's an architecture problem. And the companies that have figured that out are operating in a fundamentally different way from everyone else.

The Frankenstack

The average B2B org runs 305 applications. Only 5% of RevOps folk reckon their stack is fully utilised. 53% of licences sit unused.

Every vendor sold a point solution to a point pain. Nobody designed how they'd work together. The result is what I'd call a Frankenstack - six, seven, eight platforms stitched together with Zapier and prayer, where completing a basic workflow requires three systems and two manual handoffs. 72% of RevOps teams are losing more than 10% of revenue to process gaps alone.

It's $2 of sales and marketing spend for every $1 of new ARR. That ratio tells you everything about a sort of structural rot / architectural debt that no amount of vendor swapping will fix.

Meanwhile, cold email response rates have fallen 41% since 2019. Google and Yahoo tightened sender requirements. Microsoft followed. 80% of the buying journey happens without vendor contact now. Same sequences, same tools, same data - everyone running the same playbook and wondering why it's stopped working.

The Inversion

AI-native companies have figured this out - and their response isn't to buy better suites. It's to build composable systems from scratch.

The philosophy shift is what matters. Traditional GTM ops buys best-in-class platforms, configures them, and maintains them. Service mindset. Project-based. The new model treats GTM infrastructure the way engineering teams treat product infrastructure - something you build and ship in sprints. Product mindset. Outcomes-based. Fewer tools, more tightly composed, iterated on weekly rather than configured once and left to rot.

And the economics are mad. Clay's waterfall enrichment runs at roughly $0.01 per record versus ZoomInfo at $0.25. OpenAI went from 40% to 80% data coverage after switching to Clay. n8n processes AI workflows in 2.4 seconds versus Zapier's 5.5. When the composable stack is both cheaper and faster, the integrated suite starts looking like a legacy tax.

Cursor hits $1B ARR with 300 people - that's $3.3M per employee. Lovable reached $100M ARR in eight months with 45 folk. Traditional SaaS median? About $112K per employee. The companies operating at 7-8x that productivity ratio aren't running Frankenstacks (unsurprisingly). They're building lean, composable systems where every component earns its place.

It's Already Happening

This isn't a future trend piece. I track GTM hiring across AI-native companies weekly, and the data from this month tells a clear story.

210 GTM roles across five companies: OpenAI (132 roles across 16 distinct functions), Clay (30), ElevenLabs (24), Notion (19), Anthropic (5). 70% of those roles explicitly require AI building capabilities - not "familiarity with AI tools" but actual building skills.

Top skills in demand: cross-functional collaboration (25.7%), pipeline generation (10%), experimentation (8.6%), technical understanding (7.1%). These aren't ops support postings. They're building roles with product mandates.

And the companies are structuring around this differently from what I'm seeing. Verkada automated 80% of their SDR workflows - their MDRs only engage on response now, generating roughly 120 meetings a month versus the 20 you'd get from a typical SDR setup. That's 4-6x the output. Rippling doubled YoY cold email performance using Clay across a 30-person growth team. Not by working harder. By building better systems.

Ramp runs a Growth Platform squad with two-week sprints, shipping internal prospecting tools and AI outreach flows. Notion has three separate teams collaborating on GTM infrastructure - RevOps & Strategy, BizTech & automation engineering, and an embedded AI engineer. Anthropic has a "Productivity Engineering" sub-squad using Claude and Clay. Clay's own internal team runs deliberately minimal: Clay, Snowflake, Salesforce, Gong, and a custom Slack app. Sprint cycles, release notes, measured outcomes.

These aren't isolated experiments. They're organisational architecture decisions - treating GTM systems like products, not support functions. Internal product teams, not service desks.

Juniors With Tool Budgets

From what I'm seeing, the biggest gap isn't tooling. It's how companies are approaching the shift.

Most are assigning relatively junior talent to "experiment with AI tools." Nice UX, nice UI, lightweight workflow tweaks. But when a CRO is trying to grow from £100M to £500M, getting a junior to explore ChatGPT plugins isn't going to have material impact on 5x-ing total turnover (harsh but true). Setting a KPI for someone to use some shiny new tool and then expecting that to translate into a material step-change in revenue... that's not a strategy. That's a box-ticking exercise.

The companies actually making this work are doing something fundamentally different. They're hiring senior folk with commercial acumen and giving them product mandates - sprint cycles, release notes, measured outcomes. The gap between intent and execution is a seniority and empowerment problem, not a technology selection problem.

There are roughly 1,380 practitioners globally who've made this transition versus 2,100 open roles. Supply-constrained from the start. And pattern recognition compounds faster when the discipline is this new - someone who's built successful signal-based systems across three companies in the last 18 months has exponentially more useful knowledge than someone experimenting in isolation. The feedback loops are compressed, so experience accumulates faster than in any established GTM function.

Industry specialisation will matter too, from what I can tell. Deep sector knowledge - understanding procurement cycles in healthcare versus fintech, knowing which compliance triggers matter in financial services - becomes a proper moat. You can't automate domain expertise. The tools are democratised. The judgment isn't.

The Historical Pattern

Every major GTM operations role emerged from a structural technology shift. Sales Ops from CRM adoption in the 2000s. Marketing Ops from marketing automation in the 2010s. RevOps from tool proliferation around 2018 (Forrester popularised the term, and it became one of the fastest-growing job titles by 2023). Each time, the companies that recognised the shift early built 5-10 year execution advantages whilst competitors scrambled to catch up.

GTM Engineering (or whatever it ends up being called - the label matters less than the function) is the AI wave's creation. Not a new discipline, really - closer to the democratisation of growth engineering. The growth engineering role existed circa 2010-2015, born from the growth hacking movement that got momentum from the likes of Dropbox. But it required dedicated technical talent. Platforms like Clay, n8n, and LLMs from Anthropic and OpenAI made it possible for semi-technical operators to build what previously required a proper engineer. That's the shift - not revolution, but democratised access to building.

The function is splitting. Builders handle pre-pipeline work - prospecting, architecture, workflow automation. Operators handle in-pipeline work - closing, process design, system administration. From analysing 2,760 LinkedIn profiles, these roles occupy fundamentally different positions in the value chain. GTM Engineers are 25x more likely to focus on prospecting. RevOps is 5.7x more likely to focus on closing. Not competing titles. Complementary functions that happen to sit under the same GTM umbrella.

The Window

McKinsey's data shows companies with leading AI capabilities outperform laggards 2-6x in total shareholder return. But only 6% qualify as AI high performers - and the difference isn't whether they use AI (88% do). It's depth. High performers deployed twice as many use cases and were 2.8x more likely to redesign workflows before automating.

That last bit matters. 95% of enterprise AI pilots deliver zero measurable P&L impact because folk automate before they have clean data, defined processes, or a validated ICP. The winners earmark 50-70% of budget for data readiness before touching automation. They redesign workflows first, then select tools - not the other way round.

The architectural shift is here. The question isn't whether your GTM operating model needs to evolve - it's whether you're building the capability now or catching up in three years when the execution gap is a sort of insurmountable compounding problem...

And from what I can tell, the window for getting ahead of this is narrower than most folk reckon.