Make the case, and defend the work

You are asking for a decision: funding, headcount, a slot on the roadmap, or permission to ship. The pitch that works is not the one that sounds most confident — it is the one where the assumptions are visible, so leadership can argue with the numbers instead of with you.

This question arrives from both directions. A skeptical engineering leader asks why you cannot just write the logic. An enthusiastic executive asks why you are not using AI for everything. The same evidence answers both, and having it ready is the difference between looking rigorous and looking like you followed a trend.

When asked "why not just write rules?": "We built the rules version — it handles about 70% of cases and breaks on the rest, because the variety is in the wording, not the structure. The model covers that tail. We are keeping rules for the cases we have to guarantee, and the model handles what rules cannot enumerate."

When asked "why aren't we using AI here too?": "That one is a rules problem. The logic is stable, it has to be auditable, and a model would add cost and latency to get the same answer less predictably. We would be paying for uncertainty we do not need."

The strongest version of the argument is a number: the rules baseline scored X, the model scored Y, and the gap in business terms is Z. That sentence ends the debate faster than any framing — which is why establishing a heuristic baseline is worth doing before the meeting, not after.

An executive tests a prompt, gets a bad answer, and concludes the product is broken. They're not wrong to raise it — but they're using the wrong mental model to interpret it. Your job is to give them the right one without making them feel corrected.

The executive mental model: software either works or it doesn't. A bug gets filed, a fix gets shipped, the problem goes away. The AI mental model: the product operates at a quality level across a distribution of inputs. Some inputs get bad outputs. The question isn't "is it broken?" — it's "what percentage of inputs get bad outputs, and is that acceptable for this use case?"

The reframe that usually lands: "Think of it less like a bug report and more like a quality audit. We measure accuracy across thousands of inputs, not just one. The question is: what does our distribution look like, and did this example reveal a gap in a slice we care about?"

The goal of each script is the same: acknowledge the failure, reframe it from "bug" to "distribution sample," and redirect toward what actually matters. Every script has a "say this, not that" structure.

F1 scores and precision/recall don't belong in a board deck. Not because boards can't understand them — they can — but because they don't map to what a board actually needs to evaluate: business risk, competitive position, and investment return. Here's how to translate.

Slide 1 — Quality snapshot: one chart showing accuracy trend over time, the target threshold, and current slices. Not the methodology — the number, the trend, and the target. Add one sentence on what "wrong" looks like and who catches it.

Slide 2 — Unit economics: cost per task vs. human cost per task, gross margin at current volume, and the margin at projected scale. This is the slide that gets the CFO on your side. If the numbers aren't there yet, show the path and the volume where they flip positive.

Slide 3 — Risk register: the top three failure modes, what the current rate is, and what the mitigation is. Boards want to know you've thought about what can go wrong — not that nothing can. The absence of a risk register reads as naivety, not confidence.

A traditional SLA promises 99.9% uptime. An AI SLA does something different: it sets expectations about quality under uncertainty, commits to safety guardrails, and disclaims the guarantee of determinism — without sounding like a legal disclaimer nobody reads.

The best executive conversation is the one that never happens — because leadership already has the mental model before the angry Slack message arrives. Three things that prevent the crisis mode conversation:

Before the CEO finds the failure on their own, find it with them. Invite the exec team to a structured red-teaming session: "We're going to deliberately try to make this fail." When they find edge cases themselves, in a controlled setting, two things happen: (1) they feel ownership over the product's known limitations, and (2) those edge cases become part of the test suite. The session reframes "it has failure modes" from a PM admission to a shared team finding.

Early in the product's life, have one explicit conversation with your exec: "This system will be right X% of the time at launch. Here's what wrong looks like and here's who catches it. We're targeting Y% by [date]." This conversation, had once and documented, means every future n=1 test failure gets evaluated against an agreed baseline — not treated as evidence the whole thing is broken.

One page, once a month: accuracy trend, cost per task, the top three failure modes and their rates, one thing that improved, one thing that didn't. Not a metrics dump — a narrative. Leadership that gets this monthly develops an accurate intuition for AI quality over time, which means fewer panicked escalations and better funding conversations. It also creates a paper trail that protects you when things go wrong.