Scenario planning for startups: build models that actually drive decisions

Most scenario plans get built once, presented at a board meeting, and never opened again. That is not a planning problem - it is a design problem. The model was built to report, not to decide.

This article gives you a framework for scenario planning that is wired to decisions: hiring calls, fundraising timing, burn rate adjustments, and where to redirect sales capacity when a quarter starts missing. By the end, you will know how to build scenarios your whole leadership team can act from, not just your finance lead.

Key takeaways

• A three-scenario model (bear, base, bull) is useful only when each scenario has named assumptions, a named owner for those assumptions, and a pre-agreed response if that scenario starts materializing.
• Runway is the most important output of any scenario plan, but it is only as reliable as the input assumptions driving it.
• Sensitivity analysis - testing which variables move runway most - is where scenario planning pays its biggest dividend. It tells you where to concentrate attention and where not to.

What this article covers

1. Why single-point forecasts fail and what to build instead
2. The five inputs that drive most SaaS scenario outcomes
3. How to structure bear, base, and bull cases with specific numbers
4. Sensitivity analysis: finding the variables that actually matter
5. How to connect scenarios to decisions, not just reports
6. Scenario planning in board and investor contexts
7. Common mistakes and the fixes for each
8. A scenario planning checklist you can use this week

Why a single forecast makes your runway fragile

Operating from one forecast is the financial equivalent of navigating without a backup route. It is not that your base case is wrong - it is that a base case is an average, and averages do not capture the risk on either side.

The specific failure mode: you build a 12-month plan in January with 8% MRR growth, flat churn, and headcount scaling in Q2. By March, churn is up 2 percentage points and a key sales rep left. Your plan still says 12 months of runway. Your actuals say 7.

That gap - between what the model assumed and what is now true - is not a forecasting error. It is an assumptions ownership problem. Someone set the 8% growth input. Nobody was watching it. Nobody had a pre-agreed response when it moved.

Scenario planning fixes this by replacing the single plan with a range of credible futures, each with named inputs, a named owner, and a trigger-based response protocol. If you have not yet nailed down how to calculate your runway correctly, that is the prerequisite - because the accuracy of your scenario outputs is only as good as the cash burn inputs feeding them.

The five inputs that drive most SaaS scenarios

Before you build three scenarios, you need to know which variables actually move the needle. Most $5-50M ARR SaaS businesses are primarily driven by five levers:

The reason this table matters: each of these inputs should have a named owner before you build any scenario. Not an owner of the output - an owner of the assumption. That is the only way your scenarios stay honest once the model leaves the finance team.

Andreessen Horowitz has been consistent on this for years: the metrics that matter are only useful when they are defined precisely and owned explicitly. The same logic applies here. If you cannot answer "who is responsible for the churn rate assumption in our base case," your scenario planning will remain a presentation layer, not a decision layer.

How to build bear, base, and bull cases with real numbers

Three scenarios is not a rule - it is a pragmatic minimum. More than three and you lose the decisional clarity that makes scenarios useful. Fewer than three and you are just running a single-point forecast with a different name.

SaaStr refers to this structure as your C-90, C-60, and C-10 plans - three distinct financial plans that represent high-confidence, base, and downside scenarios. The framing is different but the underlying logic is identical: one scenario is not a plan, it is a guess.

Start with the base case

Your base case should represent your most-likely outcome given current pipeline, current churn, and committed headcount. It is not the plan you want - it is the plan your current trajectory suggests.

A simple base-case input table for a $10M ARR SaaS company might look like this:

From those inputs, your model calculates monthly net revenue, cash consumption, and runway. The base case gives you your reference point.

Build the bear case around your biggest risk

The bear case is not catastrophe planning. It is your most plausible downside scenario - the one you would not be surprised by if it happened. For most SaaS companies between $5M and $50M ARR, the credible bear cases look like one of these:

• Churn increases 2-3 percentage points, driven by budget pressure in one or two key verticals
• A strong competitor launches a lower-priced tier and slows your net new ARR by 30-40%
• A key account churns and takes $200K-$400K of ARR with it
• A fundraise takes 6 months longer than modeled, tightening cash position

Pick the bear case that reflects your actual exposure right now - not a generic worst-case. Then set your inputs accordingly.

Build the bull case around what would have to be true

