The platform migration has no user-visible benefit. How do you rank it against features customers are asking for?

Refuse the framing before you answer it

The question contains a trap in its premise: that platform work is a different kind of thing which has to be argued for on faith. Accept that framing and you are permanently in the weaker position, pleading for an allowance against work with a visible number attached. The migration does have user-visible benefit, just delayed and probabilistic, and your job is to express it in the same units as everything else on the list so it can lose fairly or win fairly.

Two costs need separating, because they behave differently and stakeholders conflate them constantly. The one-off cost is what the migration takes to complete. The carrying cost is what you pay every month you have not done it, and it is the number that makes the case. If you present only the one-off cost you have described a large expense with no return, which is exactly how these proposals get declined for three consecutive quarters and then become an emergency.

Pricing the carrying cost

Make the carrying cost concrete with a small number of stated assumptions, out loud, so each one can be challenged. Suppose the migration is off a bespoke job scheduler onto a managed queue, and the team is eight engineers.

Assume, from the last two quarters of incidents, that the scheduler causes two production incidents a month averaging four engineer-hours of response each, so eight hours. Assume every feature touching background work — roughly a third of the team's stories — carries about a day of extra integration effort, and the team ships some thirty stories a quarter, so ten of them, giving 10 days a quarter, or about 27 hours a month. Assume one engineer spends a day a month on manual reconciliation the managed queue would not need, another 8 hours. That totals roughly 43 engineer-hours a month, call it a quarter of one engineer, or about 3 per cent of an eight-person team's capacity.

Now the second half of the calculation, which most candidates skip. A quarter of an engineer is not a compelling number, so if that is all the migration buys, it is genuinely a poor investment and you should say so. The case has to rest on something else, and usually does: a growth curve that makes the carrying cost non-linear, a capability that is blocked outright, or a date you do not control.

Cost type	Assumption	Monthly cost
Incident response	2 incidents, 4 engineer-hours each	8 hours
Integration tax on features	10 extra engineer-days per quarter	~27 hours
Manual reconciliation	1 engineer-day per month	8 hours
Blocked capability	Scheduled sends cannot be sold	Deal-level, not hours

That last row is the one that changes decisions. If two enterprise deals this year require a capability the current scheduler cannot support, the migration is not maintenance, it is the prerequisite for a revenue line, and it should be ranked as that revenue line's first phase rather than as debt. Similarly, if the underlying dependency has an announced end of support, the migration has a hard date and belongs in the ring-fenced constraint bucket, not in the scored discretionary pile. Establish which of these is true before you argue anything, and be honest when none of them is, because a migration with no date, no blocked capability and a 3 per cent carrying cost should probably be done incrementally inside feature work rather than as a programme.

Making the comparison legible

Once the migration has a monthly cost and, where applicable, a date, rank it on whatever model the roadmap already uses. The useful lens is cost of delay against duration: for each candidate, what does it cost per month of not having it, and how long does it take. The migration typically has a modest but permanent and compounding cost of delay, while a feature often has a large but decaying one, because a competitor's launch or a renewal cycle passes. That asymmetry is worth stating plainly, since it explains the standard failure — features always win the current quarter on the strength of an urgency that will expire, and the migration's cost keeps accruing in every quarter it loses.

The practical resolution is rarely all-or-nothing. Ask engineering for the smallest slice that stops the bleeding rather than the whole programme: migrating the two highest-incident job types might remove most of the incident cost for a fifth of the effort, which turns an unwinnable eighteen-month ask into a scoped six-week one that competes on ordinary terms. A PM who arrives with a descoped migration is far more persuasive than one who arrives defending the full version, and it is the same discipline you apply to features, which is the point.

Where credit is won and lost

Weak answers pick a side. The interviewer is not looking for "platform work first" or "customers first"; they are looking for whether you can make an invisible cost visible without inflating it. Two specific things earn credit. The first is volunteering the case where the migration should lose, because a candidate who can only argue one direction is not doing analysis. The second is committing to a standing allocation and defending the number, so that this argument is not relitigated from zero every quarter — say 20 per cent of capacity, and be clear that the number does not come from the carrying cost. Three per cent would fund a quarter of an engineer, which pays the interest and never repays anything. Twenty per cent is the smallest allocation that lets a pair finish a scoped platform slice inside a single quarter while the feature line keeps moving, which is what makes the work land rather than perpetually half-land, and it is reviewable if incident volume moves.

The credibility gap underneath all of it is the real trap. If the last two platform investments delivered nothing observable, no amount of arithmetic will carry the third, and the real work is instrumenting the outcome — incident count, cycle time on affected stories — before you start, so the next request has evidence rather than a fresh model.

Invisible work does not need special pleading, it needs a carrying cost, a smallest useful slice, and an honest account of the case in which it should lose.