---
title: "GTM Lifecycle"
type: playbook
evidence_type: method
category: "GTM Structure"
publisher: "LeanScale"
date_modified: 2026-07-27
word_count: 2694
topics: ["gtm-strategy", "revenue-operations"]
canonical_url: https://knowledge.leanscale.team/playbooks/gtm-lifecycle-playbook/
source: "LeanScale Knowledge Hub — https://knowledge.leanscale.team"
license: "Free to quote and cite with attribution to LeanScale."
---

# GTM Lifecycle

**Evidence type:** method (what we prescribe)

Every GTM Lifecycle project moves through the same four phases. Know what you produce in each one. 1 Blueprint Research their systems & company. Surface motions and regions. Map their world to our standard.

## Four phases, one motion.

Every GTM Lifecycle project moves through the same four phases. Know what you produce in each one.
1
Blueprint
Research their systems & company. Surface motions and regions. Map their world to our standard.
Output Approved stage & funnel map
2
Build
Fields, record types, flows, validation, dashboards — scaffolded to standard, deployed via a diff you approve.
Output Live config + dashboard pack
3
Enable
Docs, a podcast, and hyper-care office hours. Clone the repo into the customer's brain.
Output Enabled team + cloned repo
4
Maintain
Watch for drift, ad-hoc triggers, and gotchas. Revisit on events and on a clock.
Output Config that stays true
Start Here

## Kick off a project in one paste.

Don't dig through the GitHub repo. Copy this prompt, drop in the customer name, and send it to your Claude.
It clones the template, reads the AGENTS.md , and walks the checklist with you.
paste into Claude
Copy prompt
# GTM Lifecycle — kick off
Clone the LeanScale GTM Lifecycle template repo for my customer [Customer Name] .
Then read AGENTS.md and run the kickoff checklist:
1. Confirm access to the connected systems (Salesforce and/or HubSpot).
2. Research the customer's motions, regions, products, and current stages.
3. Draft the Blueprint — map their current world to the LeanScale standard.
4. Generate the interactive blueprint HTML for client sign-off.
Ask me anything you need before you start.
What you get

### Skills + an AGENTS.md

A README, a playbook, and configs for both Salesforce and HubSpot . The AGENTS
file gives Claude the checklist so the kickoff is a guided walkthrough, not a scavenger hunt.
1
Phase 1

## Blueprint.

Figure out how the business actually sells before you touch a
single field. Research the systems and the company, come back with their motions and regions, then map their
current world onto our standard. With systems access, current-state is very straightforward — producible.
1.1 · Motions & Regions

### What research surfaces.

You should be able to name their motions and regions from their systems + a read on what they sell.
Report on every funnel separately and combined .
PLG Product-led
Sales-led SLG
Enterprise Named / ABM
Mid-market Managed
Velocity SMB / self-serve
Also surface
Where PQLs come from and how to route them to sales, plus the nurture funnels
that catch everything that isn't ready yet.
1.2 · The Standard

### The stages & funnels we recommend.

This is the default universe. Don't over-engineer it — recommend the standard, then add or remove with them.
More often you're eliminating stages ("we don't do demos") than inventing new ones.
Lead lifecycle
Lead / Contact
Entry New Lead →
Marketing MQL →
Accepted SAL →
Qualified SQL
Decision tree @ MQL →
Disqualified
Nurture funnel
Map the nurture funnels explicitly — where records go when they're not lost, just not ready.
New Business
Opportunity · record type
1 · Demo Booked →
2 · Demo Completed →
3 · Use Case Defined →
4 · Proposal Sent →
5 · Negotiation Completed →
Closed Won
Closed Lost
Past-tense, " -ed " stage names on purpose — a stage is an event that has happened, not a to-do.
Customer lifecycle
Account object
Pre-Kickoff →
Kickoff Completed →
Onboarding →
Early Adoption →
Mature Adoption
Tracked on the account , not the opportunity — it's the state of the relationship, not a deal.
Renewal
Opportunity · record type
Open →
Renewal Review →
Proposal Sent →
Negotiation Completed →
Closed Won
Lost
A little upside on a renewal? Book the delta as expansion — e.g. a $1M renewal that closes at $1.1M sends $100k to the expansion pipeline (or use a Renewal–Expansion type).
Expansion
Opportunity · record type
Expansion Identified →
Discovery Completed →
Proposal Sent →
Negotiation Completed →
Won
Lost
Standard practice: a separate record type so you carry New Business, Renewal, and Expansion cleanly.
POC / POV / Pilot
Its own object
Still segment these 9 times out of 10 . In Salesforce , model it as a separate
object so you can roll up reporting. In HubSpot , it rides on the deal object as a module — technically not a custom
object, but it might as well be. Either way, treat a POC as a first-class, reportable thing.
1.3 · Map, Show Values, Confirm

