Business Acumen and Commercial Context Questions

Direct answer

99.99% availability allows 52.6 minutes of downtime a year; 99.95% allows 262.8. The gap is 210.2 minutes a year. In the example below, that gap is worth about $84,000 a year in directly lost revenue (on $200 million of online revenue, assuming outages fall in busier hours and block 70% of sales, as set out in the calculation below), against an illustrative $1.2 million a year to close it, so the revenue case alone does not support 99.99%. I would find out what the CEO's target is protecting (contracts, reputation, a competitor claim), price that, and propose a tiered commitment: 99.95% across the board now, 99.99% only for the revenue-critical path, funded when the evidence of what is at stake clears break-even (the point where the benefit equals the cost).

Quantify the gap

Availability is the share of time the service works for customers; an SLO (service-level objective) is the internal target for it, and an SLA (service-level agreement) is a contractual promise with penalties.

MIN_PER_YEAR = 365 * 24 * 60
for target in (0.9999, 0.9995):
    print(f"{target:.2%} allows {MIN_PER_YEAR * (1 - target):6.1f} minutes of downtime a year")
gap_minutes = MIN_PER_YEAR * (0.9999 - 0.9995)
print(f"gap: {gap_minutes:.1f} minutes a year")

REVENUE = 200_000_000
per_minute = REVENUE / MIN_PER_YEAR
loss_per_minute = per_minute * 1.5 * 0.7      # peak factor 1.5, 70% of flows blocked
print(f"revenue lost per outage minute: ${loss_per_minute:,.0f}; direct value of closing the gap: ${gap_minutes * loss_per_minute:,.0f} a year")

INVESTMENT = 1_200_000                         # illustrative yearly cost of the extra resilience
print(f"break-even needs other benefits of ${INVESTMENT - gap_minutes * loss_per_minute:,.0f} a year")

# availability of a chain multiplies
print(f"app 99.99% x database 99.95% = {0.9999 * 0.9995:.4%}")
print(f"three 99.99% dependencies in series = {0.9999 ** 3:.4%}")

# Option B: 99.99% on the checkout path only (assume checkout carries 60% of revenue at risk)
checkout_value = gap_minutes * loss_per_minute * 0.6
print(f"checkout-only direct value: ${checkout_value:,.0f} a year against an illustrative $350,000 a year")

Output:

99.99% allows   52.6 minutes of downtime a year
99.95% allows  262.8 minutes of downtime a year
gap: 210.2 minutes a year
revenue lost per outage minute: $400; direct value of closing the gap: $84,000 a year
break-even needs other benefits of $1,116,000 a year
app 99.99% x database 99.95% = 99.9400%
three 99.99% dependencies in series = 99.9700%
checkout-only direct value: $50,400 a year against an illustrative $350,000 a year

Reading the output:

• 99.99% leaves 52.6 minutes a year; 99.95% leaves 262.8, so the gap is 210.2 minutes.
• With $200 million of online revenue, a peak factor of 1.5 and 70% of flows blocked, each outage minute loses $400 and the gap is worth $84,000 a year directly.
• If closing the gap costs an illustrative $1,200,000 a year, other benefits of $1,116,000 a year would be needed to break even.
• Availability of components in series multiplies: an app at 99.99% on a database at 99.95% delivers 99.94%, and three 99.99% dependencies in series give 99.97%. A 99.99% target therefore requires every dependency in the chain to be at least that good, which is where much of the cost comes from.

Counting what the direct number omits

The $84,000 is a floor. Add, with real numbers from your business: SLA credits owed under enterprise contracts that promise 99.99%, annual recurring revenue (ARR, the yearly subscription revenue a customer contract brings in) at risk of non-renewal if the promise is missed (ARR at risk x probability of loss; for example a $2,000,000 contract with a 15% chance of leaving after a breach is $300,000 a year of expected loss), brand and sales impact, and the engineering cost of the on-call and failover work. Express it as the break-even test above: the investment is justified when these other benefits exceed $1,116,000 a year in the example.

Negotiating target and investment

