How would you justify a six-week reliability investment to a commercial stakeholder?

What is being tested

Whether you can argue in the organisation's currency rather than in engineering terms.

What does not work

"Our error rate is 0.4% and should be 0.1%." True, and unfalsifiable from the commercial stakeholder's position. It competes with a feature that has a named customer waiting, and it loses.

The argument that works

Construct the chain from the technical measure to the business one, and state the assumption.

"We currently fail about 4,000 checkout attempts a month. Roughly 30% of those customers do not return within the session, based on our own funnel data. At an average order value of £28 that is approximately £34,000 a month. Six weeks of work addresses the two causes responsible for most of them. The assumption is that the historical return rate holds, which we will verify by measuring recovery rate after the change."

Four properties make that work: a number the business already tracks, a causal chain that is stated rather than implied, an assumption named openly, and a validation method.

Claiming precision you do not have is what gets an estimate disbelieved. Stating the assumption is what makes it credible.

The supporting arguments

Cost of inaction, with a trend. "Incident volume in this area has risen 40% over two quarters and consumed 22 engineering days last quarter." A trend line is far more persuasive than a snapshot.

Cost avoidance, which is easier to defend than revenue attribution: engineering time currently spent on incidents, support contacts, refunds and credits.

Risk, where the exposure is genuine: a regulatory obligation, a contractual availability commitment with penalties, a dependency approaching end of support.

Options with costs, not a single proposal. "Six weeks addresses both causes. Three weeks addresses the larger one and captures roughly 70% of the benefit." Commercial stakeholders make trade-offs for a living; give them one to make.

The framing that helps most

Express the outcome as capability, not as tidiness: "afterwards we can run promotional campaigns without a change freeze" is a roadmap enabler the stakeholder may already want.

What a strong answer adds

That the instrumentation must exist first. If checkout failures are not measured in near real time and segmented by platform and region, none of this argument is available — and building that measurement is itself an architectural responsibility, decided long before anyone asks for the dashboard.