Posts, videos, podcasts, articles and repos about GTM Engineering. Spam, job ads and self-promotion are filtered out, and everything is rated for how much it actually teaches.
Nishkarsh Agarwal
Founder @Sparq Labs, GTME.School · 2w ago
Your outbound isn't broken because of your tools.
It's broken because you run them in the wrong order.
Everyone's arguing about which enrichment tool to buy. Wrong fight fr.
So I put how we actually run outbound at Sparq on one sheet. One loop, eight stations. Signal, companies, people, verify, variables, send, replies, book. Then back to signal.
The line in the middle is the whole game: cheap steps before AI steps.
A few rules on there I'd tattoo on every new GTM engineer:
→ Filter on signal first. Never run tenure first.
→ Qualify the company before you pay for a single contact. Max 2 people per company.
→ Claude Code writes 2 fields per row. The email template never changes.
→ Count humans only. One audit had 131 "replies" on the dashboard. 12 were actual people 💀
→ Reply to booked call is where pipeline leaks. Not volume.
The sending math is on there too. 1 inbox × 5 a day × 26 days = 130 emails a month. Want 100k a month? That's ~770 inboxes. No magic lol.
Bottom left there's a 0–10 scorecard for the five disciplines. Screenshot it and be honest with yourself.
Comment FIELD and I'll send you the full-res sheet.
#GTMEngineering #ColdEmail #Outbound
Nishkarsh Agarwal
Founder @Sparq Labs, GTME.School · 3w ago
We cancelled our Clay subscription 30 days ago.
Nothing broke. Outbound got faster.
For 8 months we ran the stack every agency runs — Clay, Apollo.io, Instantly.ai, n8n, and a
Google Sheet nobody actually reviewed. $1,200/month. Around 10 hours a week
keeping it alive. Auth failures every Monday.
Then March happened.
Clay reset pricing: +28% cost, −40% credits, Pro tier deleted. And every HTTP call
became a billed "Action" — which meant our own custom API integrations started
burning credits just for existing.
We were paying Clay to run our own code.
So we rebuilt it in Claude Code. One terminal. One prompt. Prospeo.io → FullEnrich →
LeadMagic waterfall, straight into Instantly.
$400/month. Under 2 hours a week. Same reply rate. 3x the campaigns.
Three things I got wrong going in:
1. I thought we'd lose speed. We got faster — campaigns now launch in 20 minutes
instead of 2 days.
2. I thought the team would resist. First question was why we hadn't done it in January.
3. I thought clients would care which tools we use. Not one has asked. They care about
meetings booked.
Full breakdown in the carousel — the architecture, the exact prompt we run in
production, and an honest list of who should NOT do this.
If you're an agency still paying the Clay tax, this one's for you.
—
Comment "STACK" and I'll send you the prompt we actually run.
#GTM #Outbound #GTMEngineering #ClaudeCode #RevOps
Everett Berry
GTM Leadership at Anthropic · 2mo ago
Christian over at UserGems 💎 just ROASTED me for the data being stale in my vibe coded rep UI demo yesterday. Very fair callout Christian, let’s talk about why this happened and fix it.
Firstly, I was more just trying to show that you can hit Clay APIs from a web frontend but obviously I should validate the data - after all what kind of GTM Engineer am I to just ship things without looking at 😉
So what happened? When I asked Claude to “find contacts” I gave no additional instructions to it. So it naively hit Clay’s people search endpoint to find anyone who ever worked at Ramp and list five people.
Oops.
Happily, since Christian and others are actually looking at what I built, we can just go back into Claude Code and fix this.
In fact in my video you can see exactly that. I’m telling Claude I got called out for this and asking it to 1) narrow the title search for revops and 2) validate that we are pulling current employees.
It identifies the problem in my code right away and then sets about adding contact validation to my workflow.
While this fix took about 10 minutes Christian makes an additional more subtle point: you shouldn’t build custom tools when you can rely on one solution to give you a rep UI and all the fresh data you need.
On this point my experience is just wildly different with customers that have very poor data and very custom needs but hey it's a big market.
There we go: my unexpected DAY 5 Clay API post. DAY 4 which got me in hot water linked below.
Nico Druelle
GTM Engineering for the best AI-native companies | Founder @ The Revenue Architects · 3w ago
I screened 176 AI companies in the Bay for a GTM engineer.
The number that actually have one surprised me.
𝟰𝟱 𝘁𝗵𝗮𝘁'𝘀 𝗶𝘁, i.e 131 don't.
Few takeaways:
#1. This job category is sooo new that 90% of everyone holding the title today started in 2025 or later, and 37 of them started this year alone.
#2. GTME are lone wolves. 61% of companies with a GTM engineer have exactly one. Leads me to think that this is still experimental. Having a GTM Eng department is not the norm yet
#3. Comp Variance is still HUGE, i.e., nobody has worked out what to pay for it. The same job title is advertised at $100K and at $330K. That is a 3.3x spread on one title (granted some seniority bias)
If you're a seasoned ops professional and thinking of changing your title on LinkedIn to GTME -- the market is wide open for you.
Brian Martynowicz
Founder of Latitude | Building the AI personal content agent for LinkedIn | Sharing what we learn about content, consis… · 6w ago
I put roughly $80,000 of my own money behind one belief: the future of revenue is engineered.
One year later, here is the honest scorecard:
• ~100 current paying customers, excluding AppSumo purchasers
• ~300 accounts and 75 monthly active users
• ~$2,000 MRR
• No outside funding
This is not a victory lap. It is enough evidence to see where the GTM engineering thesis worked and where it failed.
A few things surprised me:
• The first important GTM decision wasn’t an outbound campaign. It was rebuilding our desktop product as SaaS and removing the friction between interest and value.
• Our most active customers came from LinkedIn, followed by referrals. Paid advertising brought the least active customers. That’s an activity signal, not a final verdict on paid acquisition.
• AI let a small team accomplish more, but it didn’t eliminate the work. The bottleneck moved to judgment: what requires human review and what doesn’t.
• Systems didn’t replace people. The best systems made people more effective.
I published the complete scorecard including the bets that failed and what I would do differently in the article below.
If you’re building founder-led GTM or GTM engineering, which lesson resonates most?
#GTMEngineering
I reviewed 400+ GTM Engineer applications. The best candidates weren't doing MORE.
I just spent a week inside 400+ GTM Engineer applications.
I have notes 😂
Last week, I posted ONE GTM Engineer role.
My inbox exploded.
But the candidates who stood out weren't necessarily sending:
• More applications
• More DMs
• More follow-ups
• Longer messages
• 17-minute Looms
They were making my job easier.
They:
• Made their relevance obvious
• Led with experience matching the JD
• Shared actual performance data
• Kept their message SHORT
• Had examples of what they'd built
• Followed up without stalking me across the internet
One thing I'd especially recommend?
Build a brag file.
For every important project, document:
Problem → Build → Tech → Outcome → Data
Don't just tell me:
"Built an outbound system using Clay."
Tell me:
"Built X, reduced Y by 15 hours/week and generated $1.2M pipeline."
Now we're talking.
I broke down 9 lessons from reviewing 400+ candidates in this week's newsletter.
Because your job search shouldn't be random.
Treat yourself like your first GTM campaign.
Fractional Go-To-Market Engineer | Building practical GTM systems for B2B SaaS | Outbound, CRM & AI Automation · 4w ago
9 months ago, I had zero GTM experience. I still landed my first international paid client.
Here’s how I did it
And I’m still using almost the same approach to get clients today.
1. I studied 50 GTM Engineers.
> What were they building?
> What problems were they solving?
> What were they posting about?
> I basically tried to understand what the job looked like in real life.
2. I made my own target list.
Around 50 companies I thought I realistically had a chance with, plus a few dream companies/clients I really wanted to work with.
3. I researched before I pitched.
I looked at their GTM and made hypotheses about what could be broken, manual or improved.
4. Then I built something.(Mini-Project)
A small Clay workflow, research audit, automation, Loom whatever made sense for that specific company.
So instead of saying “Hey, I'm looking for GTM work”, I had something to actually show.
5. My outreach was simple.
Short, friendly, no giant pitch. Build a connection first, make a small ask, and if they were interested then send the work and get on a call.
And..
And I never pretended to have years of experience.
I told people I was early, but I learn fast, solve problems and care about revenue.
6. At the same time, I started posting on LinkedIn.
> What I was building
> What worked
> What failed
> What I thought about GTM.
Slowly, people started knowing what I could do without me having to pitch them.
That’s still bringing me inbound opportunities today.
And after every good proj…
Advisor / Consultant (Ex Ramp, Segment, Twilio, Airbnb) · 2w ago
Thousands of partner applicants never got an email.
No welcome. No rejection. Nothing.
Every dashboard was green. The cause was one missing API parameter, the flag that says "actually send the email." No error, no alert. The system did exactly what we told it to do. The vendor gave us outdated API documentation.
I know how it happened: we were moving fast.
With AI, building takes hours instead of sprints. But QA specifically across multiple systems hasn't sped up the same way. Writing the code got faster. Checking that it actually did what we needed didn't.
Speed is a real advantage. Just verify more, not less.
What missed QA steps have bit you in the long run while moving fast?
#RevOps #GTMEngineering #AI #QA
GTM Engineering for the best AI-native companies | Founder @ The Revenue Architects · 2w ago
GTM Engineer or Growth Engineer?
I scanned 100+ job descriptions earlier this month to clear the debate
Anthropic, OpenAI, Cursor, Clay, Replit, and about 100 others.
TLDR:
A GTM Engineer builds for the reps.
A Growth Engineer builds for the customer.
-> The reps: GTM Engineer. You live in Salesforce, Clay and the warehouse, and you're measured on pipeline. Salesforce is in 58% of those specs.
-> The customer: Growth Engineer. You live in the product codebase, you ship onboarding, paywalls and experiments, and you're measured on activation. Salesforce: 3%. Experiments: 88%.
My hiring rule
1. sales-led motion, GTM Engineer.
2. self-serve product, Growth Engineer.
If your job req includes both Salesforce and a paywall, be clear about which problem this person owns first.
N
Nat Guy
Ship GTM experiences. · today
Are GTM Engineers just RevOps folks with a new title?
A made up role by a SaaS company trying to carve out a new category?
Or, on the other hand, are all our new tools giving us new capabilities... and therefore new (messy, confusing) roles, some yet to be named?
(Or both can be true, yeah? Ha.)
I took a look at what 1,667 companies wanted from these two roles.
From startups to 10,000+ employee orgs. Brex, Gong, Anthropic, OpenAi, Amazon... Most in the 50-500 range.
Not the same job.
Here's some of what I saw:
🎯 They hire GTM engineering to build pipeline: lead intel, outbound, AI workflows.
📈 They hire RevOps to run the machine: forecast, CRM, quota, programs, pricing, routing.
🎯 GTM engineering:
- Lead intelligence 60% vs 11%
- Outbound 53% vs 6%
- AI workflows 44% vs 22%
Skills: selling, campaigns, engineering.
Tools: data enrichment and workflow engines.
📈 RevOps:
- Forecasting 76% vs 26%
- CRM admin 69% vs 43%
- Coverage and quota 21% vs 1%
Skills: planning and systems.
Tools: Salesforce, spreadsheets, analytics.
The one thing they both want: automate the sales process.
(And yeah, 'GTM' here seems to really mean 'sales', not marketing, PLG and all the other ways to Go To Market... But we'll look into that later.)
Justus Santiago
GTM Engineer at Nimble | Helping AI teams replace generic search with task-specific, structured web data · 5d ago
Jev fundamentally changed how I approach finding the right ICP in an account.
It used to be deterministic title keywords. That got hard fast when prospecting into AI-native companies hiding their staff's day to day functions. "Member of Technical Staff" doesn't mean the same thing from one company to the next. Some use it for a senior engineer who basically owns a product surface. The next company describes that same person with a completely different title, or barely describes them at all. So the keyword either misses them, or it pulls in a pile of people who only sound relevant.
What I do now is pull a wide slice of everyone who might be relevant, and keep the raw material: profiles, account evidence, and the thin bits our other tools already found. Then Jev runs across that whole set.
A lot of people first think of Jev as one big yes or no. "Is this person a fit?" In my experience that question is too big. What works is breaking it into smaller, specific asks. What do they actually work on? Do they build the product? Is this a real engineering seat, or a title the company made up? Each one can score someone, and those answers are what decide how the person moves through the system.
Just know if I'm reaching out to you it's probably to talk about your search layer :)
#GTMEngineering #GTM #RevOps #GoToMarket #AIAgents #Jev #Claude
Andrew McGuire
GTM Engineering, Systems and AI | Molding human and agentic teams with Clay · 1d ago
Your GTM agent can follow every instruction and still do the wrong thing. The failure usually starts before the prompt:
Imagine it flags an account for expansion because product usage spiked.
The spike came from a test workspace. The recommendation looks credible. A rep acts on it, and now the customer has to explain why the message makes no sense.
The agent didn't invent the signal. We never told the system which usage counts.
That is the part of GTM engineering I think we underestimate. Before I write the play, I want a small contract for its data:
𝐒𝐨𝐮𝐫𝐜𝐞: Which events are eligible, and which are test or internal activity?
𝐈𝐝𝐞𝐧𝐭𝐢𝐭𝐲: Which customer and workspace do they belong to?
𝐅𝐫𝐞𝐬𝐡𝐧𝐞𝐬𝐬: How old can the event be before we stop using it?
𝐒𝐭𝐨𝐩 𝐫𝐮𝐥𝐞: If any answer is missing, does the agent hold the play or show the rep what needs review?
Then sample the recommendations every week. Save the false positives. Change the data contract when the product, accounts, or behavior changes.
You don't finish the foundation and move on to AI. Maintaining the foundation is how the agent stays useful.
What data rule did you only discover you needed after a GTM play went live?
Everett Berry
GTM Leadership at Anthropic · 2mo ago
GTM Engineers - I spent 7 days building workflows with the Clay API and MCP. Here's what I built, what worked, what didn't, and step-by-step how to videos for you to build them yourself (bookmark this!!)
Day 1 - live building a prospecting workflow from Claude Code. A simple “resequencing” workflow, described with a prompt and built inside of Clay by Claude. https://lnkd.in/gB42r_zX
Day 2 - exploring every command in the API and how to turn the Clay UI you are used to into a programmatic infrastructure layer. https://lnkd.in/gcjVvvzw
Day 3 - field marketing with codex. Enriching event leads and asking about the data without ever seeing the data or Clay’s UI. https://lnkd.in/gnn6eSea
Day 4 - vibe coding a rep UI. Got a little cooked for having some stale data in here. Also kicked off a broader debate about whether companies should build custom UIs for themselves. My take? Companies are already doing this and will continue down this path. https://lnkd.in/gwpUHxtw
Day 5 - fix my vibe coded app. I didn’t tell Claude to validate the contacts. Rookie mistake but easily fixed. https://lnkd.in/gKMjHW2m
Day 6 - revops observability dashboard for an inbound router using the Clay API. Getting metadata and reporting from our API is slept on. https://lnkd.in/gacihfxZ
Day 7 - calendar inspection for sales leadership and leader tools using Clay MCP in ChatGPT. https://lnkd.in/gADPE8Sd
My overall takeaway is that GTM Engineers are very safe in their roles. Some mistakes I made large…
Go-To-Market Engineer building outbound infrastructure for B2B growth | Ex- Soda.io’26, McKinsey NGWL’25, HPAIR’25 · 8w ago
Don’t automate personalization. Automate the research that creates it.
Most outbound teams want “personalized” messaging.
So they automate AI-written first lines.
That’s backwards.
The expensive part isn’t writing the sentence.
It’s figuring out what’s actually worth saying.
You can automate a huge part of that research.
Take a list of 500 target companies.
Instead of manually researching each one, build a workflow that pulls signals like:
→ New job openings
→ Hiring volume by department
→ Recent funding
→ Product launches
→ Headcount changes
→ New market expansion
→ Tech stack changes
→ Recent company announcements
Then classify those signals.
For example:
- Signal: Company is hiring 5 SDRs + 1 RevOps manager.
- Detected change: They’re building a more structured sales function.
- Potential implication: Their sales processes, CRM and reporting requirements are likely getting more complex.
- Relevant buyer: VP Sales / RevOps.
- Outbound hypothesis: They may be evaluating or rebuilding their GTM infrastructure.
Now you have something worth personalizing around.
And the workflow can do this across hundreds of accounts.
The important distinction is the system doesn’t decide what the company “needs.”
It finds evidence.
It turns that evidence into a hypothesis.
A human decides whether the hypothesis is actually worth acting on.
That’s where GTM Engineering gets interesting.
Not: “AI wrote 500 personalized emails.”
But: I built a system that continuously finds…
