The Five Phases of a GTM Infrastructure Build

Most GTM engagements have no shape. The work is described as “we’ll figure it out as we go” or “we’ll start with the most painful thing.” Six weeks in, nobody can describe what got built or what comes next. The retainer keeps renewing. The system stays half-built. The client is paying for motion, not for a finished thing.

A GTM infrastructure build has a fixed shape. Five phases, in a fixed order, with a fixed exit point. The phases are named because naming them makes them measurable. The order is fixed because each phase produces something the next phase needs. The exit point is fixed because the work is supposed to end.

The framework is five phases: Diagnose, Architect, Build, Activate, Transfer. Eight weeks from kickoff to handoff.

This post explains what each phase is, what it produces, why the order matters, and where most engagements stop too early.

What are the five phases of a GTM infrastructure build?

The five phases are Diagnose, Architect, Build, Activate, Transfer. Each runs in sequence. Each has a clear deliverable. Each ends before the next begins.

Phase	Question it answers	Output
Diagnose	Where is your GTM actually breaking down?	Written audit + prioritized action plan
Architect	What should the revenue system look like?	Approved blueprint, signed off before build
Build	Make it real.	Working revenue system on foundations you own
Activate	What happens after the lead enters the CRM?	Lifecycle, attribution, expansion, retention running
Transfer	You keep the keys.	Documentation, handoff, optional ongoing support

The phases are deliberate. They aren’t a marketing rebrand of “discovery, implementation, training.” Each phase is its own block of work with its own artifacts and its own success criteria.

Why these five phases, in this order?

Three reasons.

The first is dependency. You can’t architect what you haven’t diagnosed. You can’t build what you haven’t architected. You can’t activate what isn’t built. You can’t transfer what isn’t activated. Each phase produces the input the next phase needs.

The second is risk placement. Disagreements are cheapest in the Architect phase. Once Build starts, every disagreement becomes a rebuild. So the order frontloads decisions and protects the build phase from re-litigating scope.

The third is exit shape. Most engagements have no Transfer phase because the engagement model doesn’t allow one. Retainer-based work has no incentive to end. The five-phase framework forces an exit point at week eight. The work is done when the keys are handed over.

Design before build. Build before activate. Transfer last. The order isn’t arbitrary.

What happens in each phase?

Diagnose. Weeks 1 and 2. The work is reconnaissance, not consulting. I map your current GTM end-to-end: tools, data flows, qualification logic, lifecycle gaps, attribution model, what works, what doesn’t. Stakeholder interviews across sales, marketing, ops, and leadership. Three to four hours of working sessions across two weeks. The deliverable is a written audit with a prioritized action plan. Most clients are surprised by what surfaces, not because the problems are new, but because no one mapped them in one document before.

Architect. Weeks 2 and 3. Design the target system. Data model, signal sources, qualification rules, lifecycle automation logic, attribution architecture, integration map. You approve the blueprint before a single integration is written. This is where disagreements get aired and resolved while they’re still cheap. The output is a signed-off architecture document that becomes the contract for Build.

Build. Weeks 3 through 6. The work happens. Signal detection wired in. Enrichment pipeline running. Qualification logic deployed. CRM schema rebuilt where it needs to be rebuilt. Outreach automation connected. Dashboards live. The phase produces a working revenue system on foundations you own. Daily build notes go to a shared doc. Weekly demo at the end of each build week.

Activate. Weeks 6 through 8. The piece most engagements skip. Lifecycle automation goes live. Deal progression rules fire. Sentiment and engagement signals feed back into your CRM. Expansion triggers and retention monitoring start running. Attribution rolls up nightly. The system stops being a pipeline and starts being a revenue engine. This is the phase that earns the “infrastructure” label.

Transfer. Week 8. Documentation, team training, maintenance playbooks. Live walkthrough with whoever owns the system after I leave. Optional post-engagement support for teams that want help as the system evolves. The standing offer: if you never call me again, that’s the success state.

