---
title: "Growth Model"
type: playbook
evidence_type: method
category: "GTM Structure"
publisher: "LeanScale"
date_modified: 2026-07-28
word_count: 3666
topics: ["forecasting", "gtm-strategy"]
canonical_url: https://knowledge.leanscale.team/playbooks/growth-model-playbook/
source: "LeanScale Knowledge Hub — https://knowledge.leanscale.team"
license: "Free to quote and cite with attribution to LeanScale."
---

# Growth Model

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

Most playbooks are heaviest in Build. This one is heaviest in Blueprint — by a mile. Plan your time accordingly. 1 Blueprint Mine their systems for every metric, then get the room to agree on what each one means.

## Four phases, one very lopsided motion.

Most playbooks are heaviest in Build. This one is heaviest in Blueprint — by a mile. Plan your time accordingly.
1
Blueprint
Mine their systems for every metric, then get the room to agree on what each one means.
Output Signed-off assumptions
2
Build
Top-down targets, bottom-up capacity, then reconcile the two until they meet.
Output A staffable plan
3
Enable
Walk it function by function; leave it live, not as a spreadsheet attachment.
Output Performance-to-plan
4
Maintain
Measure monthly, reforecast quarterly, rebuild on events.
Output A plan that stays true
Start Here

## Kick off a project in one paste.

Copy this prompt, drop in the customer name, and send it to your Claude. It stands up the model app
pre-loaded with their data and gives you the research pack to walk into the first meeting with.
paste into Claude Copy prompt
# Growth Model — kick off
Clone the LeanScale Growth Model template repo for my customer [Customer Name]
and stand up their copy of the growth model app (new Netlify site, new Blob store,
and turn the passphrase gate back on — REQUIRE_PASS in model.mjs).
Then run the research pass before I talk to anyone. For every input the model
needs, go find THEIR number in THEIR systems — Vasco first, then Salesforce or
HubSpot directly:
- ARR by segment today, and average ACV by segment
- Annual gross churn and expansion, by segment
- MQL→SQL and SQL→Win, by segment, new logo AND expansion separately
- Sales cycle: median days SQL-created → closed-won, by segment
- Rep ramp: hire date → first month at steady-state close rate
- Attainment: trailing 12 months, ramped reps only
- Seasonality: bookings by fiscal quarter, 3-year average
- Channel-sourced pipeline, trailing 4 quarters
Where they don't track something, infer it and say how (e.g. first meaningful
activity as an SQL-date proxy). Where you can't infer it, drop in an industry
benchmark for their ACV band and segment. Tag every single number actual /
inferred / benchmark, and write the derivation into the Assumptions tab.
Then give me: the pre-populated model, the assumption log, and a one-page list of
the questions I need to ask in the exec kickoff to close the benchmark gaps.
1
Phase 1

## Blueprint.

This is the phase. Eighty percent of the project
lives here, and almost none of it is modelling. It is research, then one-on-ones, then a room full of
executives arriving at a shared definition of about eighty numbers. Do this well and Build is an afternoon.
Do it badly and you will present a beautiful model that the CRO quietly disowns.
1.1 · Before you talk to anyone

## Send the agents in first.

Never walk into the first meeting with a blank template. It is far easier for an executive to poke holes in
a number you brought than to stare at an empty cell and be asked to fill it in — and you will learn more
from what they argue with than from what they volunteer.
1
Take the actual
Wherever they genuinely track it, pull their own number. Vasco first if the diagnostic is in place, otherwise straight into Salesforce or HubSpot . Segment it — a blended conversion rate is a number about nothing.
2
Infer what they don't track
This is the layer we could never do at scale before. No S.Q.L. date field? Use first meaningful activity as the proxy and measure to closed-won. Nobody knows the real ramp? Take hire date → first closed deal across every rep who ever ramped, and take the median.
3
Benchmark only as the last resort
If it cannot be observed and cannot be inferred, drop in a benchmark for their ACV band, their segment, their motion — not a generic SaaS average. Then flag it as a question, not as an answer.
4
Tag every number with how you got it
Actual, inferred, or benchmark — on every single input, visible in the model. This is what turns "trust me" into "here is the query." It is also how you show the room, honestly, how much of their own plan is currently guesswork.
So what
The research pack is a deliverable in its own right.
Even if the growth model went no further, a company that has never measured its own ramp time, expansion
rate or true sales cycle now has all three — and knows which ones it still cannot see.
1.2 · The room