In the room, it sounds like this. You: "What is the 99.99% for: a contract, a board statement, or a competitor?" CEO: "A customer asked for it." You: "Then I want to price that. Moving from 99.95% to 99.99% saves about 210 minutes of downtime a year, worth about $84,000 in direct sales, and it costs about $1.2 million a year. It only pays if there is a contract at stake. How much revenue rides on the customer who asked, and what do they do if we say 99.95%?" Then show the options below and ask for a decision on option B.

1. Ask what the number is for. A contract clause, a board statement, a competitor's claim and a feeling all imply different answers.
2. Show the options in minutes and dollars.

3. Recommend B-with-conditions. Commit to 99.95% across the product now. Start the checkout-path design and a firm cost estimate now (weeks of planning, not the $350,000), and release the $350,000 when the exposure test passes: B's direct value is $50,400 against $350,000, so it needs about $299,600 a year of other benefits. One enterprise contract of $2,000,000 ARR with a 15% chance of leaving after a breach is $300,000 a year, which is enough. If the real driver is a contract worth millions of ARR, B and even C pass the break-even test and I would say so.
4. Explain what 99.99% demands. One 60-minute outage uses more than the whole year's budget, so recovery must be automatic, not a human paging at 3 a.m. That means health-checked failover (automated probes detect a failing server and traffic switches to a standby copy) with the service running in several zones (separate data centres in one city) or regions (separate geographic areas), so one site failing does not take the service down.
5. Measure from the customer's view and agree an error-budget policy. The error budget is the allowed downtime; when it is spent, feature work yields to reliability work. Review quarterly with real incident data.

Pitfalls

• Promising 99.99% in a contract before knowing the architecture can deliver it.
• Measuring availability at the server rather than from where users sit.
• Treating the minutes as evenly spread: a rare 4-hour outage is worse than many 2-minute blips for trust.

Direct answer

Lead with the customer and money, not the bug. Say: "We found a fault that is making some customers fail to pay us. Fixing it first takes about two weeks and moves the new feature by two weeks. Every week we leave it unfixed puts up to $24,000 of orders at risk, against about $15,000 a week of expected feature revenue, and the feature is only delayed, not lost. If many failed customers retry, the true loss is smaller, so I will measure the retry rate and confirm." Then give the new date, the cost of each option, and the one decision you need from them.

How to build the message

1. Translate the regression into a business symptom. A "reliability regression" means something that used to work got worse: slower pages, more errors, more downtime. Name the symptom the CEO already cares about: failed checkouts, support tickets, churn risk, a contract with an availability promise.
2. Put a number on the cost of leaving it. Use rates and money, not technical measures.
3. Put a number on the cost of the delay. Be honest that a delay is revenue deferred, not revenue destroyed, unless a launch window or a customer commitment makes it truly lost.
4. Offer a choice, with a recommendation. Two or three options, each with date, cost and risk, and your pick.
5. Say what you will report and when, so trust does not depend on the CEO understanding the fix.

Worked example (illustrative numbers)

A shop has 20,000 checkout attempts a week at an average order of $80. After last release, 1.5% of attempts fail with an error.

Some failed customers retry, so $24,000 is an upper bound; say so, and say you will measure the real retry rate. The comparison with the $15,000 a week the feature earns holds only if fewer than about 37.5% of failed checkouts are retried and completed (1 - 15,000 / 24,000 = 37.5%); above that, the fault costs less per week than the feature earns, and the case for fixing first rests on the risk growing and on the feature running on the same checkout. The script in the room:

"A change we shipped last month is making about 1 in 67 checkouts fail. That is roughly $24,000 of orders at risk every week. If we fix it first, the new feature lands two weeks later and about $30,000 of its revenue moves later in the year. If we ship the feature first, the checkout problem stays live and the risk keeps growing, and the feature itself runs on the same checkout. I recommend fixing first. I will send you the failed-checkout rate every Friday until it is back to normal."

(The 1 in 67 is 1 divided by 0.015.)

Trade-offs and pitfalls

