Playbook · GTM Lifecycle

The GTM Lifecycle playbook.

Everything an architect or engineer needs to run one of these projects end-to-end — Blueprint → Build → Enable → Maintain. Start with the five-minute audio brief, then copy the prompt and open the repo.

4Phases
~½ dayBlank repo → deployed
1Standard
SF + HSBoth platforms
Watch or listen first · 5 min

The audio brief.

One narrator, five minutes, the whole shape of the project — now with the deck that runs alongside it. Play it before you open anything else; it's the fastest way to get into the right mindset for a GTM Lifecycle build. In a hurry? Change the speed under the deck — it sticks next time.

0:00 / 0:00
Speed
1 / 1
Chapter 1 Narrated brief · generated with ElevenLabs · Download ↓
Chapters
The whole idea

Take a company's messy, half-defined go-to-market and turn it into one instrumented system. Blueprint → Build → Enable → Maintain — the standard we deliver to, every time.

The Shape

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.
OutputApproved stage & funnel map
2
Build
Fields, record types, flows, validation, dashboards — scaffolded to standard, deployed via a diff you approve.
OutputLive config + dashboard pack
3
Enable
Docs, a podcast, and hyper-care office hours. Clone the repo into the customer's brain.
OutputEnabled team + cloned repo
4
Maintain
Watch for drift, ad-hoc triggers, and gotchas. Revisit on events and on a clock.
OutputConfig 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 
# 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

A customer-specific repo

The clone becomes part of the customer's brain — every skill, standard, and decision from this project informs their agent going forward.

Inside it

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.

PLGProduct-led
Sales-ledSLG
EnterpriseNamed / ABM
Mid-marketManaged
VelocitySMB / 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
EntryNew Lead→ MarketingMQL→ AcceptedSAL→ QualifiedSQL
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 — Chain Guard'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 fields that thread through every stage.

Detect their methodology from research (MEDDPICC, BANT, …). See nothing? Recommend MEDDPICC and pre-fill what it would likely look like for their product and company.

Bucket 01

Qualification

The methodology fields (MEDDPICC / BANT). Backfill is genuinely hard — and mostly people only care on renewals (champion, etc.).

Bucket 02

Firmographic

Company-level attributes for segmentation and routing.

Bucket 03

Technographic

Their stack signals — what they run, what they've bought.

Bucket 04

Velocity timestamps

The date fields from §1.4 that make every funnel measurable.

The Deliverable

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 ↗

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 Clio path).
Real instance · 10–15 automations/stage (a Mistral)
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 kicks off ad-hoc work.

Trigger

A new motion

New- or existing-business side — a new way of selling needs its own funnel and fields.

Trigger

New stage-movement automation

A new alert to fire, a new artifact to create, a new thing to happen when a record moves.

Trigger

A methodology or process change

Changes to qualification, onboarding, or the expansion motion.

Trigger

A new product line

Potentially new pipelines, packaging, and reporting cuts.

Trigger

An object-model change

Moving to a contact-only model, or standing up leads where there were none.

Trigger

Renaming stages

The big one — changing stage names or the stage set itself ripples everywhere.

4.2 · Gotchas & Health Checks

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

This landing page + brief

The playbook overview and the 5-minute audio brief — the front door for anyone running the project.

For the team

The one-paste prompt

Clone-for-customer → AGENTS.md drives the checklist. Claude rips the repo and starts the walkthrough.

In the repo

Skills, configs, context

Per-platform build skills (SF + HubSpot), READMEs, playbooks, gotchas, and the common ad-hoc work — internal enablement for our team and our agents.

For the client

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.

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 →