The bull case is not a reward for hitting targets. It is a test of what your business looks like if key bets land: a new channel starts converting at target CAC, an enterprise tier closes earlier than expected, or a partnership drives meaningfully above-trend pipeline.

Bull case inputs should be plausible but not assumed. The purpose is not to motivate the team - it is to understand what you would do with expanded capacity if those scenarios materialized.

The chart above shows what a bear-to-bull range looks like for a $5M ARR company with $2M in cash. The 15-month difference between bear and bull is not a rounding error - it changes whether you raise now, hire now, or cut now.

Sensitivity analysis: find the variables that actually matter

Once you have your three scenarios, run a sensitivity test on each key input independently. Change one variable by 10%, hold everything else constant, and measure the runway impact.

This is the single highest-value FP&A exercise most companies skip. It replaces gut-feel prioritization with a ranked list of where management attention actually affects cash outcomes. Understanding your burn rate versus your burn multiple is part of the same discipline: one tells you how fast you are spending, the other tells you how efficiently that spending is converting into growth.

The pattern above is typical for SaaS companies in the $5-20M ARR range: MRR growth rate is usually the dominant lever, followed by churn or NDR, then CAC. Gross margin and headcount timing tend to matter less unless you are burning aggressively or have a high fixed-cost structure.

What sensitivity analysis changes in practice:

• You stop spending equal energy on every metric and direct management attention toward the two or three variables with the largest runway impact.
• You know which hires to delay in a bear case without needing to re-run the full model - the headcount sensitivity already told you the per-head runway cost.
• You can answer a board question like "which lever would extend our runway fastest?" with a number, not a narrative.

Connecting scenarios to decisions, not reports

This is where most scenario planning breaks down. The model exists. The three cases are well-documented. Nobody references them for actual decisions.

The fix is pre-agreed triggers and pre-agreed responses, documented before you need them.

What a trigger-based response protocol looks like

A trigger is a specific, observable event that signals you are moving from one scenario toward another. A response is the pre-agreed action your leadership team commits to if that trigger fires.

The value here is not the table - it is the conversation you have before filling it in. When the CEO and head of sales pre-agree on the hiring pause trigger, nobody is making a panicked decision under pressure in month 7. The decision was already made.

At Fiscallion, the scenario models we build with founding teams are designed specifically around this protocol. The three cases matter less than the trigger-response structure that sits underneath them - because that structure is what converts a model into a management tool.

Scenario planning and headcount decisions

Headcount is where scenario planning pays off most concretely. Most hiring decisions at the $5-50M ARR stage happen outside any model. The quarterly review surfaces a gap, a department head makes a case, and the hire gets approved in isolation from the cash and runway implications. SaaStr puts it bluntly: even a slightly too-high burn rate can spiral faster than founders expect - and unmodeled headcount growth is one of the most common causes.

Scenario planning changes that calculus. When you know that your bear case runway is 9 months, and each additional hire costs $12K/month in loaded cost, the question "should we hire this head of enterprise sales now?" becomes answerable: in bear case, that hire compresses runway by 6 weeks. In base case, the payback timeline on that hire is 8 months. Make the call with that information visible.

If you want to pressure-test what that payback period actually looks like given your current acquisition economics, the CAC payback period framework is the right place to start before approving any growth hire in a constrained runway environment.

Scenario planning for board and investor reporting

Boards want three things from a scenario presentation: they want to know the range of outcomes, the assumptions behind each, and the plan for each case.

What they usually get is one case, presented as "the plan," with some hedging language in the notes.

The shift to scenario-based board reporting is not complex. It requires changing the framing from "here is what we expect" to "here is the range, here are our assumptions, here is what we do in each case." If your board materials are still structured around single-point outputs, the SaaS board reporting framework covers how to restructure that into something decision-grade.

What a scenario-ready board update looks like

• Scenario assumptions table: Three columns (bear, base, bull), five rows (growth rate, churn, NDR, CAC, burn), one number per cell. Every board member can see where you diverge from base.
• Runway by scenario: A single bar or line chart showing months of runway under each case. No explanation needed.
• Trigger dashboard: A table listing the three or four metrics you are watching as leading indicators of scenario direction, with current actuals versus base case targets.
• Pre-agreed response per scenario: One sentence per case describing what changes and who owns it.