What artifacts does each phase produce?

Every phase has a written deliverable. No phase ends on a verbal handoff.

Phase	Artifacts
Diagnose	Written audit document, prioritized action plan, current-state architecture map
Architect	Target-state architecture diagram, data model spec, integration map, signed-off blueprint
Build	Working integrations in your environment, build notes, demo recordings, weekly status
Activate	Lifecycle automation specs, attribution model documentation, dashboard library, live demo
Transfer	Maintenance playbook, team training session recording, owner runbook, escalation contacts

The point of the artifact list isn’t bureaucracy. It’s so the team that inherits the system after week 8 can read the docs and understand what was decided. Three months later, when someone asks why qualification logic was set the way it was, the answer lives in a document, not in someone’s memory.

How long does the full build take?

Eight weeks. Two for Diagnose. One for Architect (overlapping with the back half of Diagnose). Four for Build. Two for Activate (overlapping with the back half of Build). One for Transfer.

The overlap is deliberate. Architect starts in week 2 because the diagnostic findings are coming together by then and decisions can begin. Activate starts in week 6 because lifecycle automation depends on the data layer that gets built in weeks 3 to 5, but the Activate work itself is its own track and doesn’t wait for every Build deliverable.

If timeline is tight, the work compresses. The diagnostic can run in one week instead of two. Architect can collapse into the back end of Diagnose. The shortest end-to-end build I’ve run is five weeks. Below five weeks, the Diagnose phase isn’t doing real work, and the rest of the build inherits whatever assumptions you walked in with.

If timeline is loose, the work doesn’t expand. Eight weeks is the cap. A longer engagement isn’t a better engagement, it’s a more expensive one with the same deliverable. The framework is designed to be done.

What does the framework not include?

Three things, intentionally.

It doesn’t include strategy consulting. The work assumes you know what you sell, who you sell to, and what your sales motion looks like. If those are open questions, the framework doesn’t fix them. Strategy work needs a different shape and a different operator.

It doesn’t include ongoing operations. The system is yours after week 8. Day-to-day operation, prospect outreach, deal pursuit, customer success management. All of that lives with your team. The infrastructure runs without me. The work that uses the infrastructure is your team’s work.

It doesn’t include tooling decisions you can’t reverse. The blueprint leans on your existing CRM, your existing sequencing tool, your existing data warehouse. If those foundations are wrong, the diagnostic will say so. But the Build phase isn’t a tool migration. Tool replacement is a separate engagement.

How is this different from other GTM frameworks?

Most GTM frameworks fall into one of two shapes.

The first is the consulting shape: discovery, recommendations, presentation, handoff. The output is a slide deck. No code gets written. The client owns the implementation, which usually means it doesn’t happen.

The second is the retainer-model shape: take over your stack, run it as a managed service, bill monthly. The output is execution but the infrastructure lives in their environment. The retainer can’t end without the system ending with it.

The five-phase framework is a third shape: build infrastructure, transfer ownership, leave. The output is a working system that runs without me, in your environment, on your accounts. The artifact list exists so handoff is real, not theatrical. The exit point exists so the work is finite.

If you’ve worked with a fractional RevOps lead or a GTM consultant before and you remember the feeling of “what did we actually get for that,” the difference is the artifact list and the exit point. Both are in the contract.

What comes next in this series?

This post is the framework anchor. The companion posts go deeper into specific phases.

The first is on the role itself: what a GTM Infrastructure Architect is, how it differs from a GTM Engineer, and why this role exists now. The framework above is what an architect actually does.

The next goes inside Activate, the phase most engagements skip. Post-pipeline revenue optimization, lifecycle automation, expansion triggers, attribution that the board can read. Activate is the differentiator. The post explains why, and what it produces.

If the framework fits your situation, the next step is a Diagnose conversation. Thirty minutes. No pitch. You describe what you have. I tell you what I see. From there, either there’s a fit or there isn’t.

See the five-phase framework on the site · Book a Diagnose call