Value Communication & Business Case Questions

Direct answer

For a 12-month ROI shown to a CFO (chief financial officer) I would show a range anchored on one stated "likely" case, with the break-even point marked, not a single number. A single number looks precise but is almost certainly wrong, and the CFO knows it. A bare range with no centre looks evasive. ROI (return on investment) here is (benefit minus cost) divided by cost over 12 months.

Single-point estimate vs range

What I would use and how I present it

I use the range, with the likely case first. Cost for the 12 months is $150,000 (licence $100,000 plus rollout $50,000). Benefit = active users x hours saved per user per month x loaded cost per hour (salary plus overheads) x 12.

What I say: "Our likely case is a 44% return, about $66,000 net. It breaks even if benefits reach $150,000, which is 69% of the likely case. The low case loses $44,400 and needs everything to disappoint at once. Adoption is the input that moves it most."

A practical, non-technical method for the three cases

1. List the three or four drivers (users, hours saved, hourly cost).
2. For each driver, agree with the customer a plausible low, likely and high, each with a source (their data, pilot, reference customers).
3. Build the low case with the pessimistic value of each driver, the high case with the optimistic ones. State clearly that low and high are corner cases (all drivers at their worst or best at once), which is rare.
4. Show one table, a sentence per case on what must be true, and the break-even point.

Optional and advanced: when a Monte Carlo simulation is warranted

The three-case table above is what I present in almost every meeting. This section is a rarely needed extra.

A Monte Carlo simulation runs the model thousands of times with each input drawn at random from a range, then reports percentiles (P10 means 10% of runs fall below that value, P50 is the middle run, P90 means 90% fall below). Use it when several inputs are uncertain at once, the decision threshold matters (is there a meaningful chance the benefit falls below cost?), or the audience is quantitative. Do not use it for a quick meeting: a CFO who sees a black box will ask where the input ranges came from, and "I made them up" ends the conversation. The code below pins the seed and every range so a reviewer can rerun it.

import random

COST = 150_000  # 12-month total cost: licence 100,000 + rollout 50,000 (USD)

def benefit(users, hours_per_user_month, usd_per_hour):
    return users * hours_per_user_month * usd_per_hour * 12

def roi(b):
    return (b - COST) / COST

cases = {"Low": (200, 0.8, 55), "Likely": (250, 1.2, 60), "High": (300, 1.6, 65)}
for name, inputs in cases.items():
    b = benefit(*inputs)
    print(f"{name:7s} inputs={inputs} benefit={b:,.0f} net={b-COST:,.0f} ROI={roi(b):.0%}")

random.seed(42)  # fixes the random sequence so anyone rerunning gets identical numbers
N = 10_000
runs = sorted(
    benefit(random.triangular(150, 350, 250),   # active users: (low, high, most likely)
            random.triangular(0.6, 1.8, 1.2),   # hours saved per user per month
            random.triangular(45, 75, 60))      # loaded USD per hour
    for _ in range(N)
)
p10, p50, p90 = (runs[int(N * q)] for q in (0.10, 0.50, 0.90))
print(f"benefit P10={p10:,.0f} P50={p50:,.0f} P90={p90:,.0f}")
print(f"ROI     P10={roi(p10):.0%} P50={roi(p50):.0%} P90={roi(p90):.0%}")
print(f"share of runs where benefit < cost: {sum(b < COST for b in runs)/N:.1%}")

Output:

Low     inputs=(200, 0.8, 55) benefit=105,600 net=-44,400 ROI=-30%
Likely  inputs=(250, 1.2, 60) benefit=216,000 net=66,000 ROI=44%
High    inputs=(300, 1.6, 65) benefit=374,400 net=224,400 ROI=150%
benefit P10=140,582 P50=210,431 P90=298,207
ROI     P10=-6% P50=40% P90=99%
share of runs where benefit < cost: 14.2%