## One-on-ones first. Always.

This is the most consultative project we run, and the order you talk to people in matters more than the
agenda. Do not let the executive kickoff be the first time anyone hears their own numbers read back to them.
First
The CRO, one-on-one
The person who wants to control this narrative most. Get close early. Ask directly what their number is, where it came from, and what they think it will actually take.
Then
Each function lead
Marketing, customer success, sales dev, RevOps. Same questions, their metrics. You are listening for where two leaders use the same word to mean different things.
Then
Executive kickoff
Founder or CEO, CFO, CRO, CMO, whoever runs sales, marketing and customers, plus RevOps. Frame the goal, present the research, land the recommendations.
After
Working sessions
One per function to build the capacity plan, usually two or three rounds. They work it, you meet as a group, they rework it.
Say this in the kickoff
"The goal is a detailed operating model and operating plan that gets you to your top-down goals."
"If you plan to double, we make sure there is enough capacity in sales, marketing and CS to actually do it."
"We are going to argue about inputs . Nobody looks at an output until the inputs are agreed."
"Where you don't track something, we inferred it. Here is exactly how — tell us where we're wrong ."
What you're really listening for
Two leaders using "conversion rate" to mean different things (MQL→won vs SQL→won).
A segment definition nobody can state out loud.
"Ramp is two weeks" — they mean onboarding , not productivity.
A CRO who does not yet know their target. That is fine. Unaligned is the problem, undecided is not.
1.3 · The window

## Three years. Two at the absolute minimum.

Recommended
Three-year plan
Long enough that this year's hiring and pipeline investments show up as next year's revenue, short enough to still be a plan rather than a story. Beyond three years is fiction.
Never
One-year plan
A one-year plan can only extrapolate investments you have already made. With a six-month sales cycle, most of next year is decided by what you fund this year — and a one-year window makes that invisible.
1.4 · Segmentation

## Segment everything, or the model means nothing.

Every segment has different funnel metrics, different roles, different people and different economics.
Blending them produces an average that describes no part of the business.
A typical segmentation
Each one gets its own funnel, its own team, its own targets
Highest ACV Enterprise →
Mid-Market →
SMB →
Self-Serve
The gotcha: plenty of companies have never drawn the line between these, so
nobody can tell you today's ARR per segment — and every downstream number depends on it. Expect to spend real
time here. If the line has never been drawn, drawing it is part of the deliverable.
Set per segment — the base
Starting ARR and average ACV (annual, not TCV)
ARR target for each year of the window
Annual gross churn — what you must book just to stand still
Expansion share of bookings
Sales-assisted % — the rest creates no capacity demand
Seasonality across Q1–Q4
Set per segment — the funnel
MQL → SQL and SQL → Win , new logo
Sales cycle , new logo — in months
MQL → SQL and SQL → Win , expansion — almost always far more generous
Expansion cycle — almost always far shorter
Running expansion through the new-logo win rate is one of the
most common ways to overstate the pipeline a plan needs.
1.5 · The hard part

## The expansion trap.

