You have metrics. Good ones, probably. Your recommendation model has a 94% NDCG. Your classification model has an F1 of 0.87. You’re tracking precision, recall, AUC. You’re measuring fairness. You have dashboards.

Your CFO does not care about any of this.

It’s not that your metrics are wrong. It’s that your CFO cares about different metrics, and most technical organizations have missed the gap. When you show someone “our model improved precision by 3 percentage points,” what they hear is “we spent six months optimizing something abstract.” When they ask how much money that’s worth, you don’t have a good answer. And that disconnect—between model performance and business performance—is where most AI projects end up trapped.

What Your CFO Cares About

Your CFO cares about:

Conversion: Did the AI initiative result in more revenue, or cut costs?

Risk avoidance: Did it prevent something bad from happening? How much?

Velocity: Did it let us do something faster, so we could do more volume?

Margin: Did it improve the margin on existing business?

Each of these is measurable. None of them are “model F1.”

Consider a recommendation model. Your metric might be “NDCG improved from 0.72 to 0.75.” Your CFO’s metric is “users who saw the new recommendations bought 6% more than users who saw the old ones.” Different thing entirely. The F1 improvement was necessary to get there, but it’s not what matters to the business.

Or a fraud model. Your metric is “we improved true positive rate from 87% to 91%.” Your CFO’s metric is “we caught $2.3 million in fraud last quarter, compared to $1.8 million the quarter before.” Or better: “the cost of the false positives we generate (customer friction, manual review) is lower than the cost of fraud we miss.”

The pattern is the same: your metrics are leading indicators. His are lagging indicators. And lagging indicators are what determine whether you keep funding the project.

Why Most Organizations Have This Wrong

There are a few reasons technical teams and business teams measure different things.

First, your metrics are available. You have access to model performance data. You’re logging predictions. You’re measuring holdout accuracy. You’re not necessarily inside the business system where you can see whether recommendations turned into purchases or whether avoided fraud created margin.

Second, your metrics are crisp. “F1 of 0.87” is unambiguous. “The model prevented fraud” is less so. You have to create attribution models, control groups, have arguments about whether the model or the sales team or the pricing change drove the improvement.

Third, most data teams assume that model performance maps to business performance. If the model is better, the business outcome will follow. This is usually true. But not always. And the gap—between a technically excellent model and a model that actually moves the needle for the business—is where most projects stall.

Fourth, measurement is political. If you own the model, you want to measure things that show the model in a good light. If you’re part of the business, you want to measure things that show you created value. If those measurements are different, there’s room for disagreement. It’s safer to stick to model metrics.

How to Translate

This is not actually that hard to fix. It requires being intentional about what you measure.

Start by defining the business question clearly: What would success look like? Not “the model is accurate.” What does accurate actually deliver? Is it more revenue? Less risk? Faster processing? Happier customers?

Then translate that into a measurable outcome.

If the business question is “should we use this model for recommendations,” the success metric is not “NDCG > 0.75.” It’s “users who see AI-recommended products have 15% higher conversion rate than users who see non-AI recommendations, measured over 30 days.” Now you have something testable and something that connects to revenue.

If the business question is “should we use this model for loan approvals,” the success metric is not “F1 > 0.85.” It’s “loan defaults decrease by 5% and loan volume increases by 10% when we use the model vs. traditional underwriting.” Now you have something that matters to the CFO.

The way to get there is via A/B test. Take your model. Put it in production for a subset of users or transactions. Measure what actually happens. Not “does the model work,” but “does deploying the model change behavior in the direction we want?”

The Conversation That Actually Matters

Here’s what this looks like as a conversation:

You come to the CFO and say: “I want to build a demand forecast model. Here’s what we’ll measure: does it reduce inventory carrying cost by more than the cost of the model?”

That’s a conversation. The CFO can engage with “well, what’s the cost of the model, and what’s the typical carrying cost?” and “do we have confidence those numbers are right?” and “how would we validate this?” Now you’re talking the same language.

You come with “the model has RMSE of 12.3%,” and the CFO does not know how to respond. She doesn’t know if that’s good. She doesn’t know if it’s worth investing in. She ends up saying “sounds nice, let’s see if it works,” and six months later you’re having a frustrated conversation about why the demand forecast project never got follow-up investment.

Most technical AI projects stall because nobody defined the business metric first. Everyone agreed the model should be accurate. Nobody agreed what accuracy delivers or how to measure whether it delivered.

The Fix

If you have AI projects that feel stuck, this is a diagnostic question: Can you answer this quickly and concretely: “If we deploy this model, what business outcome will improve, and by how much?”

If you can’t, that’s not a technical problem. That’s why it’s stuck.

If you can, but your CFO is still skeptical, that’s different. That’s a risk conversation. But at least you’re having a conversation about something real.

Your model metrics are important. But they’re not what determines whether your organization keeps funding AI. The business metrics are. Measure those first.