How the code works: random.triangular(low, high, mode) picks a random number between low and high, with values near the most likely one (the mode) picked more often, so the shape is a triangle peaking at the likely value. I set each most-likely value to the table's likely case (250 users, 1.2 hours, $60), and the low and high to plausible extremes for that one input, wider than the table's corner cases (an assumption to agree with the customer, not a measured fact). One simulated run, by hand: draw 280 users, 1.0 hours and $58 per hour, giving benefit 280 x 1.0 x 58 x 12 = $194,880 and ROI (194,880 - 150,000) / 150,000 = 30%. The code does that 10,000 times and sorts the benefits from smallest to largest. runs[int(N * q)] then reads the value at that fraction of the way up the list: for q = 0.10 it is runs[1000], the 1,001st smallest, so about 10% of runs fall below it. The seed is the starting point of the random sequence; fixing it makes the output repeatable.

Reading it: in this illustrative simulation about one run in seven (14.2%) loses money, and the 10th to 90th percentile ROI is -6% to 99%. That is a narrower, more realistic range than the corner cases (-30% to 150%), because inputs rarely all hit their extremes together. The triangular ranges are my assumptions, so the simulation inherits their weakness.

Not losing the room

• Lead with the likely case and the decision, not the spread.
• Show three cases, not ten. More than three scenarios blurs the message.
• Put the break-even on the page: "the case holds as long as benefit is above $150,000."
• Name the one driver that matters most and say how you will track it.

Pitfalls

• Choosing a low case so mild that nobody believes it.
• Presenting percentiles to an audience that has not asked for them.
• Mixing bases: ROI over 12 months and payback over three years in the same sentence without labelling.

Direct answer

Build one story with a spine all three share, then give each executive a short section in their own measure, and move depth into an appendix so the main deck stays short. The CFO (chief financial officer) gets money and payback (the month when cumulative savings first cover the cost), the CIO (chief information officer) gets architecture and risk, and the Head of Operations gets rollout and day-to-day impact.

Main deck: 8 slides, one visual each

Each slide has one visual because a CFO and an operations lead will each study only the visual that matters to them.

What the key slides actually say (illustrative figures: $150,000 first-year cost, $216,000 yearly benefit, so $18,000 a month)

• Slide 1 headline: "Approve $150,000 to remove $216,000 a year of manual order-handling cost; payback in month 9."
• Slide 4 cumulative cash (cumulative cash is the running total of money in minus money out): month 0 is -$150,000, month 4 is -$78,000, month 8 is -$6,000, month 9 is +$12,000. The curve crosses zero in month 9, and that crossing is the point marked on the chart.
• Slide 5 three-year TCO: status quo $1,578,000 ($526,000 a year: $310,000 of current systems and support plus the $216,000 of manual order handling) against proposed $1,080,000 ($310,000 a year of running cost that stays, plus the $150,000 one-time cost). The $498,000 gap equals 3 x $216,000 - $150,000, so the TCO bars reconcile with the payback curve on slide 4.
• Slide 6 risk table, one sample row: Risk: data migration overruns by 4 weeks. Likelihood: medium. Mitigation: migrate in two phases against a fixed-scope plan. Owner: Head of Operations.

What each executive gets in the main story

