GTM engineer rollout on Clay

Built from the system Michael Saruggia, Clay advisor and GTM engineer at Clay Operator, described on GTM Vault GTM 21 (https://pro.gtmvault.co/episodes/gtm-21). Published free by GTM Vault. The episode is an interview, not a live build; the steps below turn his stated method into a runnable plan, and your results will differ.

When to use this

Use this when a company has sales reps who start the day without lists, signals or warm conversations, has inbound or marketing activity that does not convert into MQLs because records are incomplete, and is deciding whether to hire more reps or add a GTM engineer. Michael says it fits companies past a certain level of revenue, because a small startup often has no assets to work from (GTM 21, 15:41). He works mainly with scaleups at 50 million in revenue or more, sometimes 100 million (GTM 21, 13:44), and his advice to companies at 30 million or 50 million and above is to make the hire (GTM 21, 19:13).

The system on the record

Michael defines the GTM engineer as the person who combines AI go to market tools to augment the workforce, so the company produces more with less; the end goal is more revenue per employee, and it applies to every function (GTM 21, 1:11). He sees the role as the evolution of RevOps: RevOps people are good with systems and data but often do not speak the copy or revenue language of sales, while the GTM engineer writes copy, tests what generates pipeline and works one on one with sales people (GTM 21, 8:01 and 9:10). The method he described runs in five parts:

1. Rank use cases and prove value in order. In a larger company he first assesses the highest ROI use cases that can affect the organization fastest, puts them on a timeline, starts with the first one and shows leadership real values and KPIs (GTM 21, 5:36 and 6:48). Which use case comes first depends on the company, and he says this takes business knowledge, RevOps expertise and the ability to speak the language of decision makers (GTM 21, 6:48). He starts from a set of 12 playbooks he keeps in a doc and adapts them, because problems inside each organization are specific (GTM 21, 13:44). As the machine transcript renders the list, it includes inbound, lead outbound, TAM mapping, newsletter outbound, social signals, PLG and free signups, recruitment and HR, CRM, conferences, new hires, promotions and open jobs, and past champions (GTM 21, 13:44 and 14:52). Some playbook names are phonetic in the transcript.
2. Start from existing assets, not cold outbound. The first mistake he names is not starting with the assets a company already has. If there is inbound, web traffic or a network of partners, he connects those digital assets so they generate open conversations and give reps lists of semi-warm people, which turns cold outbound into warm outbound (GTM 21, 14:52 and 15:41).
3. Fix the data before the marketing motion. Without the right data infrastructure, a marketing led motion fails (GTM 21, 15:41). His example: marketing activity on the website produces records with only an email, the lead scoring model cannot qualify them because data is missing, and asking for more fields on the form adds friction and reduces activity. In Clay, from a B2B email he gets the LinkedIn profile, from the profile he gets company and personal information such as job title, and the enriched records can become MQLs and then be turned into SQLs by the system (GTM 21, 16:48).
4. Design proprietary signals. He treats vendor signals as generic, standardized across industries and often inaccurate. Real intent comes from domain knowledge, combining the company's own data, proprietary data or a niche database (GTM 21, 18:01). His example: for a client selling point of sale systems to restaurants, the team tracked Google News for restaurant openings, turned each one into a company name, a domain, people and a decision maker, and reached out about the new opening. He notes there is no prebuilt button for this in Clay, Common Room or 6sense; it starts from brainstorming how the industry works and working backwards (GTM 21, 18:01).
5. Deliver the rep's morning. The output is a rep who wakes up to prioritized open opportunities instead of guesswork (GTM 21, 12:33). His examples of what lands in front of the rep: five leads who changed jobs and are past champions, with phone numbers and an instruction to call now; an intent signal such as a company launching three new products, with the decision makers and the messaging to use; replies from a cold email campaign to answer; and open inbound conversations, with the email and LinkedIn already connected so the rep can reach inbound leads at high speed to lead (GTM 21, 12:33). He measures everything starting from the number of conversations per day, which he calls the core problem in most teams (GTM 21, 13:44).

He warns against complexity. Many technical operators build something because it is technical rather than because it moves results, and the goals are pipeline, KPIs, cost saved and revenue (GTM 21, 9:10 and 10:26). He also sees a gap between mostly junior GTM engineers and senior CROs who cannot speak to each other, and says growth comes from their collaboration (GTM 21, 10:26 and 11:21).

The result

Michael gave no measured results from a client engagement in this episode. What he stated:

1. Headcount: instead of five SDRs or five AEs, a company can hire two or three and add a GTM engineer, so that two reps produce twice. He framed this as making existing reps more efficient, not automating their jobs, and as an illustration rather than a measured client result (GTM 21, 11:21 and 12:33).
2. KPIs he expects the system to move: number of conversations per day, meetings, conversions and revenue (GTM 21, 13:44), and more pipeline, more MQLs, more MQL to SQL conversion and more revenue per seller (GTM 21, 14:52).
3. His own early result: working alone at an Italian startup, he says he produced more than the rest of the sales team combined. He gave no figure (GTM 21, 3:11).
4. Tool consolidation: he says Clay can unify tools that are duplicated inside a company and lower cost. He gave no figure (GTM 21, 2:21).

Run it on your company

1. Ask once, in one message, for: annual revenue and headcount by GTM function; the number of SDRs and AEs and their quota attainment; what each rep starts the day with today (lists, signals, open conversations); inbound volume and how many inbound records become MQLs and SQLs; the fields captured on inbound forms; web traffic, partner network, product signups, newsletter and conference lists available; the CRM and whether it holds closed won and past champion contacts; current intent or signal vendors; the industry and how a buyer's need shows up in the world; and who the GTM engineer will report to.
2. Score the playbooks. Take Michael's list (inbound, lead outbound, TAM mapping, newsletter outbound, social signals, PLG and free signups, recruitment and HR, CRM, conferences, new hires, promotions and open jobs, past champions) and score each against the company's assets and the KPI it would move. Output: a table with columns Playbook, Asset it uses, Asset exists (yes or no), KPI moved, Expected time to first result, ROI rank. Michael gave no scoring weights on the record; leave weights for the user to confirm.
3. Set the timeline. Order the ranked playbooks, starting with ones that use existing assets before any cold outbound. Output: a timeline table with columns Order, Playbook, Owner, Start, KPI, Baseline, Target, plus a one paragraph note on the first playbook written in the language a CRO would use.
4. Build the inbound enrichment flow. Output: a field map with columns Input (email), Step (email to LinkedIn profile, profile to person fields, profile to company fields), Field, Lead scoring input (yes or no), and the MQL and SQL rules that use those fields, so no new fields are added to the form.
5. Design one proprietary signal. Work backwards from how a buyer's need appears in the industry, as in the restaurant openings example. Output: a signal spec with columns Signal, Source, How it is detected, Steps to company name, domain, people and decision maker, Message angle, plus a check that confirms no vendor already sells the same signal.
6. Define the rep's morning list. Output: a table with columns Bucket (past champions who changed jobs, intent signal accounts, cold email replies, open inbound conversations), Data supplied (phone, decision maker, message), Action, Delivery channel, Refresh time, plus one sample morning list for one rep.
7. Set the scorecard: conversations per rep per day, meetings, MQLs, MQL to SQL conversion, pipeline and revenue per seller, each with a baseline taken before the first playbook ships, reviewed with leadership on a fixed cadence.

Tools on the record

1. Clay: core of the GTM engineer stack.

Any tool doing the same job works; the method is the point. Full stack by layer: https://pro.gtmvault.co/stack/operator/michael-saruggia

Where it breaks

1. Starting with cold outbound. Michael says cold outbound is working less, and teams that skip their inbound, web traffic and partner assets miss the semi-warm lists those assets produce (GTM 21, 15:41).
2. Too small to have assets. A small startup may have nothing to connect, which is why he says the approach works better after a certain level of revenue (GTM 21, 15:41).
3. Missing data infrastructure. Without enriched records, the lead scoring model cannot qualify inbound and the marketing motion fails (GTM 21, 15:41 and 16:48).
4. Overengineering. Builders who like complexity ship technical systems that do not move pipeline, cost or revenue (GTM 21, 10:26).
5. A GTM engineer who cannot talk to the CRO. Most GTM engineers are junior, and when they cannot speak the language of senior revenue leaders the collaboration that drives growth does not happen (GTM 21, 10:26 and 11:21).
6. Relying on bought intent. Vendor signals are generic and often inaccurate; without domain knowledge there is no real intent to act on (GTM 21, 18:01).
7. No proof to leadership. If the first use case is not tied to real values and KPIs shown to leadership, the rollout loses its mandate (GTM 21, 6:48).