This is the part that has cost us the most, and it is worth slowing down for. The old hunter/farmer split is
basically dead — most AEs now sell into the existing base as well as into new logos — so treating the base as
a passive block under a retention rate is no longer intellectually honest.
Why it matters this much
A company wants to go from $10M to $20M . Churn takes 10% of the base, so
you need $11M of net new bookings, not $10M. Now the question that decides the whole plan:
how much of that $11M comes from the existing book?
If none of it does
~$44M of new-logo pipeline
At a 25% win rate, every dollar has to be sourced cold. Marketing carries all of it.
If half of it does
~$22M of new-logo pipeline
The other half comes through the base at a far better win rate and a shorter cycle — and it is sales-driven, not campaign-driven , so it barely touches the marketing plan at all.
Same target. Same win rate. Half the pipeline number,
and a completely different marketing budget conversation. This is the input that most changes what you tell
the room to go and do.
1
Do the organic math first
Usage growth, price increases, natural seat creep, auto-renew uplift. Whatever happens without a rep touching it . Net that out of the base before anything else.
2
Then layer rep-driven expansion on top
The opportunities an AE actually works. Only this share consumes sales capacity , and it runs through the expansion funnel — higher win rate, shorter cycle.
3
Write the line down and get it signed
The two are not cleanly separable and everyone knows it. That is exactly why the decision has to be explicit, owned by a name, and logged — rather than quietly assumed differently by sales and CS.
So what
Ask one question and do not leave the room without an
answer: "How much of next year's growth comes from customers you already have — and who has to go and
get it?" Every capacity number downstream moves on that answer.
1.6 · The deliverable

## The assumption log, signed off.

Every metric that touches the model, what it is set to, where the number came from, who owns it, and whether
it is agreed. It lives on its own tab in the app, and it is the artifact that makes the plan defensible six
months later when somebody asks why the pipeline target was what it was.
Customer actual
Best
Pulled from their own system
Cite the query, not the vibe
Inferred
Good
Derived from their data
State the proxy you used
Benchmark
A question
Nothing to observe or infer
Every one is an open item
Executive judgment
A decision
Target-setting, policy, design
Needs a named owner
Status

### Conflict is the real find

An assumption tagged Conflict means two leaders are running the business off different numbers. That is not a modelling problem — it is the actual thing this project exists to fix, and it is worth surfacing loudly.
Status

### Benchmarks are unasked questions

Anything still tagged Industry benchmark at kickoff is a question you have not asked yet. Work the list down; you will rarely get to zero, and you should be able to say exactly what is left and why.
Sign-off

### Get it in writing

On the bigger engagements, run the log as a formal executive sign-off document — function by function, one owner per line. Export it to CSV out of the app and attach it to the plan.
2
Phase 2

## Build.

Build is fast, because the app already exists.
Two passes: top-down to set the north star, bottom-up to see whether you can actually staff it — then reconcile
until they meet. The reconciliation is the centrepiece of the whole deliverable.
1
Top-down — set the north star
ARR targets by segment, plus the retention and funnel inputs you agreed in Blueprint. The model back-solves the rest: bookings, pipeline, SQLs, heads . It uses blended averages, so treat it as the gut-check, not the answer.
2
Bottom-up — build the real org
Named reps, real start dates, real ramp, real attainment. Named SDRs. Named CSMs. Channels with a quarterly pipeline quota. This is where you find out whether the top-down plan is a plan or a wish.
3
Reconcile
The app scores bottom-up supply against top-down demand every quarter, across bookings, pipeline, SQLs, CSM dollars and CSM logos . Green covers it. Red is a gap you close by hiring, by raising a rate, or by moving the target.
2.1 · The four capacity plans

## One workshop per function. Usually three rounds.

Run each of these with the leader who owns it. They will work it, you will meet as a group, and they will
rework it — plan for that rather than being surprised by it.
Sales
The CRO
Quota per ramped rep, by segment
Expected attainment (never 100%)
Ramp to productivity , not to onboarded
Named reps with real start months
Manager span of control
Sales Dev
VP Sales Dev
Sourced pipeline per SDR per month
Held meetings, not booked meetings
SQLs — needs an agreed acceptance step
Ramp and named roster
Marketing
The CMO
Channels, each with a pipeline quota
Expected mix across channels
Quarterly, not annual
No budget. No ROI. On purpose.
Customer Success
VP CS
ARR per CSM
Logos per CSM
Whichever binds first is the constraint
Tiered or pooled models as separate teams
Gotcha

