Inside a 3-Statement Model: What 'What If' Actually Means in a Model That Works

What 'What If' Actually Means in a Model That Works

I was stress-testing a hiring decision last week for a SaaS founder. She'd built a "low growth" scenario by reducing revenue 20%, left everything else unchanged, and the model still showed enough cash to bring on two engineers.

The scenario passed. She scheduled the offers.

I ran it again, this time linking churn assumptions to growth rate. In a genuine low-growth environment, you're not just selling less—you're also retaining worse because the product-market signals that drive renewals are weakening at the same time. Suddenly the model showed a cash gap by week nine.

"What if" isn't changing one input. It's identifying which variables move together when the world shifts.

This is the third instalment in a four-part series on building 3-statement models and 13-week cash flows that hold under pressure. [Last week](PREVIOUS_POST_URL) we covered why the 13-week cash forecast matters more than the annual projection. This week: why most scenario tests fail before they start, and what a working scenario actually looks like. A shorter version of this post appears on [LinkedIn](LINKEDIN_POST_URL).

The Independence Fallacy

Most founder-built scenarios treat inputs as independent. Revenue drops, but margin holds. Growth slows, but churn stays flat. Customer acquisition cost rises, but close rates don't fall. Each variable gets its own slider, as if business pressures arrive one at a time and wait their turn.

Real stress doesn't work that way. When growth slows, it's because multiple dynamics are breaking simultaneously: pricing pressure (lower margin), longer sales cycles (higher CAC), weaker retention (higher churn). The variables correlate.

A working scenario doesn't just flex the numbers. It maps the interdependencies first, then stresses the system.

The trap is that independent scenarios feel rigorous. You're testing multiple cases, you've built the flexibility, you're being prudent. But if your "downside case" just dials revenue down without touching the assumptions that depend on revenue momentum, you're not testing a plausible future. You're testing an arithmetic exercise.

This compounds the static assumption problem from week one: if your base case treats growth as a single input rather than a system of retention, upsell, and acquisition, your scenarios inherit that same flaw. You're stress-testing the wrong structure.

What breaks: the decision looks safe in your model, then reality delivers correlated pressure your scenarios never considered.

Mapping the Correlations That Matter

Let's work through the hiring example in full, because it shows every failure mode at once.

The founder's original "low growth" scenario reduced monthly recurring revenue by 20%. Her base case assumed £80,000 MRR, so the downside case dropped it to £64,000. She left churn at 3% monthly, gross margin at 75%, and CAC at £4,200 per new customer. The model still showed positive cash through the 13-week window, so she approved two engineering hires at £6,000 per month each.

The problem wasn't the revenue haircut. The problem was that every other assumption stayed anchored to a world where the business was healthy enough to deliver £80,000 MRR in the first place.

In reality, if MRR is falling 20%, it's falling because something upstream broke. Either you're acquiring fewer customers, losing more of them, or both. Churn doesn't stay at 3% when the product isn't delivering the outcomes that justified renewal in the first place. Gross margin doesn't stay at 75% when you're discounting to hold onto customers who are on the edge. CAC doesn't stay at £4,200 when your sales cycle is lengthening because prospects are less convinced.

Here's what the correlations actually look like:

The "Growth Shock" is the 20% revenue reduction. The sensitivity coefficients tell you how much each dependent variable moves when growth deteriorates. These aren't arbitrary. They come from historical data, cohort analysis, or—when you don't have enough history—conservative industry benchmarks.

When I re-ran the founder's scenario with correlations intact, churn rose from 3% to 4.2% monthly (a 1.2 percentage point increase for every 20% growth shock, based on her cohort retention curves). Gross margin dropped from 75% to 72% (she'd been holding pricing through discounting, which shows up in COGS as higher support costs per customer when you're retaining weaker fits). CAC rose from £4,200 to £4,900 (sales cycles were lengthening, which her CRM data confirmed).

Now the cash position at week nine turned negative. The two engineering hires she was about to make would have pushed the business into a gap it couldn't close without either raising emergency capital or cutting elsewhere.

She delayed the hires. Not because the model told her not to grow, but because it told her the timing was wrong and the cash cushion she thought she had didn't exist under realistic stress.

What a Correlated Scenario Actually Tests

A working scenario isn't pessimistic. It's internally consistent. It asks: if this one thing breaks, what else has to give?

The correlations you need to map depend on your business model, but the structure is the same across every model I build:

Revenue drivers correlate with each other. If new bookings fall, it's rarely because one channel went cold in isolation. It's because deal cycles lengthened, close rates dropped, or pricing pressure built—all of which show up in your pipeline data before they show up in revenue. Your scenario should link pipeline velocity to bookings, and bookings to revenue timing.

Retention correlates with growth momentum. High-growth companies retain better not because their product is better, but because they're serving customers in expansion mode who have budget, urgency, and executive attention. When growth slows, you're often serving a different customer profile—late adopters, smaller deals, price-sensitive buyers—and those cohorts churn faster. Your churn assumption in a downside case should reflect that shift.

Margins correlate with competitive pressure. Gross margin holds when you have pricing power. Pricing power comes from demand exceeding supply, which is another way of saying growth. When growth slows, pricing pressure builds, and you defend revenue by discounting, offering more services for the same price, or absorbing costs you used to pass through. All of those show up as margin compression. Your downside scenario should stress margin whenever it stresses growth.

Operating leverage reverses under stress. In a high-growth environment, fixed costs get spread across rising revenue, and your operating margin improves even if you're not cutting costs. In a low-growth environment, the same fixed cost base now sits on top of slower revenue, and operating margin compresses. Your downside scenario should model opex as semi-fixed (some costs flex, most don't), not as a neat percentage of revenue.