This kind of board update does not require more data - it requires better framing. The signal it sends to investors is not that you have all the answers. It is that you know how to make decisions when the answers change.

Common scenario planning mistakes and the fixes

Using the bull case as the operating plan

The most common mistake. When forecasts are consistently set at the optimistic scenario, the bear case never gets operationalized. Teams hire against bull-case revenue that has not arrived yet, and the board is kept comfortable with projections that systematically outpace actuals.

Fix: Set your base case as the operating plan. The bull case exists to define what you would do with upside - not to justify current spending.

Building scenarios but not assigning input owners

Three scenarios with anonymous assumptions are three guesses. If nobody owns the churn rate input, nobody updates it when churn starts moving. The model drifts from reality in silence.

Fix: Before you finalize any scenario, add a column: "input owner." One name per assumption. That person is responsible for surfacing changes to that input in the monthly review cadence.

Treating scenario planning as a one-time event

Scenarios built in January for a January board deck are useless by April. Markets move, pipeline shifts, a contract gets delayed, an unexpected hire opens a new channel.

Fix: Build monthly scenario refreshes into your FP&A cadence. This does not mean rebuilding the model - it means updating five to eight key input cells and re-running the runway calculation. The whole refresh should take under 20 minutes once the model is set up correctly. A well-structured SaaS financial model template is what makes that 20-minute refresh possible; without input/output separation baked into the structure, every refresh becomes a rebuild.

Ignoring cross-variable dependencies

Variables interact. Lower MRR growth does not just reduce revenue - it slows CAC payback, reduces hiring capacity, and tightens margin. A scenario model that moves one variable at a time misses the compounding effect of correlated inputs.

Fix: When you build your bear case, move all the correlated inputs together. If churn goes up, model the CS team response cost. If MRR growth slows, model the hiring delay. Scenarios should represent coherent futures, not isolated sensitivity tests.

a16z's framework for efficient SaaS growth under pressure makes the same point: the businesses that navigate downturns best are the ones that model correlated inputs - not just individual metrics - and adjust spending and hiring in response to the whole picture, not one number.

Building more than three scenarios

Four or five scenarios create analysis paralysis. Decision-makers start averaging them and end up back where they started - one implicit number.

Fix: Cap at three named scenarios. Run sensitivity analysis for the nuance. The scenarios give you the structure; the sensitivity analysis gives you the prioritization.

A scenario planning checklist you can use this week

Use this to audit your current forecasting and identify gaps before your next board update or fundraise.

Model structure

• Three distinct scenarios exist: bear, base, bull
• Each scenario has a clearly named set of five or more input assumptions
• Inputs are separated from outputs in the model (no hard-coded numbers in formula cells)
• Runway is calculated separately for each scenario

Assumptions ownership

• Every key input has a named owner from the leadership team
• Input owners have committed to a monthly review of their assumptions
• The base case assumptions have been socialized with the board and are documented

Trigger-response protocol

• Specific triggers are defined for moving from base to bear (at least two)
• Pre-agreed responses for each trigger are documented and leadership-approved
• Runway threshold for initiating fundraise process is defined and written down

Sensitivity analysis

• You have tested each key input in isolation (10% change, all others held constant)
• You know which variable has the largest runway impact
• Management priority is aligned to the top one or two sensitivity drivers

Cadence

• Scenario model is refreshed monthly (input cells updated, not rebuilt)
• Actuals vs. base case comparison is reviewed in monthly leadership meeting
• Scenario update is included in every board update, not just fundraise decks

Conclusion

Scenario planning is not a finance exercise. It is a leadership exercise that happens to use a financial model.

The companies that get the most from scenario planning are not the ones with the most sophisticated models. They are the ones where the CEO can say, from memory, what the three trigger conditions are that would shift their current operating mode - and what happens next when one of those conditions fires.

If your current plan is a single number, the first step is not to build a more complex model. It is to name the five assumptions that drive the most runway impact, assign an owner to each one, and agree on a response protocol before you need it.

That is what converts scenario planning from a presentation tool into a management tool.

If you want a working session to pressure-test your current scenarios or build this structure from scratch, Fiscallion works directly with founding teams on exactly this. Book a working session and bring your current model - we will identify the three changes that would make it decision-grade.