How to build a good driver-based model

Tearing something down is the easy half. I argued last time that most “driver-based” models aren’t. They’re budgets with extra rows. Harder, and more useful, is saying what a good one actually looks like, in terms specific enough that you can hold your own model up against them. So here’s the standard. A good driver-based model shares five traits, and there’s a single test at the end that tells you whether you’ve hit them.

1. It runs on a few drivers, chosen on purpose

The instinct is to model everything. Resist it. In most businesses six or eight drivers explain the bulk of the forecast (customers and ARPU, headcount by function and loaded cost, sales capacity and attainment), and the rest is noise you can plug with a typed number and a footnote. Picking those few is the actual skill, and it’s a judgment about materiality, not a technical step. A model that drives a $40K marketing line off a three-tab CAC engine while revenue sits hardcoded has put its machinery in exactly the wrong place. Few drivers, each chosen because it moves the number.

2. Drivers are operational; the financials are outputs

A driver is something the business manages directly: heads, units, win rate, price, ramp, churn. The financial lines are what those produce. Revenue is price times volume. Payroll is heads times loaded cost. Gross margin is whatever falls out above it. If you’re typing a number straight into a financial row, that row isn’t being driven. It’s being asserted. The line you’d have to defend in a board meeting should trace back to an operational input, not to last year plus four percent.

If you can type over a number and the model doesn’t argue with you, that number was never a driver.

3. One change ripples through the whole thing

This is the trait you can feel. Change a driver (add five reps, push hiring out a quarter, lift price 3%) and a good model updates everything downstream on its own: capacity, bookings, revenue, commission, payroll tax, the software seats those reps need. You touched one cell. A model that makes you hand-edit eight other cells to keep the story consistent isn’t saving you the work driver-based modeling exists to save. Connectivity is the whole point. Without it you’ve paid the complexity cost and kept the manual labor anyway.

4. The relationships behind the drivers are real, and you know when they break

Wiring payroll to headcount times average loaded cost is only right while the mix of senior and junior heads holds. Tilt hiring toward ten senior engineers and the average is wrong, so the model now produces a confident payroll number that’s too low. Good models make the load-bearing assumptions explicit (the average cost, the ramp curve, the attainment rate) so you can see what you’re trusting and notice when reality drifts from it. A relationship you can’t see is a relationship you can’t check.

5. You can read it

The assumptions live in one place, on an inputs sheet, not buried inside formulas three tabs deep. Someone who didn’t build the model can open it, find the drivers, change one, and follow the effect. This sounds like hygiene; it’s actually a correctness feature. Hardcodes hidden inside a SUMPRODUCT are where models quietly go wrong and stay wrong, because nobody can find the number to question it. If you can’t point to every driver in under a minute, neither can the analyst who inherits the file.

What a good model leaves alone

Knowing what not to drive is part of the craft. Immaterial lines, genuinely unpredictable items, anything where a formula would imply precision you don’t have — those get a typed number and a note, on purpose. Over-engineering is its own failure mode: forty drivers nobody can hold in their head lose trust as fast as zero. The goal isn’t maximal mechanism. It’s the least machinery that produces a forecast you can stand behind.

The test that settles it

One back-test ends the argument. Take last quarter’s actual driver values (the real headcount, the real units, the real price) and feed them in. A good model reproduces last quarter’s actual P&L, close enough that the few gaps are explainable. If it doesn’t, one of your relationships is wrong, and now you know which block to fix before you trust it for next quarter. Build the model forward; prove it backward.

Hit those five and the back-test, and the model stops being a tidy record of your assumptions. It becomes something you can ask a question and believe the answer. That’s the difference worth building for.