### Old world → new world.

1
Take their current stages, map to the recommended ones
Research picks up most of it: do you run renewals? expansions? how? POC or POV? A good guess from their systems + what they sell is usually right.
2
Show them the values, not just the boxes
"If we take all your data today, here's your new open pipeline ." Seeing the new world in their own numbers is what earns the yes.
3
Backfill from wherever they track it
Not tracking POCs, renewals, or expansions cleanly? Pull the spreadsheet, or parse the order forms , and back-date with outcomes. AI makes a big folder dump fast now — One client's Excel order forms went from nightmare to uploaded quickly.
4
Confirm: add, remove, and lock the mapping
Any stages or funnels to add or remove? Then confirm the old→new mapping together. Some of this is relationship — people want to be heard . Bake that into the value.
1.4 · Timestamps & Velocity

### How we handle stage timestamps.

The method (unchanged)
Custom fields + record-triggered flows that stamp a field as a record enters and exits each stage.
That's what powers every velocity and conversion report downstream.
The backfill rule
Backfilling velocity is dicey — mostly inference on cycle time. Default: don't — "moving forward you'll have velocities."
When you must, take opportunity-created → closed-won and divide evenly across the stages (90-day cycle, 7 stages ≈ 15 days each) unless the data gives a better signal. Not perfect, but it's something in every field.
1.5 · Object Model

### Lead vs. Contact — the fork.

Default preference is contact-only . But there's one clean fork worth baking into the playbook.
If · PLG + high volume of personal emails + Salesforce
Use Leads → Contacts
The classic PLG pattern: high-volume personal signups land as Leads, convert to Contacts. Carry the key timestamps forward onto the opportunity.
Else · everything else, or HubSpot
Contact-only
Support the Lead object if there's a good reason, but default to contacts. HubSpot is easy here — it's flat, just contacts.
1.6 · Fields, Qualification & Gating

## The Blueprint, as the client sees it.

The Blueprint phase outputs an interactive HTML artifact: the client tells us how they go to market, and it lays out
their funnels, opportunity stages by pipeline, POC/POV, customer stages, the fields that thread through every stage, and
the old→new mapping. Click a stage and it surfaces the mandatory fields and associated automations. Upload it to the
client hub — that's where they engage, comment, and approve.
leanscale-gtm-lifecycle.netlify.app
Open ↗
▶
Load the live interactive blueprint
Loads the real client-facing tool inline. Or open it in a new tab ↗
Use it
This is the example blueprint output. Each engagement's version looks a little different —
feed this link to Claude as the reference for what the deliverable should be.
2
Phase 2

## Build.

This is where the repo earns its keep. The whole standard is
already scaffolded — an agent customizes it to the approved blueprint, and you approve a diff into production.
2.1 · The Config Package

### Everything you need, already in the repo.

