GTM operations · revenue operating system
What’s
working?
I find where a revenue engine is breaking — pipeline, operating system, and team — then stand up the GTM system so demand gen can run strategy. AI is how we speed that up once the system is sound.
A senior GTM operator who owns the revenue operating system — RevOps, demand systems, and AI enablement — as one function.
Two questions, one stack
Point of view
Marketing works. Its proof
is what’s broken.
Most demand isn’t manufactured. It gets shaped long before anyone fills in a form — a podcast eighteen months ago, a peer who vouched for you in a Slack group, a reputation built over years of showing up. That is marketing. It’s the most powerful marketing there is. It’s also invisible to a model built around last-touch source fields.
So the model undercounts the work that matters most and overcounts whatever happened to be measurable. Then someone carries that model into a budget meeting, and the wrong line gets cut.
I’m not here to prove marketing works. I’m here to stop the measurement from arguing that it doesn’t.
One side has a schema.
The other doesn’t.
The moment an opportunity is created, your data gets disciplined. Required fields. Stage gates. Close dates. One system, one record, one shared key everything else can join to.
Everything that produced that opportunity gets no such treatment — outbound activity, events, referrals, warm intros, advisor and partner motions, website conversion. Each recorded in whichever tool it happened to run in, under whatever that tool calls things, with no key connecting it to the opportunity it created.
Before an opportunity exists
Ad platforms, email tool, event registrations, call and meeting logs, spreadsheets, someone’s inbox. Governed by nothing. No shared key.
After an opportunity exists
The CRM. Required fields, stage gates, validation rules. The opportunity record ties it all together.
This is structural, not a reflection of your team. No CRM enforces a schema on work that happens before its records exist — so the second answer gets assembled by hand, differently each quarter, by whoever is building the deck. It survives one meeting and then has to be rebuilt.
Until recently, fixing that was a data-engineering project — a warehouse, a modeling layer, a team, two quarters. The cost of connecting scattered activity data to CRM outcomes has collapsed over the past year. It’s now a scoped build on top of the CRM you already run — named in a diagnostic, built in weeks, and owned by your team afterward.
How I think about proof
Three kinds of claim
Not everything can be measured the same way, and pretending otherwise is where credibility goes to die. Three layers, three different standards of proof — and being explicit about which is which is most of the job.
Most measurement fails by applying one standard of proof to all three — either the same false confidence everywhere, or a shrug at anything that resists a clean number. The discipline is knowing which claim you’re entitled to make, and refusing the ones you aren’t.
How the diagnostic works
Find where the engine
is breaking
Every engagement starts here. Two to four weeks, four steps, and a plan you can act on.
Questions leadership actually asks
Board, QBR, planning — and an honest verdict on which ones your reporting can defend today.
Where the engine is breaking
Pipeline (sources, conversion, velocity), operating system (CRM, data, workflows, routing, attribution, reporting), and team (roles, handoffs).
AI as a layer, not the product
Where AI speeds a sound system vs. where it would automate a mess. Guardrails and ownership included.
Prioritized plan
What to fix first, what to build, what to retain ownership of, and what to hand to an engineer.
You get findings you can act on whether or not we work together again. If we continue, the diagnostic fee covers month 1 of a multi-month retainer.
Evidence
What this looks like when it lands
Reconciliation produces a defect ledger — every number that didn’t tie, why, and what it cost. These are the failure types it catches. Each one produced confident, plausible output. None raised an error.
Full ledger with figures available under NDA.
Written context
The part that outlives
the engagement
Every company I’ve worked in has the same problem underneath the reporting one: the decisions live in people’s heads. Why “sourced” means what it means. Which field is the real one. What was tried in 2024 and quietly abandoned. When someone leaves, it goes with them.
So every engagement writes that context down — in a form your people and your AI tools can both work from. Not a wiki nobody opens. A living record of what your team decided and why, kept current as a by-product of doing the work.
Definitions
What each metric means, and which field it actually comes from.
Decisions
What was chosen, when, and why the alternative was rejected.
Methods
How each recurring analysis is really run, step by step.
Gotchas
What breaks silently, and how you’d know it had.
Why this matters more than it used to. Most GTM teams have adopted AI and gotten inconsistent answers out of it. That’s usually not the tool. It’s that every prompt starts from nothing, so every answer quietly reinvents the definitions — and two people asking the same question get two different numbers, both confidently wrong.
Your AI is only as good as the context you can hand it. Most companies have never written that context down anywhere.
Qualification
Who this is for
Good fit when
- The revenue engine is hard to see, or it has stalled — and leadership keeps asking “what’s working?” without a defensible answer
- Pipeline looks trustworthy once an opportunity exists; the mess is everything before that, or the operating system connecting motions to outcomes
- Marketing and sales are measured as one motion, or you’re trying to get there
- You want one senior owner across RevOps, demand systems, and AI enablement — not another tool vendor or a campaign executor
- You’d rather own the system afterward than rent a black box forever
Not a fit when
- You need campaigns run — I don’t execute demand gen (I partner with people who do)
- You need day-to-day marketing-ops hands for lists and workflow tickets
- You have no CRM discipline yet — fix that first; this layer sits on top of it
- You want a dashboard rather than an agreement about what the numbers mean
- You need custom software or a context engine built from scratch — I specify and verify; an engineer owns that build
Working together
How engagements usually run
Step one · paid front door
GTM / Revenue Diagnostic
Find where the revenue engine is breaking: pipeline, operating system, and team — with AI as a layer inside the diagnostic, not the name of the work. You leave with prioritized findings and a clear next-step plan (sprint, retainer, or both).
If we continue into a multi-month retainer, this fee is used in place of month-1 spend.
Step two · standalone build
Implementation sprint
Nobody buys this off a menu first — the diagnostic names the first build, the duration, and the price. The published number is a floor. Example builds: attribution and reporting, routing and demand systems, Clay or AI workflow stand-up.
Retainer — if you want ongoing ownership.
Tiers by what I own, not by hours. Published minimum: 3 months.
Review & direct
Advisory
I review and direct; your team executes. Monthly roadmap, office hours, QA. I do not own a pipeline number.
Own named workstreams
Operator
I own one or two named workstreams end to end (examples: attribution and reporting; or Clay, routing, and demand systems).
Own the function
Embedded
I own the revenue operating system as a function — RevOps, demand systems, and AI enablement.
Start with a conversation
Bring the three questions your leadership asks most about pipeline — and whether anyone else in the company computes the answers a different way.