• Jargon. Do not say "latency regression", "error budget" or "tech debt" to a CEO. Say "customers waiting", "failures", "money at risk".
• Do not hide the delay inside a vague date. Give a date with a confidence level ("two weeks, and I will confirm by Wednesday once we have traced the cause").
• Do not oversell the fix. If the cause is not yet known, say the range and when you will know.
• What changes the recommendation: if the feature is tied to a dated launch, a contract or a partner event that would be lost by a two-week slip, or if the regression only hits a small, low-value slice, the comparison changes. Say that you checked.

Direct answer

Reliability connects to revenue through a short chain: how often the service fails, how long customers are affected (the recovery time), how much revenue flows through the affected part during those minutes, how much of that comes back later, and what extra costs the outage triggers (service-level credits, support load). A longer recovery time multiplies the minutes of impact, so the lost-revenue part of the loss grows in proportion to it; the fixed per-incident costs do not grow, so in the example below tripling recovery time from 30 to 90 minutes raises the total cost per incident about 1.65 times ($17,753 to $29,260), not 3 times.

The chain, step by step

1. Frequency. Number of customer-visible incidents per year (6 in the example).
2. Duration. MTTR, mean time to recovery: the average time from the start of customer impact to restoration, so it includes the time taken to detect the problem as well as the time to fix it. In the example it moves from 30 to 90 minutes.
3. Revenue exposure per minute. Average revenue per minute (annual online revenue / minutes in the year), adjusted for when the outage happens (a peak factor of 1.5, an assumption that your incidents tend to land in busier-than-average hours; if outages struck at uniformly random times the factor would be 1.0, so take it from the hour of day of your own past incidents) and for the share of revenue the outage actually blocks (80%, for example because 20% of orders come through a path the outage does not touch, such as the mobile app on a separate service).
4. Recoverable share. Some customers retry later: here 30% of blocked purchases return.
5. Other costs. SLA credits (refunds promised in a service-level agreement), support tickets and engineer time: $12,000 per incident, illustrative and treated as fixed per incident here (in practice credits often grow with duration).
6. Total. Loss per minute x minutes + other costs, then x incidents per year.

Worked example

Annual online revenue is $120 million.

ANNUAL_ONLINE_REVENUE = 120_000_000
HOURS_PER_YEAR = 8760
PEAK_FACTOR = 1.5            # an outage hits busier-than-average hours
SHARE_AFFECTED = 0.8         # share of revenue flows the outage blocks
RETURN_RATE = 0.3            # share of blocked purchases that happen later anyway
SLA_CREDITS_AND_SUPPORT = 12_000   # dollars per incident, illustrative

avg_per_minute = ANNUAL_ONLINE_REVENUE / HOURS_PER_YEAR / 60
loss_per_minute = avg_per_minute * PEAK_FACTOR * SHARE_AFFECTED * (1 - RETURN_RATE)
print(f"average revenue per minute ${avg_per_minute:,.2f}; lost revenue per outage minute ${loss_per_minute:,.2f}")
for mttr in (30, 90):
    per_incident = loss_per_minute * mttr + SLA_CREDITS_AND_SUPPORT
    print(f"MTTR {mttr:>2} min: ${per_incident:>9,.0f} per incident, 6 incidents a year ${6 * per_incident:>9,.0f}")

Output:

average revenue per minute $228.31; lost revenue per outage minute $191.78
MTTR 30 min: $   17,753 per incident, 6 incidents a year $  106,521
MTTR 90 min: $   29,260 per incident, 6 incidents a year $  175,562

If the factor were 1.0 (incidents at random hours) lost revenue per outage minute would be $127.85 and an incident at 30 minutes would cost $15,836, so the peak-factor assumption moves the per-incident cost by about 12%. Lost revenue per outage minute at the 1.5 factor is $191.78, so extending recovery from 30 to 90 minutes adds 60 x $191.78 = $11,507 per incident (from $17,753 to $29,260) and about $69,000 a year over six incidents (from $106,521 to $175,562).

Where the numbers come from, and the caveats

• Revenue per minute should come from payment logs for the same weekday and hour of past incidents, not from a yearly average.
• The return rate comes from comparing order volume in the hours after past outages with a normal day. For example, if 1,000 orders were blocked during an outage and the following three hours ran 300 orders above a normal day, the return rate is 300 / 1,000 = 30%.
• The share blocked comes from payment logs too: the fraction of normal orders in the affected hours that went through the failed component.
• Revenue that is not minute-by-minute (annual subscriptions) is not lost during an outage; the damage shows up as churn, credits and trust, which need separate estimates.
• The model leaves out longer-term effects (customers who leave), so it is a floor for the damage of a single long outage.