• CFO: slides 4 and 5: payback, three-year TCO, the two assumptions the result depends on.
• CIO: slides 3 and 6: how it fits the current estate (the customer's existing systems), integration effort, security and resilience.
• Head of Operations: slides 6 and 7: what changes for their teams, phasing, rollback.

Appendix for the deeper questions

Appendix slides are not presented; they sit ready for the follow-up question. If time is short, build A1, A6 and A7 first, because finance and risk questions come up in almost every review:

• A1: Calculation detail and every assumption with its source (for the CFO and procurement)
• A2: Decision drivers (the criteria the buyers will score the options on) and approvals required (for the people who sign off)
• A3: Benchmarks (measured results from comparable customers) against comparable deployments (for a high-cost, high-reliability solution)
• A4: Compliance attestations (formal statements by an auditor that a standard is met) and certifications
• A5: Operational runbooks (step-by-step procedures for running the system): failure handling, escalation and rollback
• A6: Risk register with owners
• A7: Sensitivity analysis (how the result changes when one assumption changes, for example payback if the benefit is 20% lower)

Shorter forms of the same story

The 8-slide main deck above is the core. The three forms below are cut-downs for specific slots, not alternatives to design first.

• 3-slide CFO pitch: (1) cost reduction, (2) implementation risk and vendor credibility, (3) ROI (return on investment) and payback. Each slide ends with one line of evidence, such as a customer reference or the audited baseline.
• One-page value summary: per stakeholder, a headline metric, one supporting data point and one or two sentences of message.
• 10-slide funding deck (12-month expansion): the 8 slides above plus a slide on the 12-month milestones and one on the funding request by phase.

Pitfalls

• A single deck that tries to answer every question; put it in the appendix.
• Metrics owned by nobody in the room. If the Head of Operations has no number on any slide, they will vote against.
• Showing the CFO a feature list. They need the chart that explains when the money returns.

Direct answer

Do not map goals to features. Map each goal to the capability that moves it, the executive who is accountable, the KPI (key performance indicator) that proves it, and the evidence you can bring. Write each message in the first executive's own measure. The three goals are: reduce operating costs 10% within 24 months, speed product launches 30%, expand into two new countries.

Goal to capability map

One message per executive

• CEO: "We will fund the 10% operating-cost goal from inside the programme: savings start in quarter two and are on track to cover the programme cost within the 24-month window." The arithmetic behind it (illustrative): a baseline operating cost of $50M a year makes the 10% goal $5M a year of run-rate savings (the yearly rate once the changes are in place), about $417,000 a month. If savings start at month 4 and ramp up in a straight line to that rate by month 24, cumulative savings reach about $4.4M by month 24. Against a $3M programme cost, cumulative savings cross the cost around month 21, so payback lands inside the 24-month window.
• CTO: "Your release path shrinks from request-to-production in weeks to days by removing hand-offs, giving you the 30% faster launch with the same team."
• Head of Product: "Both new countries go live on one codebase with regional data residency built in, so entering a market is a configuration decision, not a rebuild."

KPIs and proof per executive

The same method on a second goal set

Goals: accelerate digital channels, cut operational cost 10%, improve regulatory compliance. For each, pick 2-3 measurable KPIs and say where the data comes from, because a KPI nobody can source is just a claim:

Trade-offs and pitfalls

• The goals can conflict. Speed (30%) and cost (10%) pull against each other if speed needs duplicate environments. Say how you resolve it (shared platform, so the second country adds marginal cost, meaning only the extra cost of one more country: if the first country needs $1.5M of platform build, the second needs only configuration, localisation and a regional data setup of perhaps $0.3M, so launch speed rises without cost rising in proportion) rather than hoping nobody notices.
• Messages must not contradict. The CEO line promises savings by quarter two, so the CTO line must not need a large upfront rebuild.
• Proof beats polish. A pilot with measured lead time is stronger than three well-written messages.

Direct answer

A customer value proposition is a specific, testable promise to a named buyer: "for this person, with this problem, we deliver this measurable change, and here is how you will know." What separates it from a feature list is the subject of the sentence. A feature list says what the product has. A value proposition says what the buyer's world looks like afterwards, in a unit the buyer already tracks.

What makes one strong

A value proposition for an HR manager (HR onboarding automation)

"For HR managers who onboard hundreds of people a year through email threads and spreadsheets, our onboarding automation turns the offer-accepted-to-day-one checklist into one tracked workflow. Laptop, accounts, payroll forms and manager tasks start automatically, so HR spends about 2.5 hours per hire instead of 6, and 95% of new hires have everything ready on day one. Unlike a generic ticketing tool, it is built around hire dates and compliance paperwork, so nothing falls through when a start date moves."

Why this works for an HR manager: it opens with their pain (chasing people), uses their own units (hours per hire, day-one readiness), and ends with a differentiator.

Measurable results to show it holds up

Pick four to five and agree each one's baseline (today's number, measured before you start) and target with the buyer:

1. HR administrative hours per hire (time cards, chasing forms, status emails).
2. Day-one readiness rate: percent of hires with equipment, accounts and paperwork complete on their first morning.
3. Offer-accepted-to-start no-show rate, a leading signal (a measure that moves early and hints at what will happen later) of a weak pre-boarding experience.
4. Time to productivity (days until a new hire completes their first independent task, as reported by the hiring manager).
5. 90-day attrition of new hires. This is the outcome the executive cares about, but many factors drive it, so treat it as a lagging indicator (a measure that only moves months after the change, so it confirms results rather than predicting them) that you track, not a claim you guarantee.

