Translating FDE Work into Customer ROI and Risk

Illustrative. This lesson continues the composite engagement from Discovery and Scoping: the logistics company, the compliance holds. The dialogue is invented to teach the move and contains no invented statistics. Where a number would appear, the lesson shows you extracting it from the customer instead of making one up.

You've scoped a system that flags risky routing decisions. Now the VP has to walk into a budget meeting and defend spending on it, to people who will never see the code. Your job is to hand them the argument in their units. This is the translation an AI engineer never does, and it's a large part of why the role exists.

There's an honesty trap here that most write-ups fall into: they teach you to assert a return ("this saves you millions a year!"). Don't. You don't know that number, and a made-up figure is the fastest way to lose a sophisticated buyer. The credible move is to build the ROI case out of the customer's own numbers, and to name the risk as clearly as the reward.

Before reading on

The VP asks: "I need to justify this to Finance. What's the ROI?"

You do not know what a compliance hold costs this company. What do you say — and what do you refuse to say?

You refuse to invent a dollar figure. What you do is give them the shape of the calculation and ask for the one number that fills it in. Watch.

Move 1 — build the frame, ask for their number

Don't answer "the ROI is X." Give the structure of the return and let them supply the value:

You: "I won't hand you a number I made up. Finance would see through it, and so would you. Here's the shape instead: the system's value is holds avoided × what a hold costs you. I don't know the second figure; you do, or you can get it. What does one compliance hold actually cost you? The fees, the delay, the staff time chasing it down."

VP: "We've never put a clean number on it, but a bad one ties up a shipment for days and someone spends a week on the paperwork."

You: "Then that's your ROI input. If we can show, from the logs, that we prevented even a handful of those a quarter, you multiply that by your cost-per-hold and you have a defensible number, built on your data. And we'll have the flag logs to prove the count."

You just gave the VP something far stronger than a fabricated projection: a formula they own, and a plan to fill in the one variable with real data from the system itself.

Move 2 — name the risk as clearly as the reward

A pitch that's all upside reads as a sales pitch, and a sophisticated buyer discounts it. Naming the risk builds credibility:

You: "The honest risk is false flags. If the system cries wolf on routes that were fine, the veterans stop trusting it in a week and we're done. That's the failure that would sink this, so I want to name it now. So we start conservative: flag only the high-confidence risky cases, measure how often we're right, and tune before we widen. The cost of a missed hold is high; the cost of annoying your best dispatcher is also high, and I'm designing for both."

Volunteering the failure mode, and showing you've designed around it, tells the VP you've done this before. It also inoculates you: when a false flag happens (and one will) you predicted it, so it reads as the tuning step you planned for, and the VP's confidence holds.

Bad / Good / Great — "what's the ROI?"

Bad — "it'll save you millions." You invented a number. Best case, Finance ignores it; worst case, they anchor on it and you've promised a return you can't control. Either way you spent credibility you needed.

Good — "it reduces compliance holds, which are expensive." True, and directionally right, but it's not an argument the VP can take to Finance. There's no structure and no number they can defend.

Great — "the return is holds-avoided times your cost-per-hold; I'll show the avoided count from the logs, you supply the cost, and we have a figure built on your data. The main risk is false flags eroding trust, so we start narrow and tune on measured precision." You gave them a defensible formula grounded in their numbers, and you named the risk before they could. You showed up as a partner building their business case with them.

The probe to expect

VP: "Finance will want the number now, before we've collected any logs."

You: "Then we give them a conservative range with the math shown and labeled as an estimate, using your cost-per-hold and a deliberately low avoided-count, and we commit to replacing the estimate with measured numbers in the first quarter. A shown, conservative estimate they can pressure-test beats a confident figure they can't. And the day we have real logs, that slide only gets stronger."

Why this is the senior signal

Notice what the translation is really doing: it converts an engineering artifact (a flagging model) into a business object (a defensible ROI case with a named risk) that survives a room full of non-engineers. That conversion is the FDE's leverage. An interviewer probes for it directly: "how would you justify this to the customer's leadership?" The tell of someone who's done it is that they reach for the customer's numbers and volunteer the downside instead of reciting benefits.

The transferable pattern

Give the customer the structure of the return, fill it with their numbers, and name the risk as loudly as the reward. Never invent the figure. Derive it from their data and your system's own logs, and volunteer the failure mode before they find it. That's an argument they can defend without you in the room, which is what you were hired to leave behind.

Next: Driving Adoption. The business case is only real if people actually use the thing, and the hardest user is the one who's sure he doesn't need it.