Why this matters for decisions

It turns an engineering metric into a price: "each minute we shave off recovery is worth about $190 per incident", which you can set against the cost of better alerting or runbooks (written step-by-step recovery procedures).

Direct answer

Make the invisible visible by pricing it: convert "40% fewer outages" into avoided cost per year, add the benefits customers never see but the company does (engineer toil, on-call load, delivery speed), and be honest about payback. Then prove it in a pilot, but not with outage counts alone: outages are too rare for a short pilot to show a 40% change, so the pilot must be judged on leading indicators that occur often enough to measure, with a control group and success criteria agreed beforehand.

Making the case to executives

Frame it as insurance: a known cost now against an expected loss that falls. Illustrative inputs: 10 major outages a year, 50 minutes each, $300 of lost revenue per minute, $20,000 per outage of response time and service credits, and a $220,000 one-off project cost.

OUTAGES_PER_YEAR = 10
MINUTES_PER_OUTAGE = 50
REVENUE_LOST_PER_MINUTE = 300
RESPONSE_AND_CREDITS_PER_OUTAGE = 20_000    # engineer time plus SLA credits, illustrative
PROJECT_COST = 220_000                       # one-off, illustrative
REDUCTION = 0.40

per_outage = MINUTES_PER_OUTAGE * REVENUE_LOST_PER_MINUTE + RESPONSE_AND_CREDITS_PER_OUTAGE
annual = OUTAGES_PER_YEAR * per_outage
avoided = annual * REDUCTION
print(f"cost per outage ${per_outage:,}; yearly outage cost ${annual:,}")
print(f"outages avoided per year {OUTAGES_PER_YEAR * REDUCTION:.0f}; value ${avoided:,.0f} a year")
print(f"payback on outage cost alone: {PROJECT_COST / avoided * 12:.1f} months")

Output:

cost per outage $35,000; yearly outage cost $350,000
outages avoided per year 4; value $140,000 a year
payback on outage cost alone: 18.9 months

On outage cost alone, payback is 18.9 months, which is a sober number to show rather than hide. Then add what that number leaves out:

• Tail risk. The average hides the rare bad day; one 4-hour outage costs 4 x 60 x $300 = $72,000 in lost revenue before response costs. Reducing the chance of the long tail is worth more than the average suggests.
• Engineering time. Hours spent in incident response, postmortems and manual recovery, and on-call burnout (attrition costs are real but must be estimated, not asserted).
• Delivery speed. Fewer failed releases means more deploys, which is a feature-velocity benefit.
• Customer-visible proxies. Support tickets, SLA credits and renewal risk for accounts that have had incidents.

Ask for a staged decision: fund the pilot on the two most incident-prone services, with a go or no-go review at a set date. The pitch an executive would hear: "Outages cost us about $350,000 a year. This project removes about 40% of them, roughly $140,000 a year, and also cuts the pages that wake our engineers. It costs $220,000 once, so on outages alone it pays back in about 19 months, sooner once engineering time is counted. I am asking you to fund a pilot on two services, with success criteria we agree today and a review date. If we miss them, we stop."

Proving value in a pilot

Design. Pick pilot services and comparable control services that do not get the project in the same period (same traffic, similar change rate). Agree the metrics, the period and the success threshold before starting.

Why outage counts are not enough. A pilot's expected outages are few. In plain words, the code below answers one question: if the project really does cut outages by 40%, how often would a pilot of a given size show it convincingly, rather than looking like luck? That chance is called power. Suppose the treated and control groups have equal exposure, outage counts are Poisson (random, independent events), and the treated group truly has 40% fewer. The chance that a one-sided exact test at the 5% level detects it (the power) depends on how many outages the control group is expected to have over the pilot:

import math

def pois_pmf(lam, kmax):
    p = [math.exp(-lam)]
    for k in range(1, kmax + 1):
        p.append(p[-1] * lam / k)
    return p