These aren't exotic insights. They're the mechanics every CFO already knows. The reason founder-built models miss them is that founders build models input by input, not system by system. Each assumption gets its own cell, its own logic, its own scenario slider. The model never asks whether those assumptions make sense together.

A working model structures the dependencies first, then lets the scenario test the system.

The Formula That Holds It Together

The equation that makes this real is simpler than it looks:

That's just the cash flow statement in one line. But every term on the right-hand side depends on the correlations we've been mapping.

Cash inflows depend on revenue, which depends on bookings, which depend on pipeline velocity and close rates. Cash outflows depend on operating costs, which depend on headcount, which depends on hiring decisions you're making now based on a revenue forecast that might not hold.

When you stress-test the model, you're not just changing revenue. You're changing every assumption downstream of revenue, tracing the impact through to cash, and asking whether the decision you're about to make still holds.

Here's what that looked like in the hiring example, week by week:

Base case (no shock): Cash starts at £95,000. MRR of £80,000 per month, churn at 3%, two new customers per month at £4,200 CAC each. Gross margin at 75%, opex at £52,000 per month including the two new hires. Cash at week 13: £103,000.

Downside case (independent assumptions): Revenue drops to £64,000 MRR, everything else unchanged. Cash at week 13: £71,000. Still positive, hires still look safe.

Downside case (correlated assumptions): Revenue drops to £64,000 MRR, churn rises to 4.2%, gross margin falls to 72%, CAC rises to £4,900. Cash at week 9: -£3,000. The model breaks before you reach week 13.

The difference between the second and third scenarios is the difference between a model that passes a decision it shouldn't, and a model that flags the risk in time to adjust.

The Edge Cases That Break Most Models

The correlations above cover the common cases. The edge cases are where most models fail, because they involve dynamics that don't show up in your historical data or don't fit into a tidy formula.

Timing lags between cause and effect. When growth slows, churn doesn't spike immediately. It shows up two or three months later, after the customers who renewed during the high-growth period come up for their next renewal and decide not to continue. Your scenario needs to model the lag, not just the correlation. If you stress churn in the same month you stress revenue, you're overstating the immediate impact and understating the delayed risk.

Non-linear relationships. Most correlations aren't linear. A 10% revenue drop might increase churn by half a percentage point, but a 30% revenue drop might increase churn by three percentage points, because at that level of stress you're losing not just marginal customers but core customers who stuck with you through the first wave of trouble. Your sensitivity coefficients should reflect the non-linearity, or at minimum test multiple levels of shock to see where the relationship bends.

Second-order effects that feed back into the model. When churn rises, it doesn't just reduce revenue. It also reduces the size of your installed base, which reduces the pipeline of upsell opportunities, which reduces future revenue growth even after the initial shock passes. Your model should feed churn back into the base that drives future growth, not treat it as a one-time haircut.

Threshold effects that trigger discrete changes. Some costs are fixed until they're not. Headcount is the obvious example: you can't reduce it by 10%, you reduce it by whole people. When your cash position deteriorates, the decision isn't "reduce opex by 15%," it's "do we let someone go, and if so, who, and what does that do to delivery capacity?" Your scenario should model the discrete decisions you'd actually face, not the smooth percentage adjustments that make the math easier.

None of these are optional refinements. They're the mechanics that determine whether your scenario survives contact with a real decision.

What This Means for the Decision in Front of You

The founder didn't cancel the hires permanently. She delayed them eight weeks, used the time to close two deals that had been sitting in late-stage pipeline, and rebuilt the cash cushion before bringing the engineers on.

The model didn't tell her not to grow. It told her the sequence mattered, and the risk she thought she had room for didn't exist under realistic stress.

That's what a working scenario does. It doesn't produce a single number you either believe or don't. It shows you the range of outcomes that are plausible given what you know, maps the dependencies that connect them, and lets you see which decisions hold across that range and which ones only hold if everything goes right.

Most models don't do this because most models were never built to. They were built to produce a forecast, pass it to the board, and move on. The scenario testing is an afterthought, a sensitivity table at the end of the deck that no one believes and no one uses.

A working model inverts that. The scenario isn't the appendix. It's the whole point. The base case is just one scenario among many, and the value of the model is that it lets you test all of them before you commit.

Why This Matters More Now

The margin for error is tighter than it was two years ago. Capital is more expensive, revenue is harder to grow, and the decisions that used to be reversible—hire someone, sign a lease, commit to a vendor contract—are now decisions you live with for longer because unwinding them is costly.

When the margin for error was wide, you could afford to test decisions in the market and adjust when reality diverged from your model. When the margin is tight, you need the model to catch the divergence before it becomes a problem you're managing in real time with no room to maneuver.

That's not a macro opinion. It's the pattern I see in every model I'm building this quarter. The founders who are navigating this environment well aren't the ones with the most conservative forecasts. They're the ones with the most rigorous scenario tests, who know which assumptions are load-bearing and which ones are decoration, and who've mapped the correlations before the pressure arrives.

The ones who aren't navigating it well are the ones whose models still treat every input as independent, every scenario as a thought experiment, and every decision as reversible.

Next week: how a working model becomes the infrastructure that supports decisions before they're made, not just the spreadsheet that explains them after.

If you're building a model that needs to hold under correlated stress—or if the one you have isn't catching the risks before they land—the work is available: [calendly.com/muhammed-adediran/30min](https://calendly.com/muhammed-adediran/30min)