GTM Engineer @GrowthKinetics | Building revenue engines with AI and automation · 2w ago
I think GTM Engineers are going to have to care less about how much they build.
How many Clay tables?
How many workflows?
How many automations?
How many agents?
Honestly, none of that matters much if pipeline isn't moving.
I've seen some GTM Engineer roles starting to call this out too.
The focus is more on pipeline, demos, conversion...
not how many automations you shipped.
And I actually like that.
Because it's really easy to build something and think:
“Damn, this is a cool workflow.”
But then you have to ask:
Did it actually help sales?
Did reps save time?
Did conversion improve?
Did we create more pipeline?
That's the part that matters to me.
I think GTM Engineering is going to be less about how much you build and more about what changed because you built it.
Because basically...
you can build the coolest GTM system in the world.
Someone still has to buy.
Thoughts?
Viraj Parmar
GTM Engineer @GrowthKinetics | Building revenue engines with AI and automation · 3w ago
I think GTM Engineering is getting interesting.
I've been seeing more roles lately where the job isn't just:
- build a Clay workflow
- connect some APIs
- automate outbound
It's more like:
- go into the company
- figure out how their GTM actually works
- find what's broken and build the system around it.
I like this way more.
Because every company has its own way of doing GTM.
The stack is different.
The data is messy.
The process isn't always documented.
And there are always things that don't fit into some nice template.
You can't really solve all of that with a template.
And that's probably why I think GTM Engineering is moving closer to actual software engineering.
You're not just connecting tools.
You're figuring out what needs to exist...
and then building it.
Maybe that's what GTM Engineering becomes.
Not knowing every tool.
Just being really good at figuring out what should be built.
Curious how other GTM Engineers see this?
Viraj Parmar
GTM Engineer @GrowthKinetics | Building revenue engines with AI and automation · 3d ago
Saw an interesting debate recently.
Will GTM Engineering still exist in a few years, or will AI make it redundant?
Honestly, I think part of the job will disappear.
If your entire skillset is building Clay tables, connecting APIs, and generating personalized emails, that's going to get easier.
But here's where it gets interesting.
Imagine a SaaS company wants to identify customers ready for an enterprise plan.
Product usage lives in one system.
Account data lives in HubSpot.
Support conversations live somewhere else.
Sales needs to know which accounts to approach, when to reach out, and what to say.
Someone has to connect all of this.
They need to decide which signals matter, what triggers an action, and how to measure whether it worked.
I read a GTM Engineering breakdown recently where the author said 90% of their AI work was traditional workflows.
Only 10% involved more agentic use cases.
That stuck with me.Were spending a lot of time talking about agents.
Meanwhile, most of the work still involves getting the data, logic, and actions to work together.
I think knowing the tools will become less valuable on its own.
Understanding the GTM process well enough to build the right system is where I'd focus.
Thoughts?
Viraj Parmar
GTM Engineer @GrowthKinetics | Building revenue engines with AI and automation · 2w ago
I think a lot of people are building GTM agents too early.
They open Claude.
Connect a few tools.
Give it a prompt.
And start automating.
But I think there's a step missing.
Watch your best rep first.
See how they actually research an account.
What they notice?
What they ignore?
What makes them interested in an account?
What makes them change their mind?
How they decide who is worth reaching out to?
A lot of that never makes it into Salesforce.
It's just years of experience sitting in their head.
And honestly, that's probably the most valuable part to capture.
Because if you automate a bad process, you just get a faster bad process.
But if you can turn the way your best people think into a system...
now you're building something useful.
That's what I find really interesting about GTM Engineering.
Don't start with the agent.
Start with understanding what your best rep already knows.
I mean...
why build another agent before understanding how your best people actually work?
Viraj Parmar
GTM Engineer @GrowthKinetics | Building revenue engines with AI and automation · 11d ago
I think GTM teams are sitting on a data source they barely use.
Sales calls.
Most teams use them to get a transcript and a summary.
But there’s a lot more you can do with that data.
For example:
Gong → transcript → AI → CRM → GTM action
A prospect says on a call:
“We are probably replacing our current tool in the next 3 months”
The system picks that up.
It writes:
Buying signal: Evaluating alternatives
Timing: ~3 months
Next best action: follow up within 3 days
back to the CRM.
Then the workflow does a few things automatically:
→ creates a follow-up task for the AE
→ pulls the relevant case study into the next email
→ sends the AE a Slack alert with the exact quote
→ finds other accounts mentioning the same problem
Now that one sentence from a sales call has become a GTM signal.
Thats what I find interesting about GTM Engineering.
Not just summarizing what happened.
Turning conversations into actions the rest of the GTM system can take.
The workflow becomes:
call → signal → action
Thoughts?
Viraj Parmar
GTM Engineer @GrowthKinetics | Building revenue engines with AI and automation · 2w ago
I think we’re going to see more companies build a “GTM Brain.”
Not another AI SDR.
Not another agent that sends emails.
Something that actually understands how the GTM team thinks.
Because right now, the information is everywhere.
CRM has account history.
Clay has enrichment. Intent tools have signals.
Call recordings have conversations.
LinkedIn has hiring and job changes.
But the hard part is connecting all of this.
For example:
A company just raised money.
Cool.
They also hired a new VP Sales.
Okay.
Now they're hiring 15 AEs.
Interesting.
And they are entering a market where your product solves a known problem.
Now you have a reason to look deeper.
That reasoning is what most GTM systems are missing.
Your best rep does this automatically.
They have seen hundreds of accounts.
They know which signals matter.
They know which ones are noise.
They know when to dig deeper.
They know when to walk away.
A GTM Brain should capture that.
Then your agents can use it to research accounts, find prospects, prioritize leads, write emails, update CRM...Basically, the agents do the work.
The GTM Brain decides whats worth doing.
I think thats a much more interesting direction for GTM Engineering.
Not more automation. Better decision-making.
Thoughts?
Viraj Parmar
GTM Engineer @GrowthKinetics | Building revenue engines with AI and automation · 3w ago
I think GTM Engineers have been building decision engines without realizing it.
I’ve done this a lot.
Take a bunch of accounts.
Enrich them.
Pull funding, hiring, tech, intent, website activity, LinkedIn stuff.
Then start adding logic:
if this → keep
if this + this → prioritize
if this → skip
if score > X → send to outbound
Pretty quickly, your Clay table becomes a giant decision tree.
That’s why TypeSafe AI (Jev) caught my attention.
It’s not another model trying to write the next email.
It’s built to make structured decisions inside software, with probabilities and confidence attached.
And that feels really relevant to GTM.
Because maybe instead of hardcoding every little rule...
we can start giving the system the context and let it make some of those decisions.
Clay still gets the data.
The CRM still holds the state.
The automation still executes.
But the decision layer gets smarter.
I think that's a pretty interesting direction for GTM Engineering.
We’ve spent years figuring out how to connect tools.
Now we might be figuring out how to connect decisions.
What do you think?
Viraj Parmar
GTM Engineer @GrowthKinetics | Building revenue engines with AI and automation · 3w ago
I think there's a simple GTM Engineering rule
I'm starting to like...
Don't use AI for things a formula can do.
I'm seeing people put AI into almost every step of a workflow.
But sometimes you really don't need it.
If I need to check whether a company has more than 500 employees, that's a formula.
If I need to check whether the title contains “VP Sales,” that's a formula too.
Simple rule. Simple answer.
And yes, AI can help you build that formula.
But you don't need to call AI every time the workflow runs.
Use AI to build the logic. Don’t necessarily use AI to execute the logic.
Then you get into things like:
Does this company actually look like a good fit for us?
Does this person look like someone who would care about what we sell?
Is there enough context here to actually reach out?
Now a formula starts getting pretty messy.
That's where AI makes more sense.
And this is why I find Jev interesting.
It's built for these small decisions inside a workflow... things like classification, scoring and routing without using a big language model just to get a simple decision.
So the workflow can be more like:
rules for the obvious stuff → Jev for the fuzzy stuff → LLM when you actually need language
I think this is going to become an important part of GTM Engineering.
Not “use AI everywhere.”
Just: use the right kind of intelligence for each step.
That's probably a much better way to build these systems.
Curious how others are thinking about this?
Viraj Parmar
GTM Engineer @GrowthKinetics | Building revenue engines with AI and automation · 2w ago
AI without actions is still just a copilot.
A lot of sales AI today can:
- research the account
- write the email
- suggest the next step
Cool.
But then a human still has to go into 5 different tools and do it.
Thats the part I think is changing. I was looking at what Saleshandy has been building with MCP + CLI.
With MCP, you can actually ask an AI to work with Saleshandy:
“Which sequences are underperforming?”
“Move these prospects into the nurture sequence.”
“Which sender accounts have deliverability issues?”
The AI isnt just giving you an answer. It can take the supported action inside the workspace.
And with the CLI, a GTM engineer can script things like prospect imports, sequence management and analytics instead of doing everything through the UI.
Thats what I find interesting.
The value of AI in GTM isnt just better recommendations. Its being able to go from:
signal → decision → action without a human becoming the API between every tool.
Thats where I think GTM Engineers will spend more time.
Not building more dashboards.
Building systems where the tools can actually do something when the logic says they should.
What part of your GTM stack still needs you to click “do it”?