def power(control_events, reduction=0.4, alpha=0.05):
    """Expected events in the control group over the pilot; treated group has
    (1 - reduction) times as many. Equal exposure. One-sided exact test: given the
    total N, the treated count is Binomial(N, 0.5) under no effect."""
    lc, lt = control_events, control_events * (1 - reduction)
    kmax = int(lc + 12 * math.sqrt(lc) + 20)
    pc, pt = pois_pmf(lc, kmax), pois_pmf(lt, kmax)
    # largest treated count that is significant, for each total N
    cache = {}
    def crit(N):
        if N not in cache:
            cum, best = 0.0, -1
            for i in range(N + 1):
                cum += math.comb(N, i) / 2 ** N
                if cum <= alpha:
                    best = i
                else:
                    break
            cache[N] = best
        return cache[N]
    total = 0.0
    for nt in range(kmax + 1):
        for nc in range(kmax + 1):
            if nt <= crit(nt + nc):
                total += pt[nt] * pc[nc]
    return total

for ctrl in (5, 10, 20, 50, 100):
    print(f"control events {ctrl:>3}, treated expected {ctrl*0.6:>5.1f}, power {power(ctrl):.2f}")

Output:

control events   5, treated expected   3.0, power 0.09
control events  10, treated expected   6.0, power 0.19
control events  20, treated expected  12.0, power 0.35
control events  50, treated expected  30.0, power 0.69
control events 100, treated expected  60.0, power 0.93

With 5 or 10 expected outages in the control group, power is 9% to 19%; you would need about 100 to be 93% likely to detect the effect. So a quiet pilot proves nothing either way.

How to read the code. The two groups' outage counts are drawn at random from the Poisson probabilities (pois_pmf), which give the chance of 0, 1, 2, ... outages when the average is known. For every pair of counts, the test asks whether the treated group's share of the combined outages is low enough to be surprising. The exact test works like this: if the project did nothing, each outage would be a coin flip between the two groups, so the treated count out of N total outages follows Binomial(N, 0.5). With N = 20 total outages, the treated group having 5 or fewer happens by chance about 2% of the time (6 or fewer is about 6%, which is over the 5% cut-off), so 5 is the critical value for N = 20; the function crit finds that cut-off for each N and caches it. The final double loop adds up the probability of every pair of counts that lands at or below the cut-off. "One-sided" means we only ask whether the treated group is lower, and "5% level" means that when nothing has changed the test wrongly declares success no more than 5% of the time.

Use measures that happen often:

• Change failure rate (the share of deployments causing an incident or rollback).
• Pages (alerts that wake an engineer) per week, and the share that are actionable.
• Faults caught by the new safeguards before customers saw them (near-misses), such as a bad deploy that automatic rollback reverted in two minutes before anyone noticed, or injected failures (a server deliberately switched off in a test) that the system survived.
• Time to detect and time to recover in incidents that do occur.
• Customer-facing minutes of impact, SLA credits (refunds promised in a service-level agreement) and support tickets as lagging confirmation.

A common target is 80% power: an 80% chance of detecting a real 40% effect. With 50 expected events in the control group, power is about 69%, just short; with about 70 it is about 82%, and with 100 it is 93%. So choose indicators that should produce roughly 70 or more events in the control group over the pilot (about 5 a week over a 13-week pilot), and treat anything below that as too thin to read.

Trade-offs and pitfalls

• Choosing the pilot services because they are easy makes the result unrepresentative; choose by incident history and report that choice.
• Regression to the mean (extreme results drift back toward normal on their own): if a service had 8 outages last quarter when it usually has about 4, it will probably have 4 or 5 next quarter with no project at all, which would look like a 40% improvement. A control group chosen the same way shows the drift, which is why it matters.
• Declaring victory on a quiet quarter: absence of outages is the expected outcome in many quarters.
• Agree the kill criteria too: what result would make you stop?

Direct answer

I would write the plan as a data function (analytics) and say so; the same method applies to engineering or reliability. Define what "active" means first, decompose the 25% goal into new, kept and returning users, then pick three initiatives that attack the biggest leaks, with a stated reason for each and a stated list of things I will not do.