### Nobody remembers the managers

"We need thirty CSMs." Fine — who manages thirty people? The management layer gets left out of almost every capacity plan we inherit, and it is a material number of heads. Model managers explicitly, from their own start dates.
Gotcha

### "Ramp is two weeks"

They mean they can learn the product in two weeks. Ramp means closing deals at the full rate . Ask "when do they close at steady state?" and infer it from the CRM. The gap between the two answers is frequently four months of capacity.
Gotcha

### Logo load hides behind dollar load

CS coverage looks healthy on dollars and fails on accounts. At low ACV, account load binds long before the book value does . Read both, and lead with whichever is worse.
2.2 · Marketing

## A pipeline quota, not a budget.

Do this
Give each channel a quarterly pipeline number
Exactly like a rep's quota. Agree the mix — inbound, paid, events, partners, base and referrals — then hand the pipeline plan to marketing and let them go and fight for the budget that delivers it.
Not this
Budget and ROI per channel
Every time we have taken the model that far it gets gamed — "this channel has better ROI, so put everything into it" — and it ignores channel elasticity . Some channels simply cannot absorb more money. There are only so many events. Your best channel may depend on one person's calendar.
2.3 · The other trap

## Pipeline leads bookings by one full sales cycle.

The mistake almost everyone makes
They look at the bookings plan for Q3, see a 25% win rate, multiply by four, and call
that Q3's pipeline goal . It is not. That was Q2's job . With a three-month cycle, the pipeline that
produces Q3 bookings had to exist at the start of Q2.
Build it here Q2 pipeline →
3-month cycle →
Q3 bookings
The model already shifts the demand line back by each
segment's cycle, so the tool will not get this wrong. Your job is to say it out loud in the room — because
a pipeline gap spotted late is a bookings gap that can no longer be fixed.
2.4 · The line we don't cross

## Stay out of their financial data.

No salaries. No OTE. No marketing budget. No tech-stack spend. The model carries
capacity and headcount — and deliberately nothing that has a dollar cost attached to it.
It starts a fight you cannot win. Put a cost number in front of finance that they disagree with and the meeting becomes about that number.
Distrust is contagious. Once they poke a hole in one cost line, they stop trusting the parts of the model that were actually right.
It is not our job. Hand finance a capacity plan and let them do the ROI, the burn and the P&L. That is the division of labour they want anyway.
It muddies the value. The model's job is to answer "can this org hit this number?" — cost lines make that answer harder to see, not easier.
The app enforces this: there are no cost fields anywhere in it.
Managers are modelled as headcount and span of control, never as salary.
2.5 · Scenarios

## Bear, Base and Bull — differing on inputs, not just targets.

Three plans, built from three sets of assumptions. If your bull case is just the base case with bigger
numbers typed over the top, you have not built a scenario — you have built a wish.
Bear
Demand softens
Lower win rates, longer cycles, higher churn
Attainment drops
You already hired for Base
Watch coverage go slack , not short
Base
The committed plan
The number you run the business against
The org you are actually staffing
Coverage should land near 1.0×
Bull
Upside
Better win rates, hotter expansion
Bigger targets
Usually under-resourced on purpose
"Here is the hiring you commit to now "
So what
A bull case with red coverage is not a forecast — it is a
hiring decision with a deadline . With a five-month sales cycle, the reps who deliver the bull case
have to be in seat long before anyone knows whether the bull case is happening.
3
Phase 3

## Enable.

