What-If Analysis at Scale: How Aerospace, PE, and Deep Tech Analysts Handle Uncertainty

What "What-If Analysis" Actually Means at the Professional Level

The term gets used loosely. At the spreadsheet level, what-if analysis means plugging different inputs into a formula and observing the output. Goal Seek, data tables, Excel's Scenario Manager — these are the beginner-level tools, and they work fine for simple questions.

But serious what-if analysis is a different discipline entirely. It has four characteristics that distinguish it from the amateur version:

1. Structural coherence: Every scenario must use the same model logic. You are not comparing different models — you are comparing different inputs to the same model.
2. Traceable assumptions: For any output difference between two scenarios, you must be able to identify the exact assumption that drove it and by how much.
3. Governed inheritance: Most inputs should be shared across scenarios. A scenario is a deviation from a base case, not a new model from scratch.
4. Versioned history: The model must capture not just "what are the scenarios now" but "what were they last Tuesday, and who changed what."

When all four are present, what-if analysis becomes a decision-making instrument. When any one is absent, it becomes a source of errors that look like analysis but aren't.

How Aerospace Analysts Run What-If Analysis

Aerospace is the domain where what-if analysis is most structurally demanding. The decisions are enormous — a commercial aircraft program costs $10–20 billion to develop; a satellite constellation can run higher — and they play out over decades. A 1% cost overrun on a 20-year program is not a rounding error.

The make-or-buy decision

One of the most common scenario exercises in aerospace is the make-or-buy analysis. Should the prime contractor build a subsystem in-house, or source it from a supplier? The answer depends on a tangle of variables: internal production volume, learning curve steepness, supplier quote stability, NRE (non-recurring engineering) amortization, long-term program assumptions, and strategic positioning.

A responsible make-or-buy model will run at minimum three top-level scenarios — make, buy, and a hybrid — and then a full sensitivity sweep within each. How sensitive is the make case to learning-curve rate? If the curve is 85% rather than 90%, does the answer flip? What if the supplier's unit price escalates 4% per year instead of the contracted 2%? These are not academic questions. They are the actual inputs that determine which option gets approved.

Launch vehicle economics

In the commercial launch market, what-if analysis directly determines whether a program exists at all. The economics of a launch vehicle are highly sensitive to launch cadence: a rocket that flies twice a year has a very different unit cost structure than one that flies twenty times a year. Fixed costs — the engineering team, the launch infrastructure, the certification overhead — spread across far fewer revenue events.

This makes cadence the master assumption. SpaceX's ability to reuse Falcon 9 boosters, for example, transformed what was a manufacturing cost problem into a turnaround operations problem. Their financial models almost certainly ran hundreds of what-if iterations on reflights-per-booster, refurbishment cost per flight, and market price elasticity before the program committed to full reusability as the core economic strategy.

Companies like Rocket Lab, Relativity Space, and Firefly face similar modeling challenges: how many launches per year does the market support at what price, and how does the unit economics trajectory change if cadence ramps faster or slower than projected? Each of those is a branching scenario with its own assumption set.

Program of record vs. commercial split

Defense primes like Lockheed Martin, Northrop Grumman, and Boeing GD run a particularly complex version of this: how does a platform's economics change based on the government/commercial revenue split? A platform that carries 80% government program-of-record revenue has different risk characteristics — and a different financing model — than one tilted toward commercial contracts. Running what-if analysis across that split, while holding program costs and LRIP (low-rate initial production) pricing fixed, is standard practice before any major bid or capital commitment.

How Private Equity Analysts Run What-If Analysis

