Scenario Planning vs Sensitivity Analysis: Which Question You're Actually Asking

Two finance teams run what they both call "downside analysis" and produce different artifacts. One flexes churn from 3% to 4% and reads the runway impact off a single output cell. The other builds a coherent recession narrative — bookings down, expansion frozen, collections slower — and reprices the whole model against it. The confusion between scenario planning vs sensitivity analysis isn't semantic. The two methods answer different questions, and running one when you needed the other produces a model that looks rigorous and misdirects the board.

Two questions, not one

Sensitivity analysis asks: what happens if one number changes? You isolate a single input, hold everything else constant, and measure the effect on an output you care about. It is a partial-derivative exercise — the finance equivalent of turning one knob to see how loud it gets. The CFA Institute treats it as a core valuation technique for exactly this reason: it quantifies which assumptions your answer actually depends on.

Scenario planning asks: what happens if the world changes? You move several inputs together in a way that reflects a plausible future, because in the real world drivers are correlated. Churn rarely rises while expansion revenue holds steady; a demand shock hits new logos and net retention at the same time. The discipline has roots in Shell's scenario practice from the 1970s, which was never about single-variable precision and always about coherent, internally consistent futures — an approach Harvard Business Review has since traced from Pierre Wack's original planning group through its adoption across corporate strategy.

The failure mode is treating a bundle of correlated moves as if it were one knob, or treating a single knob as if it described a world. Both leave you confident about the wrong thing.

A worked example: $30M ARR SaaS

Take a company at $30M ARR, growing 40% annually, burning $1.4M a month, with 18 months of runway on the base plan. The model has maybe forty inputs. You cannot scenario-plan forty inputs — that's 3^40 combinations and a spreadsheet nobody trusts. So you start with sensitivity analysis to find out which inputs matter.

You flex each driver ±10% in isolation and rank the impact on runway:

• Gross churn: +2 points of monthly churn cuts runway by roughly five months. Dominant.
• Sales-hire ramp: pushing new-rep productivity from month four to month seven pushes back the ARR curve and costs about three months of runway. Second.
• CAC: a 10% move matters, but less — call it six weeks.
• Hosting and COGS: a rounding error at this stage.

Now you know something you didn't before: two independent drivers — churn and ramp — govern the outcome. Everything else is noise you can hold flat. That ranking is the entire point of doing sensitivity first.

Bundling coherent futures

With the two drivers identified, scenario planning gets tractable. You build three worlds, not twenty:

• Base: churn holds at plan, ramp lands on schedule, expansion ARR contributes as modeled.
• Downside: gross churn +2 points, new logos −30%, and — the move a naive model misses — expansion ARR goes to zero, because the same macro pressure that suppresses new bookings freezes existing accounts from upgrading. That correlation is invisible to single-variable sensitivity. It only shows up when you force yourself to describe a world.
• Severe downside: the above plus a hiring freeze that breaks the ramp assumption entirely.

The downside isn't the arithmetic sum of the two worst sensitivities. It's a story where the drivers move together, and the combined runway hit is worse than the parts — the correlated version lands closer to nine months than five. That gap between the additive estimate and the coherent one is the reason the two methods can't substitute for each other.

Stress testing is a third thing

Neither method is stress testing, which deserves its own name. Sensitivity and scenario analysis ask what happens under plausible moves. Stress testing asks what happens under deliberately implausible ones — the tail. Regulators formalized this after 2008; the Federal Reserve's CCAR program exists to ask banks what breaks when unemployment doubles overnight, not what happens in a normal recession, using supervisory scenarios that are engineered to be severe rather than probable.

For a growth-stage company the analog is: what if your largest customer, 12% of ARR, churns next quarter and your next raise slips two quarters? You don't assign it a probability. You run it to find out whether the company survives, and what covenant or cash trigger you'd hit first — which is where trigger-based planning picks up, converting the stress result into a decision you've pre-committed to.

The assumption problem underneath all three

Every one of these methods is only as good as its inputs, and this is where most of them quietly fail. If you rank sensitivities on last quarter's churn cohort and that cohort was distorted by a one-time enterprise loss, you'll crown the wrong driver and scenario-plan around it. You'll spend three weeks modeling CAC when the real fragility was net retention that only shows up in this month's data.

This is the deeper argument for why FP&A has to sit on live data rather than a quarter-end snapshot, and it's the connective tissue across scenario planning as a decision function. A sensitivity ranking built on stale numbers isn't neutral — it actively points attention at yesterday's risk. When the underlying model lives in a spreadsheet refreshed by hand once a month, the ranking is stale by construction, which is one of the ways spreadsheet scenario models break down as the company scales.

The practical sequence, then, is fixed. Get the inputs current. Run sensitivity to find the two or three drivers that move the outcome. Bundle those into a handful of coherent scenarios. Reserve stress testing for the tail cases you need to survive rather than forecast. Teams that invert this — starting with twenty hand-authored scenarios — burn weeks producing a model that answers a question nobody asked.

The teams that keep the input layer current tend to run this sequence in an afternoon, not a quarter — see how continuous data changes the cadence. →

For the fuller argument on operationalizing this inside a finance org, the visibility section collects the related pieces; the mechanics of building the models themselves live under tools.