The model is not the outcome. A company that
measures itself against a plan every month is the outcome. Enable is where you make sure that happens.
Step 1
Walk it function by function
Each leader sees their own capacity plan, and how it rolls into the number. No surprises in the group session.
Step 2
The readout
Present the plan, the gaps and the assumption log to the exec team. Consider a narrated walkthrough of the findings so people who miss the meeting still get the argument.
Step 3
Hand over the live model
Not a spreadsheet attachment. Give them the app itself so the plan stays editable, shareable and single-source. A model in an inbox is dead on arrival.
Step 4
Stand up performance-to-plan
A dashboard we own, a monthly reporting pack, or the live view in Vasco. Something that says every month: here is where we said we would be, here is where we are.
Where Vasco fits
Before: the diagnostic is the prerequisite — it is where most of the research pass comes from.
After: Vasco becomes the live version of the growth model — performance to the plan you just set.
For accounts that don't fit the Vasco model, a monthly reporting pack does the same job.
How to position the project
An architect can run this solo — no engineering support once the app is stood up.
Which means it works as a bonus project or as part of onboarding, rather than burning one of their project slots.
Showing up to the first sprint call with a pre-populated model is a very different first impression than a blank template.
4
Phase 4

## Maintain.

A plan nobody revisits is worse than no plan,
because people keep quoting it long after its assumptions went stale. Set the clock, and set the triggers.
Monthly
Measure performance to plan
Not a rebuild. Just: where did we say we would be, and where are we — on bookings, pipeline and headcount.
Quarterly
Reforecast
Revisit the assumptions that moved. Adjust targets or capacity. This is the recommended cadence.
Every half
The minimum
If quarterly is not realistic for them, every six months is the floor you should accept.
Annually
Bare minimum
Once a year is barely maintenance. If this is where they land, say so plainly.
Event triggers

## Rebuild on events, not just on the calendar.

Trigger

## The model, live.

The collaborative growth model and capacity plan, pre-loaded with a worked example: a fast-growing Series B
B2B SaaS company at $12M ARR , four segments, a three-year window, and all three plans built —
Bear, Base and Bull . This shared copy is open — the link goes straight in , no passphrase,
because it only holds sample data. Clone it per customer, and gate that copy.
Base
Staffable
$12M → $47.3M · 58% CAGR
Bookings coverage 1.03×
The org you are actually hiring
Bull
Not staffed yet
$12M → $62.3M · 73% CAGR
Bookings coverage 0.81×
The hiring conversation, with a deadline
Bear
Slack capacity
$12M → $28.7M · 34% CAGR
Bookings coverage 1.57×
You hired for Base and demand came light
leanscale-growth-model.netlify.app
Open ↗
▶
Load the live growth model
Loads the real app inline · no passphrase, it opens straight in · or open it in a new tab ↗
What's in it
Growth — segmented ARR targets, by year or by quarter, with retention and funnel inputs
Pipeline — back-solved demand, cycle-shifted, monthly or quarterly
Sales · SDRs · Marketing · CS — the four bottom-up capacity plans, named people and all
Self-Serve — the product-led motion in its own silo
Plan vs Capacity — the reconciliation; the centrepiece
Assumptions — the sign-off log, with CSV export
Compare — Bear vs Base vs Bull, outcomes and coverage
Cloning it for a customer
New Netlify site and a new Blobs store name in model.mjs .
Turn the gate back on. Set REQUIRE_PASS = true and a passphrase hash in
model.mjs , and set OPEN_KEY to match in index.html . The shared
template is open because it carries sample data; a customer copy holds their real ARR, targets and
named reps, and an open link means anyone who has it can edit them.
Set the company name in the menu — it renames the app everywhere.
Replace the seed with their segments, or just edit over the sample.
Live multi-editor, conflict-safe. Send the link to the CRO.
Expect to extend it: physical inventory, services delivery capacity, PQL-split funnels. It is a
general model — most customers need one thing added.
LeanScale · Delivery OS
The Growth Model playbook — the internal standard for building a customer's two-to-three year
operating plan and the capacity plan that delivers it.

## Canonical

https://knowledge.leanscale.team/playbooks/growth-model-playbook/