Clay partnered with Maven on the Clay by Maven Growth Series, a set of Lightning Lessons for the next generation of GTM engineers. I was one of the instructors. My lesson, "Map the GTM system from spend to revenue," covered what GTM engineering is and how to build it across the whole revenue motion.

GTM engineering is the discipline that connects the dollar you spend to the dollar you earn. This post is the written version of my lesson: the definition, the four stages every GTM system runs on, and one deal followed from first touch to expansion.

At the end, you'll have a way to draw your own GTM map and find where it leaks.

Watch the full session: Map the GTM system from spend to revenue on YouTube

The deal nobody could explain

For most of my career, I believed GTM was sales. GTM was the part where you go get new clients. That isn't wrong. It just isn't the whole thing.

At Spotify, I ran sales strategy and the deal desk for ad sales, working with media agencies and some of the world's largest advertisers. We launched a new programmatic ad product. It was a big launch and a new revenue line.

Marketing built the buzz with events, content, and newsletters. Sales pitched it to new accounts. Account managers brought it to every existing client. Three departments, one product, one target, all at the same time.

It worked. Deals closed. But we didn't know what closed them. For every deal, the CRM recorded one thing: the account executive.

As a sales leader, I hadn't cared. My number was my number. From the deal desk, I could see it was one motion, end to end, and nobody had drawn it. That is GTM: one process, run by departments that each see their own piece. Almost nobody sits in the seat that sees the whole thing.

Today, that seat can be a system.

What is GTM engineering?

Go-to-market used to be a department. Now it's the name for the whole path to revenue. The definition Partner UP is built on: GTM is everything from the dollar you spend to the dollar you earn.

• Marketing generates demand.

• Business development generates leads.

• Sales generates revenue.

• RevOps makes it measurable.

• Post-sale keeps it and grows it.

Every company cuts that into departments differently. Underneath, there is one motion: demand, leads, revenue, renewals.

Before AI, each department had its own tools and its own dashboard. Someone pulled numbers from each and reconciled them in a spreadsheet, after the fact, for a handful of top accounts. Nobody could see the whole motion across the whole book.

GTM engineering is the discipline that connects the dollar you spend to the dollar you earn, so the map is drawn as the data flows instead of after. It is not a department. It's the layer that sits inside each function and connects them.

You'll hear many titles for this work: GTM engineer, GTM systems engineer, RevOps engineer. What matters is where the work touches the funnel. Split the roles if you want. Never split the system. [link: GTM engineer roles: why one person can't do all four jobs]

The SERA framework: four stages of every GTM system

Every GTM system, in every motion, runs through the same four stages: source, enrich, reason, act. I call it SERA.

[embed: node/f5fc8f33-72f5]

1. Source. Where the data comes from: third-party, first-party, CRM, forms, lists, product signups, events.

2. Enrich and orchestrate. Fill the gaps, structure the data, refresh it, and decide what flows where.

3. Reason. An LLM scores, infers, categorizes, and drafts. This layer didn't exist two years ago. It's why the map can be drawn now.

4. Act. Push the result to the sequencer, the CRM, Slack, the calendar, Notion, or a slide deck, ready for the person who needs it.

SERA is a loop. Every action creates new data: a reply, a meeting, a signed contract. That becomes the next source.

In practice, we connect sources into Clay, then use Clay plus Claude Code to enrich, refresh, and structure the data before any AI reasons over it. Check the data and the foundations first, then act. [link: Clay services page]

The GTM engineering map: four motions, four stages

Put the four motions down the side and the four SERA stages across the top. That grid is your GTM map. The rows are motions, not departments, because every company splits departments differently.

To make it concrete, take an imaginary company. Acme is an AI accounting and tax compliance platform. It sells to finance teams at multi-entity companies, so the buyer is a Controller or CFO, and the deal touches tax, finance systems, and IT.

We'll follow one deal: Cobalt, a manufacturer with four legal entities. Acme is large on purpose, so every row shows. If you're earlier stage, start with the rows you have.

Demand: one row per human

Marketing usually owns this row. Its job is to become known to the ICP. It's the only row where you spend on more than headcount: ads, content, partnerships, events, webinars.

At Cobalt, the Controller watched an Acme webinar and clicked two ads. An accountant at one of their subsidiaries ran the free nexus check on Acme's website. That's a hand-raise.

The unlock most companies miss: merge every touch into one table, one row per human, not one list per channel. Merged, you see the same Controller across the events list, the webinar list, the ads list, and the form list.

With one row per human, an AI agent sorts everyone into three buckets: potential client, someone learning the space, potential partner. The Controller and the accountant are potential clients, so Cobalt goes to sales. The NetSuite consultant who ran the same nexus check is a partner, not a prospect.

Where it leaks: marketing and sales disagree on the ICP, and every touch downstream inherits the disagreement.

The fix: one shared ICP definition, owned jointly and enforced by the categorization layer.

Leads: research that writes back

This row belongs to sales and business development, and it's personal. Reps are paid on results, so every motion has to show up in a rep's number. If it doesn't, they won't use it.

Cobalt arrives from marketing. Then a signal fires: Cobalt acquires a company in a new state. New entity, new nexus. The problem Acme solves just got bigger. That's the reason to reach out this week. [link: signal-based prospecting with Clay]

Next, map the buying committee: the Controller who owns the close, the Head of Tax who owns nexus, the CFO who signs, and the finance systems lead.

