What is GTM engineering?

GTM engineering is building the data, workflows and tools a go-to-market team runs on. It answers three questions with systems instead of guesswork: who to target, why now and what to say. Instead of buying a list and sending one message to everyone, GTM engineering uses public data, enrichment and AI to find prospects with a specific problem and build the message around it.

Why GTM engineering exists

The old approach is to define an ICP, build personas, buy a list and hand a message to an SDR. Jordan Crawford's view is that this breaks at the message, because the message is about the seller, not the situation the buyer is in.

AI didn't fix it. It's been more than three years since ChatGPT, and the Blueprint homepage notes that 95% of outbound gets zero engagement. AI made every team faster, but most teams spent that speed sending the same product pitch to more people.

Jordan describes three eras of go-to-market:

1. The SDR era. Hire more reps, buy a list from ZoomInfo and start dialing.
2. The workflow era. A specialist runs Clay, enrichment APIs and multi-step workflows. Targeting improves, but one person and one tool become a single point of failure.
3. The current era. Teams can work with every internal and external data point about their customers and prospects. The teams that win know what to ask the AI to build.

How GTM engineering works

The core idea is to work backwards from the expected output. For outbound, that means:

1. Start from why your best customers actually bought, in their own words, from calls, the CRM and your team.
2. Find the external data that would have shown that problem: government records, permits, regulatory filings, competitor signals.
3. Build a list of companies in the same situation. Blueprint calls this a Pain-Qualified Segment (PQS).
4. Let the data write the message. Blueprint calls this a Permissionless Value Prop (PVP), a message specific enough that the data is the value.

See how PQS and PVP work together for the full method.

A simple example

The Blueprint homepage compares two messages to a healthcare organization. The generic one says managing compliance across facilities is hard and offers a platform to stay audit-ready. The engineered one says seven providers at the prospect's Pacific Northwest facilities have lapsed PECOS enrollment, so any Medicare claims they bill are being denied, and it attaches the list.

The second message only exists because someone worked out which public data would show the problem, then built the list from it.

Beyond outbound

The same inversion works for churn analysis, customer health scoring and call analysis. Start from the outcome, such as an account you saved or a deal you won, then find the data that predicts it. Jordan does this work in Claude Code, across campaigns, churn analysis, customer health scoring and call transcripts.

If you're comparing roles, see what a GTM engineer does and GTM engineering vs RevOps.

Jordan's point of view

Jordan's position is that the tools are now solved. Picking what to build and working backwards from outcomes is most of the work, and the remaining question is whether your team can execute.

He also argues for shipping often. AI gets things wrong, but your team finds out within minutes of sending. You fix it and ship again, and each campaign makes the next one sharper. The goal is for your team to learn the method so the capability stays after any advisor leaves.

• Leading a revenue team? See fractional GTM engineering advisory.
• Building the systems yourself? See On the Edge for GTM engineers, or read how to become a GTM engineer.
• Want to see the output? Browse real playbooks in the Blueprint Showcase.