GTM Lifecycle

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

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

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

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

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

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

• 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

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

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 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

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

• 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

• 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

• 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 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

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

• 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

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

• 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
• 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 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 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

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.

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.

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.

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.

• 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.