At the Reason stage, the system researches Cobalt, drafts a first message with the acquisition as the reason to reach out, and places it in the sequencer. A Slack message gives the SDR the script, why they're calling, and who else is in the org. Once a meeting is booked, the AE gets the why-now, discovery questions, and a deck built for Cobalt. For Cobalt, the rep edits the draft. For lower tiers, drafts are approved up front and run on their own.

Where it leaks: someone researches Cobalt in a chat window, finds the acquisition, and it never reaches the CRM. Next quarter, someone starts from scratch.

The fix: every research run writes back to the account record, so the next person starts where the last one stopped.

Revenue: one definition per stage

RevOps usually owns this row. It answers one question every week: what are we going to close, and how sure are we? [link: RevOps service page]

This row pulls from everything the other rows produce: CRM stages, calls, meetings, email, billing, and the history of every deal Acme has won and lost.

Two things get cleaned up first. One set of stage definitions, so a stage means the same thing to every team. And account hierarchy, which turns Cobalt's four legal entities into one account with one buying committee.

Now the system can reason over it. Based on past wins, it notices the CFO hasn't joined a meeting yet and flags the gap. The forecast review starts with the deals where the rep's call and the evidence disagree. The AE still makes the call. The system brings the evidence.

Where it leaks: "qualified" means one thing to sales and another to RevOps.

The fix: one definition per stage, checked by the system. You'll see it in forecast accuracy.

Renewals: route product signals to the account owner

This is post-sale: customer success and account management. It's where I see the least built and the most opportunity. From the sales side, I watched account managers and CS teams build their own systems on top of the job they already had. I think that's where the next GTM engineers will come from.

The AE brought the CFO in, and Cobalt closed. Now the question is whether the account grows.

Here the data starts in the product: entities connected, integrations syncing, filings completed. Add tickets, contract dates, and who the champion is. Then match product accounts to CRM accounts, so usage shows up where the account team works.

Six months in, Cobalt connects the company it acquired. A fifth entity, filing in a new state. Their exposure grew, so the contract should grow with it. The CSM gets an alert with the reason attached and decides if it's real. Expansion goes to the AE, and renewals feed the same forecast as the revenue row.

Where it leaks: usage lives in the product, and the account team works in the CRM.

The fix: route every product signal to the account owner. You'll see it in net revenue retention, expansion pipeline, and churn caught early.

Close the loop: renewals feed the ICP

Each row is owned by a department. GTM engineers build the system that connects them.

The back half of the motion feeds the front half. Renewal and expansion data flow back into the ICP and the scoring. Cobalt tells marketing who to find next: manufacturers that grow by acquisition. That loop turns four workflows into one system that learns.

Three rules for AI in GTM engineering

1. AI runs in every stage, but it decides in only one: Reason. That's where it scores, researches, and drafts. Everywhere else, it works inside rules a human set.

2. Ask agents for fields, not paragraphs. A decision, a reason, a draft. A paragraph needs someone to read it. Fields can be checked in seconds.

3. A human approves before anything acts. Where that approval sits depends on the account tier.

The approval isn't the part you automate last. It's the design.

Draw your own GTM map this week

The template from the session has six sections. Make a copy and fill it in for your company. [link: GTM map template]

1. Inputs: where your money and hours go in.

2. The map: for each cell, write what runs there today. Mark it M for manual, S for system, or leave it blank.

3. The leak audit: where each row breaks.

4. Where AI belongs: which cells need a Reason step.

5. The revenue side: for each system you'd build, the signal you'll see in weeks and the revenue it leads to in a quarter. If you can't draw that line, don't build it yet.

6. One fix. Only one.

If a box stays empty, that's a finding, not a failure. The empty cells show you where to build next.

Want a second pair of eyes? Send your map to hello@partneruphq.com.

The map is the system. The foundation underneath it is a separate lesson. My colleague Alex Bueno taught it in the same series: Build the GTM Foundation for Scaling With AI. [link: Alex Bueno's Maven session recording]

Frequently asked questions

What is GTM engineering?

GTM engineering is the discipline that connects the dollar a company spends to the dollar it earns. It builds the system that links marketing, sales, RevOps, and post-sale into one motion, so you can see what drives revenue across every account, not only the top ten. GTM engineering is not a department. It's a layer inside each function that sources data, enriches it, reasons over it with AI, and pushes actions to the people who need them.

What does a GTM engineer do?

A GTM engineer builds and maintains the system behind go-to-market. That includes connecting data sources, enriching and structuring account and contact data, setting up AI steps that score, research, and draft, and routing the output to the CRM, sequencer, or Slack. The department owns the motion. The GTM engineer builds the system it runs on.

What is the SERA framework?

SERA stands for source, enrich, reason, act. It's the four-stage pattern every GTM system runs on. Source is where data comes from. Enrich fills gaps and structures it. Reason is where an LLM scores, infers, categorizes, or drafts. Act pushes the result to the right tool or person. It's a loop: every action creates new data that becomes the next source.

How is GTM engineering different from RevOps?

RevOps owns one row of the GTM map: revenue. It makes the pipeline measurable and runs the forecast. GTM engineering spans all four rows, demand, leads, revenue, and renewals, and builds the system that connects them. In many companies, RevOps teams do GTM engineering work. The difference is scope: one motion versus the whole path from spend to revenue.

Where should a company start with GTM engineering?

Start by drawing your map. List your four motions, mark each SERA stage as manual, system, or empty, and find where each row leaks. Then pick one fix that ties to a signal you'll see in weeks and revenue you'll see in a quarter. Earlier-stage companies won't have every row yet. Start with the rows you have.