GTM is still very much human, and I will fight anyone who says otherwise. Manually.

The machinery is not the work

I think weΓÇÖve become very methodical about GTM engineering. ThereΓÇÖs a workflow for everything, a playbook for every channel, and apparently an AI agent for every task that previously required you to have a thought.

Some of that is useful. IΓÇÖm a GTM engineer. I like building things, connecting systems, and figuring out how to make a process work at scale.

WeΓÇÖre confusing the machinery of go-to-market with the actual work of understanding why somebody would buy something.

The engineering should be methodical. The problem is when we start treating the person on the other end as another component in the workflow. Get enough signals, connect enough platforms, generate the right sentence, and apparently a customer comes out the other side.

I donΓÇÖt think it works like that. And the longer I do this, the more convinced I am that the part weΓÇÖre trying hardest to automate away is often the part that makes everything else work.

Before the workflow, what is the offer?

For me, this starts with three things: who youΓÇÖre selling to, what youΓÇÖre selling them, and what makes your offer worth choosing.

What are you actually offering this person? What problem are you taking off their plate? Why should they choose you over their existing solution, another provider, or doing absolutely nothing?

Once youΓÇÖre clear on those things, you have a much better foundation for almost any sensible outreach approach.

Channel choice and deliverability still matter. The channel just needs to be carrying an argument that already makes sense. YouΓÇÖre not asking the infrastructure to manufacture a reason for someone to care.

Then we can talk about email infrastructure, LinkedIn, lead sourcing, intent, CRM routing, attribution, and all the other things that make a GTM engineer useful.

But before we get there, I want to know what weΓÇÖre putting into the machine.

Because ΓÇ£we havenΓÇÖt quite figured out why people buy this, but weΓÇÖd like to send it to 50,000 of themΓÇ¥ is not a particularly reassuring starting point.

The best example I have is almost embarrassingly simple

We recently started working with a client in the medical hiring space.

Their audience was straightforward: people posting medical-related jobs, particularly roles that are difficult to fill. Their offer was straightforward too: help those employers fill the roles more effectively than their usual route through platforms like Indeed.

They knew the market and they knew the problem.

Now, you could absolutely take that brief and turn it into a substantial engineering project. Layer in multiple hiring signals. Enrich the company through three providers. Score the account. Find another signal to validate the first signal. Start looking for the mysterious ΓÇ£alphaΓÇ¥ hiding somewhere inside the 100 prospects with a 99-point intent score.

But this clientΓÇÖs request was much simpler. Find the people posting the relevant jobs and reach out to them by email.

The copy was supremely simple too. The message essentially came down to: youΓÇÖre hiring for this kind of role, and we can help you fill it.

That was the pitch.

There wasnΓÇÖt an AI-written paragraph about how inspiring their companyΓÇÖs mission was. There wasnΓÇÖt an elaborate attempt to establish a connection through something the prospect posted six months ago. The relevance was already there.

They had a job to fill. This person could help fill it.

For that very specific audience, it has produced the highest reply rate IΓÇÖve personally seen in a campaign. And it has kept working.

The part I keep coming back to is that this client has essentially been running a version of the same campaign for 15 years. We didnΓÇÖt arrive and discover a completely new reason for people to buy from him. We helped him scale something he already understood.

And honestly, I think thereΓÇÖs a lot for GTM engineers to learn from that.

Simple does not mean someone hasnΓÇÖt thought about it

Some of the clients I find easiest to work with are the ones who have been selling their product for a decade, or who have significantly more domain expertise than I do.

They tend to know what works for them. They have strong principles. They understand the objections, the buying process, and the difference between someone who sounds interested and someone who actually needs what they sell.

And their messaging is often very simple.

I donΓÇÖt think that simplicity is accidental. ItΓÇÖs the result of reducing the pitch to the things that matter, because theyΓÇÖve had enough conversations to know what those things are.

In the medical hiring example, the job posting already gave us a relevant reason to reach out. We could have collected another 20 data points, but what decision would they have changed?

Would they have changed who we contacted, or what we offered?

Sometimes the answer is yes, and the enrichment is worth doing. But sometimes weΓÇÖre just adding detail because we know how to add detail.

When I look at four platforms connected to each other, three separate enrichment engines, multiple email finders, and MCPs and CLIs running all over the place, I want to ask a fairly basic question:

Is this helping us reach the right person with a better offer, or are we making ourselves feel better about an offer that still isnΓÇÖt particularly compelling?

