-
1
Pick the model type that matches your motion
Start by choosing a model shape that fits your business, not the one your last company used. The two primary axes are bottoms-up versus top-down, and cohort-decay versus cumulative. Bottoms-up builds revenue from channel-level inputs like leads, conversion rates, and ARPA, which suits product led and velocity motions where volume math dominates. Top-down starts from a market or capacity ceiling and allocates share down to segments, which suits enterprise motions with low deal count and long cycles. Cohort-decay projects each acquisition cohort forward with its own retention curve, while cumulative treats the installed base as a single pool. Most mature SaaS teams end up blending bottoms-up new business with cohort-decay retention, because the two sides of the P and L behave differently.
- Score your motion on deal count, average contract value, and sales cycle length before picking a shape
- Default to bottoms-up for self-serve or velocity, top-down for enterprise, and hybrid for everything in between
- Use cohort-decay for retention and expansion math any time you have more than four quarters of history to anchor it
Tip: Do not try to model every lever on day one. Ship a working v1 against the three or four inputs that move the number, then add fidelity in later iterations.
-
2
Build the input layer and lock the definitions
The quality of a growth model is set by the inputs, not the formulas. Build an input tab that holds every assumption the projection depends on, grouped by category: ARPA by segment and plan, CAC by channel, gross and net churn by cohort age, and growth rate per acquisition channel. Every input needs a source, an owner, and a last-updated date so the model can be audited later. Separate the inputs tab from the calculations tab so analysts can change assumptions without breaking formulas. Flag any input that is a placeholder in a different color, and track the delta between placeholders and sourced values as a quality metric for the model itself.
- Group inputs into four buckets: pricing and ARPA, acquisition and CAC, retention and churn, and expansion rates
- Attach a source cell to every input: either a historical period, a benchmark link, or a named owner who signed off
- Freeze the input tab against formulas so a stray edit cannot propagate silently into the projection
Tip: Write the metric definitions above the input table and link them to the shared glossary. Half of modeling arguments are definition arguments in disguise.
-
3
Build the output projection across 12 to 24 months
Project the model forward on a monthly grid for 12 to 24 months. Twelve months is enough for the operating plan, 18 to 24 months is where board narratives and hiring plans live. The output should show new ARR, expansion ARR, contraction, churn, and ending ARR for every month, with gross and net retention computed from the same cohort tables that drive the retention assumption. Pair the ARR view with a bookings view and a cash view, because the three numbers diverge in interesting ways under annual billing and multi-year deals. Keep formulas horizontal and consistent across the row so a single cell change can be audited by dragging across periods.
- Lay out the output with months across and metrics down, mirroring the finance team's reporting pack
- Compute ending ARR as beginning ARR plus new plus expansion minus contraction minus churn, every single month
- Add a bookings and cash view beside the ARR view so finance can tie the model to the P and L and the cash forecast
-
4
Run a sensitivity analysis with three scenarios
A single-point projection is a wish, not a model. Build three scenarios on top of the base case: a downside that stresses the two inputs most likely to disappoint, an upside that funds the two levers most likely to compound, and a stretch that assumes a step function in one specific channel. Run each scenario by cloning the input tab, not by overwriting the base, so the three views can be compared side by side. Tag every scenario with the two or three assumption changes that produce it, because the conversation on the output is really a conversation on which inputs the exec team believes. Keep the deltas transparent so the board can see which lever moves which number.
- Pick the two inputs most sensitive to miss in your business and vary them by plus or minus one standard deviation
- Document the specific assumption changes behind each scenario so the delta is auditable, not vibes
- Chart the three ending ARR curves on one view so the fan of outcomes is visible, not buried in tabs
Tip: If the downside and upside produce the same number, your sensitivity ranges are too narrow. Widen them until the fan actually tells you something.
-
5
Present the model to the exec team and the board
A growth model only earns trust when it is explained in plain language. Build a one-page summary that leads with the three scenarios, the two or three inputs that drive them, and the hiring plan, cash runway, and net retention each scenario implies. Pair the summary with a short appendix that shows the input tab, the cohort table, and the historical fit of the base case against the last four quarters of actuals. Walk the exec team through the model once before the board sees it, so finance, marketing, sales, and customer success can all stress test the assumptions in their domain. The board conversation should be about which scenario to fund, not about which cell is wrong.
- Lead with the three scenario curves and the two inputs that drive each one, not the input tab
- Include a historical fit chart that shows how the base case would have predicted the last four quarters
- Pre-brief every exec in their functional domain so the board meeting is a decision, not a debug session
-
6
Publish the model as a single source of truth
A growth model that lives on three laptops is not a growth model. Pick one location, usually a shared drive folder owned by finance, and declare it the only authoritative version. Version control the file by date in the filename, and keep an archive of every monthly cut so the historical fit tab can be reconstructed. Grant edit access to a short list of named owners and comment access to the broader exec team, because scope creep on who can edit is how models drift. Link to the model from the operating cadence doc, the board materials folder, and the planning tracker so every downstream artifact pulls from the same cell values.
- Pick one home for the model, usually a finance owned shared folder, and link to it from every planning doc
- Version by date in the filename and archive the prior cut on every monthly update so history is preserved
- Restrict edit access to a small named list and give everyone else comment or view rights by default
-
7
Update monthly against actuals
A model that is not refreshed against actuals is a slide, not a tool. Set a monthly cadence where finance drops in the actual period a few business days after close and the model recomputes forward on the latest cohort behavior. Keep the base case assumptions frozen between quarters so the drift between model and actuals is visible, then recalibrate on a quarterly basis as part of the forecast cycle. Treat each monthly refresh as a small variance review: did new ARR, churn, and expansion land where the model said they would, and if not, which input needs an update. Teams that run this loop every month cut their forward error materially within three quarters.
- Set a fixed day of the month for the refresh and name the finance owner who runs it
- Keep base case inputs frozen between quarterly recalibrations so drift is visible, not papered over
- Snapshot the pre-refresh and post-refresh outputs each month so the variance log has clean inputs
Tip: Refresh even in a month where the number is on plan. Hitting on luck looks like hitting on process until you decompose the drivers.
-
8
Decompose variances and feed the next cycle
The point of the model is not the projection, it is the learning loop. Every quarter, decompose the variance between forecast and actual into the individual input drivers: did new logo volume miss, did ARPA move, did churn tick up, did expansion lag. Attribute every piece of the variance to a specific input and a specific owner, and feed those tags into the next quarter's input updates and into the sensitivity ranges. Over three to four quarters, the variance decomposition itself becomes a data set that tightens the next model, because you learn which inputs are reliable and which ones need wider bands. This is how modeling maturity compounds instead of resetting every year.
- Decompose each quarterly variance into new, expansion, contraction, and churn drivers before anything else
- Attribute every driver to a named owner so the next-cycle update has an accountable editor
- Widen the sensitivity bands on inputs that missed by more than one band two quarters in a row
Tip: Publish the variance decomposition to the whole exec team, not just finance. The model is a shared instrument, not a finance artifact.