Terms

• Active user: a person who performed a defined core action in a window, for example at least one meaningful action in the last 28 days. This definition must be written down; changing it later can move the number without any real change.
• Growth accounting: active users this period = active last period + new + returning (reactivated) - lapsed. It shows which flow to change.
• Activation: a new user reaching the first valuable action, such as completing a first task. The activation funnel is the sequence of steps to get there, with the share who drop at each step. Time to first value is how long that takes.
• Cohort: users who joined in the same period, tracked together. A holdout is a group deliberately left out of a change as a comparison. Reactivation means bringing a lapsed user back.
• Vanity total: a big number, such as total sign-ups, that does not show whether people stay. Reconciliation within an agreed tolerance: the new, retained, returning and lapsed counts must add up to the reported total within a set gap, for example 0.5%.

The arithmetic of the goal (illustrative base: 400,000 active users)

25% of 400,000 = 100,000 more active users over four quarters. As a straight line that is 25,000 net per quarter. If growth compounds instead, it is about 5.7% per quarter (1.25 to the power of 0.25 is 1.0574). I would plan to the straight line and track the compounded path beside it: compounding asks for about 23,000 net adds in Q1 and about 27,100 in Q4, so the straight line keeps the team ahead of the compounded path early, which leaves room for the harder last quarter.

Quarter plan: three prioritised initiatives (Q1)

How much each initiative adds (illustrative Q1 sizing)

• Initiative 1 adds no users itself; it makes the others measurable.
• Initiative 2: assume 120,000 new users a quarter. Raising 7-day activation from 30% to 40% gives 12,000 more activated users. If activated users are still active at 28 days 60% of the time against 10% otherwise, that is 12,000 x (0.60 - 0.10) = 6,000 more active users.
• Initiative 3: assume 200,000 lapsed users and a reactivation test showing 2% more return than the holdout: 200,000 x 0.02 = 4,000 returning users.

Together about 10,000 of the 25,000 a quarter, or 40% of the line, once both are fully live; that is a run-rate figure, not a Q1 result. On this plan's own timeline the first activation experiment reads out in week 10, so a winning flow reaches only about 3 of the 13 weeks of new users in Q1 (12,000 x 3/13 is about 2,800 more activated users, and their 28-day retention lands mostly in Q2), and the reactivation test runs weeks 6 to 12. Q1 therefore adds well under 10,000 net users from these initiatives; the full effect shows from Q2 on, and the Q1 deliverable is the measured, trusted baseline plus proven experiments. I would say that out loud: the remaining 15,000 depends on acquisition and product work owned elsewhere, and the plan names that gap and its owner. Activation gains continue each quarter because every new cohort benefits.

Plan outcomes in order: by week 3 the numbers are trusted; by week 10 the first experiment has read out; by week 13 the quarter's net adds are measured against the 25,000 line and the plan is rebased.

What I would deliberately not do

• Build a machine-learning personalisation model: expensive, and the first two initiatives are cheaper to test.
• Create more dashboards for vanity totals (total sign-ups) that do not separate retained from new.
• Accept ad hoc requests that are unrelated to the three initiatives without trading them off in writing.
• Chase a one-off spike from a campaign that brings users who do not return.

Customer-first version of the same plan

If the mission is "customer-first growth", the 90-day version keeps the three initiatives but states outcomes in customer terms: faster time to first value, fewer customers who give up in week one, more lapsed customers who come back for a reason they care about. Progress measures: time to first value, 7-day activation rate, 28-day retention of the new cohort.

Reliability or engineering variant

For an SRE (site reliability engineer) team the ladder is: protect the sign-up and first-use path (latency and error budgets on those paths), fix the top causes of failed first sessions, and add alerts on funnel drop-offs. An error budget is the amount of failure a service may have in a period before reliability work takes priority over new features; latency is how long a response takes. The same rule applies: each item names the metric it moves and what is left undone.

Pitfalls

Counting sign-ups as active users; a plan with no "not doing" list; no way to tell whether movement came from the initiatives or from seasonality (use holdouts, groups kept out of a change as a comparison).