The tooling is fine. The question is whether you know why youΓÇÖre using it.

Can you get a reply before you build the machine?

This is something more founders should think about.

If you picked 50 relevant people and wrote the emails yourself, could you get anyone interested? You, explaining to another person why you think you can help them.

Fifty emails are not a definitive test of product-market fit. A weak response could mean youΓÇÖve picked the wrong audience, misunderstood the problem, chosen the wrong channel, or simply explained yourself badly.

But those are exactly the things IΓÇÖd want to investigate before building a system to repeat the same approach at scale.

Read the replies. Have the conversations. Find out what people misunderstand, what they dismiss, and what gets their attention. Give yourself a chance to discover that the pitch you love is not the pitch your customer cares about.

Use AI to challenge your thinking, help with research, or clean up a draft. There is nothing noble about doing unnecessary manual work.

DonΓÇÖt expect it to resolve the commercial uncertainty for you.

You havenΓÇÖt worked out the audience. YouΓÇÖre not sure the offer is right. You donΓÇÖt really know why the last campaign failed. But this time, the copy will be AI-generated, so presumably weΓÇÖre all good.

I donΓÇÖt buy that.

I want the automation to be informed by something weΓÇÖve learned from actual people, not just by our confidence that the next prompt will finally sort everything out.

Your agency also needs permission to question the premise

ThereΓÇÖs another side to this, and I think GTM engineers and agencies need to be honest about it.

A founder struggling with outbound does not automatically mean an agency canΓÇÖt help. Of course we can help. We can bring a different perspective, identify a better audience, challenge the positioning, improve the offer, and run better experiments.

But we need permission to do those things.

If the audience, the offer, the messaging, and the productΓÇÖs limitations are all off limits, then what exactly are we being asked to solve?

Sometimes the expectation is that everything commercial stays exactly as it is, but the GTM engineer introduces enough technology to produce a completely different outcome.

ThatΓÇÖs a difficult engagement to sign up for.

A client who is confident because they understand their market and a client who is inflexible because they donΓÇÖt want their assumptions challenged can look similar in a kickoff call.

The experienced client with the simple offer can explain why it works. The rigid client may just insist that it should.

ΓÇ£Your offer is badΓÇ¥ cannot become the agencyΓÇÖs convenient explanation for poor targeting, weak execution, or bad infrastructure. We still have to do our jobs.

But we should agree on what the problem is, what weΓÇÖre allowed to test, and who owns which decisions. Otherwise, you can end up taking responsibility for a commercial outcome without having any influence over the commercial assumptions behind it.

The engineering matters. So does knowing when to stop engineering.

I still want good infrastructure. I want reliable lead sourcing, sensible qualification, clean CRM records, and attribution that helps us understand what is happening.

I want us to use AI where it makes the work better. I want us to automate repetitive tasks. Nobody needs to paste emails into a spreadsheet by hand.

But every extra layer should earn its place.

Before adding another signal or another tool, I want to know what decision it will change. Before scaling a campaign, I want to know what evidence we have that it deserves more volume.

And I want us to measure more than activity. Replies are useful, but the point is to create relevant conversations, qualified opportunities, and ultimately business. A complicated workflow is not an outcome in its own right.

Sometimes our most valuable contribution is a sophisticated system that makes something previously impractical possible.

Sometimes itΓÇÖs recognizing that the client already has a good offer and getting it in front of more of the right people without unnecessarily rewriting the whole thing.

I think both are legitimate GTM engineering. The second one just makes for a less exciting workflow screenshot.

Until Skynet gets here, IΓÇÖm backing the humans

The way I see it, GTM is still very much a human process.

Someone has to understand the problem and decide what is worth offering. They have to recognize when the market is pushing back, and take responsibility for whether the business can actually deliver what the message promises.

ThatΓÇÖs the part I donΓÇÖt want us to lose while weΓÇÖre busy connecting everything.

ItΓÇÖs also the kind of work I want to do at Apero: understand the business, figure out where we can help, and build the systems that support that. Sometimes that means more technology. Sometimes it means asking a question nobody particularly wants to answer.

So absolutely, think about your tooling and your infrastructure. Figure out how to scale.

But first, make sure you have something worth saying to someone who has a reason to care.

Until Skynet takes us all, IΓÇÖm putting my money on the human who understands the customer over the workflow that merely knows how to contact them.

And the offer in the title stands. You do have to show up yourself, though. Your AI agent cannot attend on your behalf.