Salesforce · ready to deploy
Global value sets for the stage pick-lists
Custom fields across Lead, Contact, Account, Opportunity
Business processes — New Business, Renewal, Expansion
Record types — one per pipeline
Record-triggered flows — lifecycle timestamps, close-won cascades, account roll-ups
Validation rules
Dashboards & reports — buildable via Claude
HubSpot · the equivalent
Same structure, built via a HubSpot private app + Claude connector
More manual today — the build gives you exact step-by-step until assets are fully packaged
Flat object model — contacts, no leads fork
Reports & dashboards done manually, or copied portal-to-portal with the Lean Stack Chrome extension (ours for life)
POC/POV rides on the deal object as a module
2.2 · The AI Build Workflow

### Agent customizes, engineer approves.

1
Agent reads the approved blueprint
Each build target (Salesforce config, HubSpot config) has its own skills — a README and a playbook — inside the repo.
2
It customizes the metadata to what the blueprint prescribed
The standard package, tailored: their stages, their fields, their record types.
3
You get a diff — standard vs. blueprint vs. package
The engineer sees exactly what's changing before anything ships.
4
Approve → deploy to sandbox or production
One click. On HubSpot, the same review, with a bit more hands-on execution for now.
2.3 · The Dashboard Pack

### Five dashboards, every build.

Marketing
Demand
MQL & MAL volume
MQL→SAL, SAL→SQL conversion
Broken out by lead source / channel / campaign
Sales
Bookings
Bookings, sales cycle, conversion — by rep
Total bookings & weighted pipeline
Pipeline coverage; bookings by territory / region
Customer
Retain & grow
Renewals & expansions by CSM or rep
Discovery: who owns renewals & expansion? (increasingly sales, not CS)
Executive roll-up
The high level
The top-line numbers, one screen
Cross-funnel health for the leadership read
Funnel analytics
The engine
Conversion rate & sales cycle
Sliced by every segment — motion, region, source
2.4 · Migration & Cutover

### The safest way to flip the switch.

The riskiest part of Build. First, discovery : map every automation that fires on each stage — the "4D model" of what
moving a record actually triggers (validation rules, alerts, integrations). Then pick your path by how embedded they are.
Simple instance · low automation
Rename in place
Little hanging off the stages? Rename them raw in production and you're done (the rename-in-place path).
Real instance · 10–15 automations/stage
Run in parallel, then hot-swap
Never just flip it. Stage the new world alongside the old until you're confident, then cut over in one move.
1
Consolidate first
15 flows on one stage? Combine into one flow (some Apex) so there's less to migrate and less to break.
2
Duplicate onto new fields, run in parallel
Stand up the new fields, timestamps, and automations running against a hidden admin page layout only LeanScale + select client admins can see. Business as usual continues; you're measuring the new world quietly.
3
Hot-swap the stage field
Once confident, swap the main stage to the new global value set — same field, whole new values — and migrate the integrations along with it. (HubSpot is more manual: you go in and edit it.)
4
Cut over Friday ~2pm
Sales team heading into the weekend, let it bake, hot-fix anything before Monday. Brief the broader team the Wednesday before .
3
Phase 3

## Enable.

Ship three things every time — documentation, a podcast, and live
office hours — and clone the repo so the whole project becomes part of the customer's brain.
📄 Documentation
Read
Stages & the universe
Mandatory fields & qualification
How data gets populated
🎧 Podcast
Listen
Every enablement gets one (ElevenLabs)
People retain audio they'd skim as text
This page's brief is the template
🎙 Office hours
Live
Hyper-care around the cutover
Answer the real questions in the room
3.1 · The Hyper-care Cadence

### One week of white-glove.

Wed · before
Pre-brief
Walk the broader sales team through what's changing before it lands.
Fri · 2pm
Cutover
Go live, then let it bake over the weekend.
Mon · after
Office hours
First live day — catch anything that surfaced.
Fri · +1 week
Office hours
Close out hyper-care. After this, you're good.
3.2 · Clone the repo into their brain
We clone this GTM Lifecycle repo for each customer . Everything we do on the engagement — the stages,
the fields, the decisions — informs their agent going forward. It goes in the repo we keep for them.
That's the compounding move: enablement isn't a one-time handoff, it's context that makes every future
project on that account faster .
3.3 · Automating the mandatory fields
Along with setting stages, you'll automate how some mandatory data gets populated. Often that spills into a
separate enrichment project — or the transcript-to-CRM agent , which fills qualification, next steps, and
more straight from call transcripts. Scope it, don't silently absorb it.
4
Phase 4

