R&D operations

Technical-commercial translation: how to make AI decisions executives can actually make

Why AI proposals fail to reach executive decisions, a framework for translating technical detail into commercial tradeoffs, and examples of what the translation looks like in practice.

Most AI proposals that reach leadership either overwhelm or underwhelm. They either arrive as a technical document that no executive can evaluate, or as a commercial slide that no technical person believes. The decision stalls, gets deferred, or gets made on instinct rather than information.

The problem is not technical complexity or executive laziness. It is that nobody translated the proposal from one language into the other. That translation is a skill, and it is mostly missing from AI teams.

Why proposals fail to reach decisions

The technical team has been living with the problem for weeks. They understand the architecture, the model choices, the tradeoffs, the risks. When they present, they present the thing they understand: a technical problem with a technical solution.

The executive needs something different. Not less detail, but different detail. They need to know: what are we choosing between, what does each option cost in money and time and risk, and what happens if we choose wrong? That is a commercial question, and most technical proposals do not answer it.

The gap is not about dumbing things down. It is about reformatting information for a different decision context. An executive approving a €400k AI project needs to know that the build-vs-buy decision carries a 6-month timeline difference and a €120k cost difference, and that the build option creates IP that the buy option does not, but also requires two people the company does not yet have. That is a decision they can make. “We recommend a fine-tuned open-source model over a commercial API” is not.

The translation framework

Good technical-commercial translation does four things:

Surfaces the actual choice. Every technical proposal contains a set of real decisions, usually buried in the methodology section. Name them explicitly. Not “we will build an ML pipeline,” but “we are choosing between three approaches: a commercial API, a fine-tuned open-source model, and a custom-trained model. We recommend the second. Here is why.”

Expresses tradeoffs in commercial terms. Time, money, risk, and optionality are the currencies executives use. A model that is 6% more accurate but costs €80k more to train and requires 14 weeks of additional data work is a commercial tradeoff, not a technical one. Present it that way.

States the risk in outcome terms. “The approach may not generalise to edge cases” means nothing to an executive. “If the model underperforms on the 15% of documents that are non-standard, the feature will not be deployable and we will have spent 6 months on it” means something specific that can be weighed.

Makes the recommendation with a reason. Not “we recommend option B because of its performance characteristics,” but “we recommend option B because it delivers the needed accuracy, can be in production within the project timeline, and does not create a vendor dependency that would prevent us from switching later. The risk is in the data situation, which we address in phase 2.”

What it looks like in practice

Poorly translated proposal:

We evaluated three architecture options for the document classification system. Option A uses GPT-4o via API with prompt engineering, achieving 71% accuracy on our evaluation set. Option B fine-tunes Mistral-7B on our labelled dataset, achieving 83% accuracy with lower inference cost. Option C trains a custom classifier using our proprietary data, achieving 89% accuracy but requiring 8 weeks of additional labelling effort. We recommend Option B based on the accuracy-cost tradeoff.

Well-translated proposal:

We have three options. The fastest one (Option A, API-based) can be in production in 6 weeks and costs €18k, but delivers accuracy below our commercial threshold and would create a permanent per-call cost. The middle option (Option B, fine-tuned model) hits our accuracy target, takes 12 weeks, costs €65k, and produces a model we own. The strongest option (Option C, custom classifier) exceeds our accuracy target but requires labelling work we cannot do in time and adds 8 weeks and €40k. We recommend Option B: it meets the accuracy threshold, fits the project timeline, and produces an asset we control. The main risk is the labelling dependency in Phase 1, which we need to resolve by week 3.

The information is nearly identical. The second version allows a decision to happen.

Who does this work

In most AI teams, nobody is specifically responsible for translation. Engineers present technical proposals. Leadership approves or defers. The operator’s job, sitting across both worlds, is to make sure the translation happens before the presentation, not during it.

This means writing the commercial framing before the meeting, reviewing the technical team’s proposal through the executive lens, and often ghostwriting the section of the presentation that leadership actually needs to read. It is not glamorous work. It is the work that determines whether AI projects get funded, started, and completed, or get stuck in indefinite review.