You need a steering committee to fund a quarter of platform hardening instead of two customer features. How do you put technical risk and feature risk side by side so an executive can choose?

Short answer

Express both in the same currency, which is expected cost to the business over a stated horizon, and show the arithmetic from assumptions the room can argue with. Give the committee a real choice with a decision date rather than a single option and a plea.

One currency, or there is no comparison

An executive comparing "two features customers asked for" with "hardening the ingestion pipeline" is not comparing anything; the two are stated in incompatible units and the familiar one wins by default. The whole task is putting both in the same currency, and the only currency that works at that table is expected cost to the business over a stated period. Everything else — story points, technical elegance, engineering discomfort, a maturity score — is an internal measure that a steering committee cannot trade against revenue.

That reframe also changes who is deciding what. Once both sides are expressed as expected cost with visible assumptions, the committee is doing the job it is actually equipped for, which is judging the inputs. They know better than you what a week of outage does to the enterprise renewal conversation. You know better than they do how likely the outage is. Splitting the estimate along that line is what makes the meeting productive rather than adversarial.

Show the arithmetic, not the conclusion

The comparison has to be carried through in front of them, from assumptions they are invited to attack. A number asserted at a steering committee gets disbelieved; a number derived from four stated inputs gets argued about, and an argument about inputs is a decision being made.

Option A - fund two features this quarter
  Incremental ARR if both land            600,000 per year   (sales estimate)
  Probability both land in the quarter    0.7                (our own history)
  Expected first-year gain                420,000

  Ingestion pipeline left as is
  Probability of a saturation incident
  in the next four quarters               0.4                (see basis below)
  Cost of that incident                   350,000            (see basis below)
  Expected cost carried                   140,000

  Net expected position                   +280,000

Option B - fund hardening this quarter
  Two features slip one quarter, not lost
  Delay cost, one quarter of ARR          150,000
  Probability of saturation incident
  after hardening                         0.05
  Expected cost carried                   17,500

  Net expected position                   -167,500 this quarter,
                                          and 122,500 of avoided
                                          expected loss carried forward

Basis for 0.4: peak throughput is at 62 percent of the measured
  ceiling and has grown 9 percent a quarter for five quarters;
  at that rate the ceiling is reached inside four quarters.
Basis for 350,000: the March incident cost 210,000 in credits and
  eleven engineer-weeks; saturation degrades all tenants, not one
  region, so the credit exposure is larger.

Two things about that block matter more than its totals. Every number is either sourced from something the room already believes — a sales estimate, a real prior incident, a measured utilisation figure — or explicitly labelled as an assumption. And the delay cost of the features is a delay, not a loss, which is the honest framing and the one that most often turns the decision. Candidates who present the features as forgone forever are overstating their own case and will be caught.

If you cannot produce a probability at all, say so and switch to a threshold instead: "we do not know the likelihood, but throughput is at 62 percent of ceiling and growing 9 percent a quarter, so the decision cannot be deferred past two quarters without deciding by default". Deciding by default is the phrase that lands, because it is the thing an executive most wants to avoid being told afterwards.

Give them a genuine choice, including the one you are not recommending

A recommendation with no alternative reads as advocacy and invites the committee to look for the option you left out. Three lines is usually enough.

Option	Cost this quarter	Risk carried	When this is the right call
Features only	None to roadmap	Full saturation exposure for four quarters	If the renewal genuinely turns on these two features
Hardening only	Both features slip a quarter	Near-eliminated	If a multi-tenant outage would break a reference customer
Split: one feature, throughput ceiling raised	One feature slips	Halved, ceiling revisited in two quarters	Recommended; buys a quarter of evidence without stopping the roadmap

The split option is worth constructing deliberately rather than offering as a compromise. Most hardening work has a part that removes the near-term cliff and a part that is genuinely architectural improvement, and separating them lets you take the cliff off the table for a fraction of the quarter. A TPM who arrives with only all-or-nothing has not done the decomposition.

Say what would change your mind, and when it gets reviewed

Close by naming the evidence that would flip the recommendation and the date it next gets looked at. "If throughput growth drops below four percent a quarter for two quarters, the hardening can wait and I will say so" does more for your standing than any part of the argument, because it tells the room the analysis is a mechanism rather than a position. It also protects you in the case where they fund the features and nothing breaks: you will have said in advance what the risk was and what would have retired it, so the outcome does not read as your having cried wolf.

The failure this question is designed to expose

The trap here is arguing in engineering currency to a business audience — reliability, coupling, maintainability, a debt score — and mistaking the committee's blank response for short-termism. It is not short-termism. Those words describe a cost the room cannot price, and an unpriced cost loses to a priced benefit every time, entirely rationally. The corollary is uncomfortable and worth saying in the interview: if you cannot express the technical risk as a cost with a probability and a horizon, you have not finished the analysis, and the committee is right to defer.

Technical risk loses to feature value not because executives discount it but because it usually arrives without a price attached.

---

© 2026 Preptima. Originally published at preptima.com.