Real Options Thinking for Technology Investment Decisions
Fixed ROI models break down when applied to AI pilots and platform rebuilds, because they demand precision at the point of maximum uncertainty. This article sets out a real options framework that lets CTOs and CFOs approve staged technology investment without a single, unreliable upfront ROI number.

Boards ask a predictable question before approving technology spend: what's the ROI? For a new payment gateway or a straightforward infrastructure upgrade, that question is answerable. For an AI pilot, a platform rebuild, or a multi-year modernisation program, it often isn't — not honestly. Real options thinking gives CTOs and CFOs a way to approve staged investment under genuine uncertainty, without forcing a single upfront number that nobody can defend.
What is real options thinking in technology investment?
Real options thinking is a decision framework, borrowed from financial options theory, that treats a technology investment as a series of staged choices rather than one irreversible commitment. Instead of asking "will this project deliver X return?", it asks "what do we learn at each stage, and does that learning justify the next increment of spend?" Each stage buys the right, but not the obligation, to continue.
This matters because most consequential technology decisions — modernising a legacy core system, piloting an AI capability, rebuilding a platform — carry uncertainty that a single net-present-value calculation cannot capture. You don't yet know whether the model will generalise to production data, whether the legacy system's hidden dependencies will blow out the timeline, or whether customer behaviour will shift once the new platform ships. Real options thinking makes that uncertainty explicit and manageable instead of pretending it away with a confident-sounding spreadsheet.
Why do fixed ROI models fail for AI pilots and platform rebuilds?
Fixed ROI models fail because they demand precision at the point of maximum uncertainty — before any code has shipped or any model has touched production data. Forcing a five-year NPV on an AI pilot produces a number that is technically calculable and practically meaningless, because the inputs are guesses dressed up as forecasts.
This creates two bad outcomes. Boards either reject worthwhile exploratory work because the ROI case looks too soft to approve, or they approve an inflated business case built on numbers nobody believes, which erodes trust the first time the project misses its projected return. Neither outcome serves the organisation. An AI product strategy engagement should surface where genuine uncertainty exists early, rather than paper over it with a forecast that looks precise but isn't.
How does real options thinking work in practice?
In practice, real options thinking breaks a large technology commitment into smaller, sequenced decisions, each with a defined cost, a defined learning objective, and an explicit decision gate. You fund the next stage only once the previous stage answers a specific question — not on a fixed calendar, and not because the budget was already allocated.
A typical structure looks like this:
- Discovery option — a small, time-boxed investment to validate a hypothesis (technical feasibility, data quality, model performance) before committing further. This is where an AI readiness assessment or a technical architecture review typically sits.
- Pilot option — a scoped build against a narrow use case, with success criteria agreed before the work starts, not retrofitted afterward to justify the spend.
- Scale option — the decision to expand the pilot into a production-grade capability, informed by what the pilot actually demonstrated rather than what the original business case assumed.
- Platform option — broader architectural investment (decomposing a monolith, building shared data infrastructure) that the earlier stages have shown is worth the cost.
Each gate is a genuine decision point. Killing a project at stage two because the pilot didn't validate the hypothesis is not a failure of the framework — it's the framework working exactly as intended, because it avoided a much larger stage-four commitment on a flawed premise.
What does a staged investment structure look like compared to a fixed-commitment model?
A staged, options-based structure differs from a fixed-commitment model primarily in when capital is at risk and how success is defined. The table below compares the two approaches across the dimensions boards typically care about.
| Dimension | Fixed-commitment model | Real options model |
|---|---|---|
| Upfront decision | Full budget approved against a single ROI case | Small initial spend to fund discovery |
| Risk exposure | Capital at risk from day one | Capital at risk increases only as uncertainty decreases |
| Success measure | Predicted return vs actual return | Did the stage answer its defined question |
| Board involvement | One large approval, then status updates | Multiple smaller approvals at defined gates |
| Response to bad news | Sunk cost pressure to continue | Clean exit point built into the plan |
| Best suited to | Well-understood, low-uncertainty projects | AI pilots, platform rebuilds, modernisation programs |
Neither model is universally superior. A well-understood infrastructure refresh with known costs and known outcomes doesn't need an options framework — a fixed business case is faster and perfectly defensible. The framework earns its keep specifically where technical or market uncertainty is high, which is exactly where AI initiatives, application modernisation programs, and greenfield data infrastructure builds tend to sit.
How should CTOs present staged investment options to the board?
CTOs should present staged options by naming the uncertainty explicitly, attaching a dollar figure and a timeframe to each stage, and defining upfront what evidence would justify — or not justify — proceeding to the next one. This reframes the board's role from approving a five-year forecast to governing a sequence of smaller, well-defined decisions.

In practice this means bringing the board three things at each request: the specific question this stage of spend will answer, the cost and duration to answer it, and the decision criteria for what happens next regardless of the answer. A board that understands it is approving a $40,000, four-week discovery phase — not a $2 million platform rebuild — can say yes to exploratory work far more readily than one being asked to bless a speculative five-year NPV. CFOs benefit too: staged options are easier to model for cash flow and risk exposure than a single large commitment with uncertain timing.
What are the risks of applying real options thinking poorly?
The main risk is treating the framework as a way to avoid accountability rather than a way to structure it. Real options thinking only works if each gate has genuine decision criteria and genuine willingness to stop. If every pilot is quietly guaranteed to proceed to scale regardless of what it shows, the staged structure becomes theatre rather than governance.

A second risk is under-scoping the discovery and pilot stages so tightly that they can't actually answer the question they're meant to answer — for example, testing a language model on clean sample data when the real challenge is production data quality. This is a common failure mode in early AI work, and it's one reason organisations bring in outside AI engineering expertise for the pilot stage: to make sure the test is representative enough that a genuine no-go decision is possible, not just a foregone conclusion dressed up as validation.
Bringing real options thinking into your next technology decision
Real options thinking won't make every technology decision easy, and it isn't a substitute for sound engineering judgement. What it does is give CTOs and CFOs a shared, honest way to talk about investment under genuine uncertainty — replacing a single unreliable ROI figure with a sequence of smaller, evidence-based decisions the board can actually govern. For more on how staged decision-making applies to specific technology domains, browse our insights.
If you're weighing a staged approach to modernisation, an AI pilot, or a platform rebuild and want help structuring the decision gates, get in touch — we're happy to talk through what a sensible first stage would look like for your situation.
Chris Kerr
Partner at Horizon Labs, an AI product consultancy and venture studio. A commercially focused product and technology leader with 20+ years building and scaling digital platforms, teams, and businesses across SaaS, travel, eCommerce, logistics and transport, and digital marketing — operating at the intersection of product, engineering, and data. Writes about platform strategy, AI transformation, modern data ecosystems, and the operational discipline that separates AI demos from AI products.