## Maintain.

A GTM system drifts. Ad-hoc changes pull it away from the design.
Your job is to watch for the triggers and the gotchas, and revisit on a schedule.
4.1 · Ad-hoc Triggers

### What to watch for.

Salespeople find the cracks
Additional validation rules — reps always find the gaps; add checks & balances
Testing & monitoring — watch for validation rules over- or under-firing (you catch most in testing)
Automation errors — health-check the flows
Config drift — for the QBR
Ad-hoc work slowly pulls the live config away from the original blueprint. Track the gap between
what was designed and what's live . That drift is the signal — after a few quarters it says
"we should probably revisit this," and it's a great QBR story.
4.3 · When to Revisit

### Event-based and time-based triggers.

Event-based
Revisit when something changes
A new sales motion is added
They add a PLG or SLG motion they didn't have
A new CRO or executive arrives with opinions on qualification
Time-based
Peek every ~6 months
Even with no event, take a look every six months to see how it's holding up. The exact cadence differs by project — some, like a growth model, are annual; others are driven by quantitative signal.
What You Hand Over

## The assets, in one place.

The team gets a landing page (this one) with the brief, a one-paste prompt, and the template repo behind it.
The client gets an interactive blueprint in their hub to approve.
For the team

### The interactive blueprint

The HTML artifact, uploaded to the client hub as a living page they comment on and approve .
The bet
GTM Lifecycle is the most repeatable project we run. With the base repo plus this playbook, a team can
start running it next week — and a clean one deploys in about half a day.
✓
Closeout

## Debrief the project.

When a GTM Lifecycle engagement wraps, spend sixteen
minutes with the debrief agent. Teamwork already knows what got built and when. This is for the
part none of our systems can see — the call that could have gone either way, the thing the customer
wanted that you refused, the near-miss that never became an incident, and above all the places
this playbook turned out to be wrong. What comes out of it gets written back into this page.

### Before you start

Two minutes of thinking beats sixteen minutes of recall. Have these in your head —
you don't need notes, and you definitely don't need a script.
Lead vs. Contact — which way you went, what drove it, and whether you'd make the same call again.
Stages, funnels and timestamps — what you actually implemented against what the playbook prescribes.
The defaults — whether five dashboards and one week of white-glove were right for this customer.
Sixteen minutes, one sitting. It's a voice conversation, so your browser will
ask for microphone access — use headphones or the agent will hear itself. Chrome is the safer bet
over Safari.

#### What this is, and isn't

It's a craft debrief , feeding straight back into this playbook.
It is not an assessment. Nothing here goes near performance review.
It's attributed — Anthony reads it with your name on it.
"This took two weeks longer than it should have because of X" is the most useful thing
you can say . Say it.

#### If it doesn't load

No mic prompt? Check the padlock in the address bar — the browser may have blocked it.
Agent talking over you? Headphones. It's hearing itself through your speakers.
Still stuck? Message Anthony rather than burning fifteen minutes on it.
The transcript takes a moment to generate after you hang up. You'll get a recap
emailed to you.

### Hand over the artifacts too

The debrief asks what you built that's worth reusing. This is where you actually hand it
over — dashboards, field maps, flows, templates, scripts, spec docs. Files land in the
project's Drive folder; links go into the artifact register so the next person can find them.
Thirty seconds, and do it while the project is still in your head.
“I'll upload it later” is exactly how assets end up trapped on an account.
Add an artifact →
LeanScale · Delivery OS
The GTM Lifecycle playbook — the internal standard for turning a customer's go-to-market into one instrumented
system across Salesforce and HubSpot. Blueprint, Build, Enable, Maintain.

## Canonical

https://knowledge.leanscale.team/playbooks/gtm-lifecycle-playbook/