Guide / GTM Engineering

How to build a GTM system, step by step

This is the framework we use when we sit down with a new client and design their GTM system. It is not original in spirit, but it is honest in detail. Seven steps, in order, with a realistic 90-day rollout at the end. Nothing here requires a 12-person team. It requires sequence and patience.

Step 1: GTM thesis and ICP

Before you touch any tool, write down the thesis in one paragraph. Who are you selling to, what are they hiring you for, why now, and what is the simplest motion that could possibly work. If you cannot fit it in a paragraph, the system you build will be confused, because the brief is confused.

The ICP, the ideal customer profile, falls out of the thesis. We define it on three axes: firmographic (industry, size, geography), technographic (what they run today), and behavioural (what they have done recently that suggests they are in a buying window). The behavioural axis is the one most teams skip and the one that does most of the work.

A small story. I closed an earlier startup years ago because I could not sell the product, which is the polite way of saying the thesis was wrong and I had no idea. That experience is the reason this step is first. Every workflow downstream multiplies whatever signal or noise lives in the thesis.

Step 2: TAM extraction and segmentation

Once the ICP is written down, extract the full addressable market. Not a sample, the whole thing. For most B2B segments we end up with a few thousand to a few tens of thousands of accounts. Manageable.

Then segment. The most useful split is rarely industry. It is usually a combination of size band, buying readiness, and a behavioural axis like "currently hiring for the problem we solve". Three or four segments is plenty. Each segment will get its own message and often its own workflow.

• Tier A. Best-fit accounts. Manual research, longer sequences, named ownership.
• Tier B. Strong fit, no urgency yet. Automated enrichment, nurture, wait for signals.
• Tier C. Edge of ICP. Light touch, only when a high-quality signal fires.

Step 3: wire buying signals as triggers

Pick two or three signals that genuinely predict intent in your market. Not ten. Two or three, then add more once the first ones produce.

For a SaaS selling test automation tooling, the signals might be: a new QA leader, public engineering job posts mentioning the relevant stack, or competitor reviews appearing on G2. For a software house, it might be a fresh series A in a target vertical, a CTO change, or a public RFP. The pattern is the same: the signal is the reason the message is timely.

Each signal becomes a trigger in the system. Trigger fires, enrichment runs, message gets drafted, workflow starts. The signal is the thing that makes the message land. Without it, you are still doing volume outbound, just with prettier tools. The four signals we lean on most are hiring, funding rounds, tech stack changes and job changes at executive level. Pick two to start, wire them in, then add more once the first two produce.

Step 4: persona mapping and messaging

Inside every target account there are at least three people who matter. We split them into three buckets and write to each one differently.

• Power Users. The people who would use the product day to day. They care about pain, workflow and time saved. Specific, concrete, full of nouns.
• Champions. Senior individual contributors and team leads who push the buying decision internally. They care about credibility, peer adoption and risk. Stories from similar companies land here.
• Decision Makers. Budget holders. They care about outcomes, payback period and political safety. Short, sharp, framed in their language.

You do not always contact all three. For some products the Power User is the buyer. For others the Decision Maker is the only door. Mapping forces a real answer instead of "we send to whoever Apollo returns".

Step 5: workflow design across channels

A workflow is the actual automation that takes a triggered account from "interesting" to "in a real conversation". We draw every workflow on a whiteboard before we open a tool. The drawing fits on one page or the workflow is too complicated.

A simple workflow looks like this. Trigger fires. Agent runs research, produces a brief. Agent drafts a first email and a LinkedIn note in the assigned voice. Human reviews and approves a batch in a few minutes. Email goes Tuesday, LinkedIn connect on Thursday. Two follow-ups, spaced. Reply classifier triages incoming. Positive and objection go to a human inbox the same hour. Everything else updates the CRM and goes back to nurture.

Most teams overdesign their first workflow. Build the simplest version that could possibly produce a meeting, ship it, then add branches when reality demands them.

Step 6: the human layer and QA

Agents do the drafting. Humans do the strategy, the judgment and the real conversations. That sounds obvious until you watch a team try to remove the human entirely and then quietly add them back two months later.

We keep humans in three places on every workflow. First, a quick approval step on the first-touch batch, mostly to catch the AI doing something embarrassing. Second, every positive or objection reply, immediately. Third, a weekly review of a sample of sent messages, to keep the style honest.

On the QA side, two non-negotiables. Spam-trigger and link checks before any batch ships. A red-team pass on the first version of every new sequence: read it as a hostile recipient and ask, would I unsubscribe? If yes, fix it before launch.

Step 7: measurement and weekly iteration

Measure per workflow, not per channel. "Our email reply rate is 4 percent" is a useless number. "The funding-trigger workflow into Tier A produced a few meetings a week at a sane cost, and the hiring-trigger workflow into Tier B is flatlining" is a useful one.

Three numbers we look at every week: positive reply rate, meeting rate, pipeline created. Plus one qualitative read: pull three actual replies and read them with the team. Numbers lie often, replies almost never.

Iteration rule: kill any workflow that has not produced a meeting in three weeks, unless we can name a specific upcoming change that would fix it. Scale any workflow that has produced for three weeks in a row. Test one new angle a week. Never test more than two things at once, or you will not be able to read the results.

A realistic 90-day rollout

If you start today, this is what the first quarter usually looks like for a small team adopting this approach.

• Weeks 1 to 2. Thesis, ICP, TAM extracted, three segments defined. Stack assembled or audited. Domains warming. No outbound yet.
• Weeks 3 to 4. First two signals wired up. First workflow drawn on the whiteboard, built end to end, agents prompted, style guide written. First batch sent to Tier A only.
• Weeks 5 to 8. Replies coming in. Style guide rewritten based on what humans actually responded to. Second workflow added. Tier B switched on. Weekly review cadence established.
• Weeks 9 to 12. Two or three workflows running steadily. First few meetings on the calendar with real intent. Reporting per workflow stable. Decisions about what to kill and what to scale start being routine.

You will not have a polished engine in 90 days. You will have a working loop, a real read on which signals matter, and enough conversations to start compounding. That is the realistic finish line for a single quarter, and it is more than enough to justify the next one.

If you want the role view of who runs this, see what a GTM engineer actually does. If you want the inventory of tools that sit underneath, the stack guide is the companion piece.