PE what-if analysis has different characteristics than aerospace. The time horizon is shorter (3–7 years vs. 20+), the decisions are binary (buy or don't buy; sell now or hold), and the audience — the investment committee — demands clarity on downside scenarios above all else.

The three-scenario minimum

Every LBO model worth presenting to an IC has at minimum three scenarios: management case, base case, and downside. In practice, serious shops add more: an upside case (useful for framing return potential), an entry multiple sensitivity (what if we pay 1x more than the bid?), and often a "covenant stress" case specifically designed to show when leverage ratios breach debt covenants.

The discipline here is important: each scenario must flow through the same model structure. Revenue growth assumptions and margin assumptions drive EBITDA, which drives free cash flow, which determines debt paydown and exit enterprise value at the assumed multiple. If you run the bear case on a different model than the bull case, you have not done scenario analysis — you have done two separate forecasts and called them scenarios.

Sensitivity tables: the PE analyst's bread and butter

The 2D sensitivity table — IRR or MOIC as a function of entry multiple and exit multiple, for example — is the most common output of PE what-if analysis, and for good reason. It immediately answers the investment committee's real question: "What does the return look like if we pay too much and sell into a bad market?"

A well-constructed LBO might carry 5–6 such tables at the back of the IC memo: entry/exit multiple, revenue growth/margin expansion, revenue growth/exit multiple, hold period vs. exit multiple, and so on. Building all of those cleanly in a model without copy-sheet chaos is harder than it sounds — each table is implicitly a separate scenario space.

Add-on acquisition scenarios

Platform buy-and-build strategies add another layer. Each potential add-on acquisition is its own what-if: what does the combined entity look like if we close this acquisition in year 2 vs. year 3? What if synergies are 50% of projected? What if the acquired company's EBITDA comes in 20% below LOI representations? Top PE shops model these add-on scenarios as branches off the standalone model — they share the platform's structure and add layers on top — rather than as entirely separate files.

Firms like KKR, Apollo, and Blackstone manage portfolios with dozens of active deals, each with their own scenario tree. The analysts running those models deal with version control and scenario inheritance as daily operational problems, not occasional annoyances.

How Deep Tech and Infrastructure Analysts Run What-If Analysis

Startups and growth companies building capital-intensive products — advanced manufacturing, grid infrastructure, nuclear, autonomous systems — sit in an interesting middle ground. They have the long time horizons and high capital intensity of aerospace, combined with the investor-audience pressure and exit orientation of PE.

The fundraising scenario stack

For a growth-stage deep tech company, the financial model is almost always built as a scenario stack: Series B plan, Series C plan, capital-constrained plan, and "what if we get a strategic partnership from a major OEM" plan. Each scenario changes the revenue trajectory, the capex timing, the headcount ramp, and the path to unit economics.

The challenge is that these scenarios evolve constantly as new information arrives. A contract award changes the revenue scenario. A manufacturing delay shifts the capex schedule. A new competitor entering the market changes the price assumption. Maintaining a coherent scenario library under continuous revision — without losing track of what changed and why — is the central modeling problem for this type of company.

The unit economics inflection model

For companies where unit economics improve with volume (learning curves, factory utilization, supplier pricing power), the what-if question is often: "At what production volume do we cross the line into healthy unit economics, and how sensitive is that crossover to cost inputs?" This requires modeling the production ramp as a variable, running multiple ramp scenarios, and sweeping the key cost assumptions within each.

A company like a battery manufacturer or a satellite broadband provider might run dozens of these scenarios: fast ramp vs. slow ramp, high ASP vs. price-competitive ASP, raw material cost scenarios indexed to commodity prices. The scenario library becomes a living document that the CFO and board review quarterly.

The Three Problems Every Serious What-If Analyst Hits

Across aerospace, private equity, and deep tech — despite the very different decisions and time horizons — serious what-if practitioners run into the same three structural problems.

1. Version drift

The model was right on Monday. By Thursday, four people have touched it. By the following Monday, there are three versions in the shared folder with names like LBO_Model_v7_JM_FINAL.xlsx, LBO_Model_v7_JM_FINAL_KL.xlsx, and LBO_Model_USE_THIS_JUNE9.xlsx. No one is certain which scenarios in each version are current. The IC memo is due in two days.

Version drift is the single most common source of what-if analysis errors. The model logic diverges across files, and a change to the base case in one file does not propagate to the scenario files. Scenarios that were built to share a structure gradually diverge until they are effectively different models — which means their comparison is no longer meaningful.

2. Assumption opacity

Two scenarios show a $35M difference in 5-year NPV. The question everyone in the room is asking: "What's driving that?" If the model is structured well, the analyst can answer immediately: "It's almost entirely the exit multiple assumption — bear is at 7x, base is at 8.5x, and the company has $200M of EBITDA by year 5, so that 1.5x difference accounts for $300M of enterprise value, which flows through to equity value at our leverage ratio." That is a useful answer.

If the model is not well-structured, the answer is "let me pull that up" followed by ten minutes of cell-tracing. Assumption opacity is a signal that the what-if analysis is not doing the job it is supposed to do: turning uncertainty into navigable decision space.

3. Stale scenario inheritance

The bear case was built three months ago as a variation off the base case. The base case has since been updated six times. The bear case has not been updated consistently with those changes — it still uses the old revenue model, the old headcount assumptions, and a margin structure that was revised after a board meeting in April. It is no longer a valid bear case; it is a snapshot of an old model with some inputs changed.

This is the inheritance problem. Scenarios need to inherit from a living base case, not from a frozen copy of it. Every time the base case is updated, all scenarios should automatically receive the update everywhere they don't explicitly override it. This is easy to state and very hard to implement in a conventional copy-paste spreadsheet.

How Serious Analysts Solve These Problems

Centralized assumption control

The first response most experienced modelers reach for is a dedicated assumption sheet — a single tab where every input lives, and every formula in the model references that tab. No hardcoded numbers anywhere in the calculation logic. This alone eliminates a large class of version drift errors, because at least all the assumptions are in one place.

The limitation is that this still doesn't handle scenarios well. A model with a centralized assumption sheet can have one set of inputs active at a time. To run scenarios, you either use a scenario selector (a dropdown that swaps out assumption sets via INDEX/MATCH or named range tricks) or you duplicate the assumption sheet for each scenario. Both approaches have failure modes.

Named scenario architecture

Sophisticated modelers build what amounts to a scenario database: a structured range where each row is an assumption and each column is a scenario. A master switch at the top of the model selects which column's values feed the calculation engine. This is the most robust Excel-native approach and is common in well-built PE and infrastructure models.

It works until you need more than a handful of scenarios, or until the model needs restructuring. At that point, adding a new assumption means adding a new row to the database and populating values for every existing scenario — which can involve 15–20 cells per addition. The maintenance burden grows with every new assumption.

Sensitivity sweeps as a substitute for scenario proliferation

One of the smartest tactical moves in what-if analysis is to replace a proliferating set of discrete scenarios with a parameterized sensitivity sweep. Instead of "bull case, base case, bear case, stress case," you build one model and run a sweep of the three or four load-bearing assumptions across their plausible ranges. The output is a matrix of outcomes — all internally consistent, all built from the same model logic — that shows the full possibility space rather than a few cherry-picked points within it.

A tornado chart is the standard visualization: each assumption is a horizontal bar showing how much the output (IRR, NPV, unit cost) moves when the assumption varies across its range. The longest bars identify the assumptions that matter most. That immediately focuses the due diligence, the negotiating attention, and the operational monitoring on the right inputs.

The practical limitation: a 5-variable sensitivity sweep produces a 5-dimensional output space that is difficult to slice and present. In practice, most analysts run 2D sweeps (the standard data table), generate several of them across different axis pairs, and manually collate. It works, but it is tedious.

Branching: the structural solution

The cleanest conceptual solution to the inheritance problem is what version control systems solved for code: branching. A scenario is a branch off the base case that inherits everything by default and overrides only the specific assumptions it differs on. When the base case is updated, all branches receive the update automatically everywhere they haven't explicitly overridden it.

This eliminates the stale inheritance problem structurally. The bear case never drifts away from the current base case model logic; it only differs where the bear case explicitly says "use 6x exit multiple instead of the base case's 8.5x." Every other input — the revenue model, the cost structure, the capex schedule, the leverage assumptions — flows through from the base case automatically.

It also eliminates assumption opacity. If two branches show different NPVs, the system can diff them: show exactly which inputs are overridden in each branch and by how much. The answer to "what's driving the $35M difference" is computed automatically, not traced manually.

What Most Analysts Actually Do (And Why It's Costly)

Despite knowing the right architecture, most analysts use copy-paste scenarios. The reason is pragmatic: the branching architecture described above requires either a purpose-built tool or an extremely disciplined manual implementation that is difficult to maintain as the team changes.

The cost of copy-paste what-if analysis is not zero, but it tends to be diffuse and hard to measure. An incorrect scenario comparison that gets presented to a board, and that influences a decision, may never be traced back to the model structure that enabled the error. The deal closes on assumptions that were slightly wrong in the analysis, and the cause is invisible.

The more measurable cost is analyst time. A Goldman Sachs banking analyst or a Bain portfolio company FP&A lead spends a meaningful fraction of their modeling time not on the analysis itself, but on the maintenance overhead of managing scenario files: reconciling versions, updating all scenarios when the base case changes, checking that the bear case still shares the same revenue model as the base case. This is administrative work masquerading as analysis.

One CFO at a Series C infrastructure company described it to us as "the tax we pay for not solving the version control problem." His team of three finance people spent roughly two days per quarter reconciling scenario files — not because they were bad at their jobs, but because the tools didn't give them a better option.

The Anatomy of a Well-Structured What-If Model

Whether you are building an aerospace cost model or an LBO or a SaaS unit economics spreadsheet, a well-structured what-if model has the same core components:

Component	Purpose	Common failure mode
Base case / master assumptions	The single source of truth for all inputs that are shared across scenarios	Scattered hardcodes across the model
Scenario override layer	Explicitly tracks which inputs differ in each scenario and by how much	Implicit overrides buried in calculation cells
Inheritance mechanism	Ensures each scenario uses base case values for every input it doesn't explicitly override	Manual copy-paste; inheritance breaks on base case updates
Diff capability	Ability to compare any two scenarios and see only what differs between them	Manually eyeballing two files side-by-side
Sensitivity sweep layer	Parameterized range sweeps within each scenario	Hand-built data tables rebuilt for each model update
Version history	Auditable record of what changed, when, and what the impact was	File system timestamps and email chains

Most spreadsheets in the wild have the first component (some form of base case) and fail on every other one. The models at the serious end of the profession have all six. The difference between those two extremes is the difference between a model that produces decisions and one that produces the appearance of analysis.

Practical Takeaways for Individual Analysts

You do not need to be running SpaceX launch economics or a $2B LBO to benefit from this structural discipline. The same principles apply to any model where:

• You have more than two or three scenarios that need to stay in sync
• The base case is expected to change as new information arrives
• You need to explain to someone else what is driving a difference between scenarios
• The model will be used by more than one person over its lifespan

Start with a named assumption sheet, no exceptions

The minimum viable upgrade to any what-if model is moving all inputs to a dedicated assumption sheet. Every formula in your calculation engine should reference a named cell or named range from that sheet. No hardcodes in calculation cells. This alone is worth the twenty minutes it takes to implement on an existing model.

Define scenarios as overrides, not copies

When you build a new scenario, do not duplicate the entire model. Instead, build a scenario block — a set of cells that lists which inputs differ from the base case and by how much. Use a scenario selector to swap between active scenarios. Even the manual version of this discipline prevents the worst version drift failures.

Build diff into the presentation layer

The most useful output of a what-if analysis is not the scenarios themselves — it is the explanation of what drives the differences between them. Build a "bridge" exhibit: start with scenario A's output, add each assumption difference as a bar, and arrive at scenario B's output. This forces the model to be explicit about what matters, and it is the exhibit that actually drives the decision.

Treat the scenario library as a living document

Scenarios go stale. The bear case from six months ago may no longer be the relevant downside — new information has arrived, the base case has changed, and the bear case needs to be updated to reflect current thinking. Build a review cadence into how you use the model: every time the base case is significantly updated, audit each scenario to confirm it is still a meaningful variant.

Frequently Asked Questions