Insights

The frameworks behind
the infrastructure that scales.

Diagnostic models, reference architectures, and operator perspectives on fixing the GTM foundation — from territory design to AI deployment.

The AI-Native GTM Architecture

A reference model for diagnosing the modern revenue stack. Buyer signals flow through five integrated layers — data, orchestration, action, conversion, and revenue intelligence — aligned to functional ownership across RevOps, Marketing, Sales, and Customer Success, with foundation models and agentic workflows embedded across every layer.

Used in operational efficiency assessments, AI readiness diagnostics, and stack rationalization engagements.

AI-Native GTM Architecture — Five-layer reference model for diagnosing the modern revenue stack
Get the full-resolution PDF

Print-quality version of the AI-Native GTM Architecture for your next stack review or planning session. Enter your work email and it downloads immediately.

No newsletter, no spam. I may follow up once if your GTM stack looks like a fit.

The Split Playbook: Enterprise Rigor Meets High-Growth Speed

On one side, AI-native companies are hitting $400M ARR in under two years with 150 people. Consumption-based pricing, PLG motions seeding enterprise pipeline, org structures that look nothing like what existed five years ago.

On the other side, enterprise sales orgs are still running annual planning cycles, setting quotas from top-down spreadsheets, and managing territories in systems that don't talk to each other.

The data tells the real story: 76% of B2B organizations are now deploying agentic AI in their GTM functions. But 88% of those pilots never reach production. The gap isn't the AI. It's the operating model underneath it.

The companies that will win aren't on either extreme. They're the ones that can take the rigor of enterprise GTM infrastructure and run it at the speed the market now demands.

I spent 25 years building that infrastructure at Oracle: territory design, quota architecture, incentive compensation, and budget governance connected through a unified planning platform supporting 10,000+ sellers. That's the foundation high-growth companies hit a wall without once they pass $100M ARR.

But infrastructure without speed is just bureaucracy. Enterprise GTM teams that can't move to continuous planning, real-time territory intelligence, and governed AI-assisted decision-making will lose to smaller competitors who built it from day one.

Three things I'm watching in 2026: continuous planning replacing annual cycles, where the companies building rolling scenario models that update weekly are outpacing the ones still locked into Q4 territory redesigns that go live in Q1. Consumption-based models forcing RevOps to rethink comp design, because when revenue scales with usage instead of seat count, the entire quota and territory framework needs to be rebuilt. And the "agentish vs. agentic" question becoming the defining GTM operations decision, where the real conversation isn't whether to deploy AI agents but how much autonomy is safe when revenue, compliance, and trust are on the line.

The next generation of GTM leaders won't be defined by whether they came from enterprise or high-growth. They'll be defined by whether they can build infrastructure that scales both up and fast.

Agentic vs. Agentish: Why Most AI in Sales Ops Isn't What It Claims to Be

Every CRO I talk to wants AI in their GTM stack. Territory optimization. Predictive quota setting. Rep capacity modeling. Smart account assignment. But here's the problem most of them haven't solved yet: the planning infrastructure underneath doesn't support it.

At most companies, territory design lives in one system, budget allocation in another, quota setting in a spreadsheet, and attainment reporting in a fourth place. Data moves between them manually. Nobody can run a what-if scenario without rebuilding a model from scratch. And when you try to layer AI on top of that fragmentation, you get garbage recommendations that nobody trusts.

At Oracle, I built the business case and led the design for a unified GTM Platform that linked the entire planning value chain — go-to-market planning, budget allocation, territory management, quota setting, and attainment reporting — into a single system. The point wasn't just efficiency. It was making AI possible.

The first priority was connecting quota setting to real territory equity data, so quotas could be calculated at the rep level from actual coverage models, not top-down spreadsheet allocation. Then we brought budget allocation into the same platform so Sales, Finance, and Ops could review at every level of the hierarchy in real time, with over-assign governance and auditable adjustments.

The AI capabilities — territory optimization, rep capacity modeling, quota recommendations, and rep profile matching — were designed as the next layer. But none of it would have worked without the unified data foundation underneath.

AI needs clean, connected, real-time data running through a single system. Most companies try to skip straight to the AI layer without building that foundation.

The ROI case was compelling, and it came from two sources most people overlook: reducing attrition driven by bad territory and quota design, and eliminating the manual processes that slow every planning cycle. Industry research consistently shows that unattainable quotas and compensation concerns are the top reasons sellers leave. Fix the infrastructure that produces those outcomes, and the financial case builds itself.

If you're a RevOps leader evaluating where AI fits, the honest answer might be: not yet. Build the unified planning infrastructure first. Connect territory, quota, budget, and attainment into one system with one version of the truth. Then AI has something to work with.

The companies that will win with AI in GTM aren't the ones who deploy it first. They're the ones who built the infrastructure that makes it useful.

Why Your CRM Data Problem Is Actually a Revenue Problem

Most companies redesign territories once a year. They pull a spreadsheet together in Q4, argue about it for six to ten weeks, and push it live at some point in Q1 hoping nothing breaks.

At Oracle, we supported 10,000+ sellers across four regions, three lines of business, and six global business units, plus customer success and consulting. If we got territory design wrong, the downstream impact hit quota accuracy, compensation expense, coverage gaps and overlaps, and seller attrition all at once. That's not a planning miss. That's a financial event.

Here's what I learned running that process for 10+ years: territory design isn't a planning exercise. It's a financial commitment. Every territory boundary is a cost allocation decision, a quota assignment, and a compensation liability rolled into one. When companies treat it as a sales ops task instead of a cross-functional financial decision, they end up with overlaps, white space, and a comp budget that doesn't correlate to the growth plan.

Three things that changed our outcomes. First, we stopped designing territories in isolation from quota and comp. Territory, quota, and incentive compensation are one system. We built a unified planning platform that forced alignment across all three before anything went live. That single change saved millions in platform consolidation costs alone.

Second, we moved from annual to continuous territory intelligence. Static boundaries can't keep up with account movement, rep attrition, GTM strategy changes, or product launches mid-year. We embedded AI-driven account clustering and equity analytics directly into the platform so managers could see coverage issues in real time instead of finding out at the end of the quarter.

Third, we treated territory design as a governance function, not a project. A dedicated team with executive sponsorship from Sales Leadership, Operations, Finance, and Legal, standardized principles across every business unit, and a defined escalation path. That's how we got comp plan exceptions down 75%.

The companies that scale territory design well aren't the ones with better data. They're the ones that treat it as strategic infrastructure.

Ready to architect your GTM for scale?
Schedule a Conversation