Worked example (illustrative numbers, replace with the buyer's own)

Assume 600 hires a year, 6 HR hours per hire today, 2.5 hours after automation, and a loaded cost (salary plus overhead) of $45 per hour.

• Today: 600 x 6 = 3,600 hours a year.
• Saved: 600 x (6 - 2.5) = 2,100 hours a year.
• Value: 2,100 x $45 = $94,500 a year in HR capacity (capacity freed, not necessarily headcount removed: 2,100 hours is about 1.2 full-time people at 1,800 hours a year, so the HR team can absorb growth without hiring, but payroll only falls if someone is actually let go or a vacancy goes unfilled).

The most sensitive assumption is the 2.5-hour figure. State that you will validate it with a two-week time study of the buyer's current process before presenting any dollar claim.

Trade-offs and pitfalls

• Do not bury the proposition under a long list of capabilities; one outcome, one proof.
• Hours saved is the weakest financial claim (it is only real if the freed time is redeployed). Pair it with a metric the HR manager's boss owns, such as day-one readiness or attrition.
• Promising an outcome you do not control (for example "reduces attrition by 20%") damages trust. Say what you can show, and commit to measuring the rest together.

Direct answer

A good 60 to 90 second technical pitch ties one architecture decision to the buyer's one number, names the single technical advantage that produces the result, and answers the buyer's top worry in a sentence. Spoken at about 150 words a minute, that is 150 to 225 words. For a DAU goal, the architecture is an event-driven notification pipeline; the worry I would address is cost predictability.

Terms: DAU is daily active users, the number of distinct users who use the product on a given day; push notification is a message sent to a user's device by the app; event-driven means actions generate events that trigger processing immediately instead of waiting for a scheduled batch job; a control group is a set of users deliberately not given the change, so you can see the difference it makes.

The pitch (about 155 words, roughly 60 to 65 seconds)

Your goal is twenty percent more daily active users, and the fastest lever is reaching people at the moment a notification is useful to them. We would build a push pipeline on a managed event-streaming and messaging service: each user action becomes an event, and a rule decides within seconds whether to notify and when. The technical advantage that drives the result is event-driven delivery with per-user timing, so an abandoned cart or a friend's reply reaches the person while it still matters, instead of in a nightly batch. It also scales on its own: a launch-day spike does not need a human to add servers. On your main concern, cost, we would set a monthly spend cap and alert at eighty percent, so the bill is predictable. Let's agree on a four-week test with a small group of users and measure the lift in daily active users against a control group before committing further.

The goal, the four-week test and the lift measurement are the substance. The specific timing (seconds) and the eighty-percent alert are design choices to confirm against the platform you actually propose.

Why it is built this way

• Goal first. The first sentence is the customer's own number (20% DAU), not our architecture.
• One technical advantage: event-driven delivery with per-user timing. It drives the result by raising the share of notifications that arrive when they are relevant, which lifts opens and returns to the app.
• Top worry answered concretely. I chose cost predictability. If the buyer's worry were security, the line would become "the pipeline sends only an identifier to the push provider; personal data stays in your account and is encrypted at rest." If scale: "it scales automatically for launches, and we load-test to your peak before go-live."
• A proof step, not a promise. A control-group test turns "this should lift DAU" into a measurable claim and caps the risk for the buyer.

One sentence for a CTO versus a finance leader

If you must say it in a single sentence: "For your CTO this is a managed, event-driven pipeline that frees engineers and scales to launch peaks, and for your finance leader it is a capped, pay-per-notification cost with a test that prices each additional daily active user before commitment." The two audience-specific sentences below are how I would say it when I can address each person separately.

• CTO (chief technology officer): "The pipeline is event-driven and managed, so your team ships features rather than operating notification servers, and it scales to launch peaks without re-architecture."
• Finance leader: "You pay in proportion to notifications sent with a monthly cap, and the test tells you the cost per additional daily active user before you commit."

Tailoring matters because the two people are judged on different numbers: the CTO on delivery risk and engineering capacity, the finance leader on cost and return. The same architecture sounds like a risk or an asset depending on which number you connect it to.

Pitfalls

• Opening with the architecture. The buyer's goal is the headline.
• Promising a specific DAU lift. A 20% target depends on product and content as well as delivery timing; promise a measured test, not the outcome.
• Over-notifying: more messages can raise opt-outs and uninstall rates, which reduce DAU. Mention frequency limits.