Ten minutes with the client's leadership: turning pilot results into a signed decision

Picture this. You have just finished a six-week pilot at a logistics company. The document-reading agent works, the eval suite is green and the operations team has got used to it. Then a calendar invite arrives: the head of operations is giving you 10 minutes on Thursday afternoon.

Those 10 minutes settle what happens to six weeks of work. The pilot might go to production, or it might sit in a shared folder for good. Will Larson, who writes the blog Irrational Exuberance, observes that executives often make the call in the meeting itself, and you rarely get another chance to discuss it before the decision is made.

So this is not an optional soft skill. Your code only creates value once someone on the client side signs off on running it for real. This guide shows how to build those 10 minutes, one minute at a time.

Executives approve recommendations, not results

Engineers tend to tell the story in chronological order: what the problem was, what they tried, what broke, which number they ended up with. The request for a decision arrives in minute eight. By then the audience has been on their phones for a while.

Larson advises the reverse. In his view, the clearest structure always puts the overall point first, followed by the supporting points underneath it. This is Barbara Minto’s Pyramid Principle. The opening follows SCQA: Situation, Complication, Question, Answer.

Nancy Duarte, a presentation specialist, gives similar advice: open with the findings and the recommendation, and say at the start how you will use the meeting’s time.

Larson also makes a point that is easy to miss. You cannot build consensus in the room unless there is a recommendation for people to get behind. Bring only a problem and the room will argue. Bring a recommendation and they will amend it, then sign.

The 10-minute script, written out sentence by sentence

Go back to the hypothetical example above. The pilot processed 2,000 customs documents. The agent completed 1,640 of them on its own, or 82%, and routed the remaining 360 to human reviewers.

Average handling time per document fell from 9 minutes to 2. The decision you need is permission for the agent to write to the production ERP at one warehouse, with someone on the client side owning the review process.

Minutes 0–1: the recommendation and the ground rules. “I’m asking you to approve two things today: letting the agent write to the ERP at the Binh Duong warehouse, and making the documentation team lead the owner of the review process for 8 weeks. I’ll present for 6 minutes and leave the remaining 4 for your questions.” Duarte argues that when the audience knows there will be time for questions, they are more likely to let you get through your key points without interrupting.

Minutes 1–3: SCQA. Situation: the documentation team keys everything in by hand. Complication: peak season is coming and there is no time to hire more staff. Question: should the agent go into live operation before the peak? Answer: yes, on the two conditions just stated.

Minutes 3–6: three pieces of evidence, one sentence each. The agent handles 82% of documents on its own. Any document below the confidence threshold cannot be written to the ERP until a person has reviewed it. Every failure seen during the pilot now has a safeguard, with details in the appendix.

Minutes 6–7: the options and the cost of waiting. Option A is to deploy now at one warehouse. Option B is to run the pilot for another 4 weeks, which means going into peak season still keying documents in by hand. Say clearly which option you recommend and why.

Minutes 7–10: Q&A and the close. Your last sentence repeats the recommendation from the first minute, word for word. Then you stop and wait for an answer.

The hardest part is translating technical language into decision language:

What engineers tend to say	What the executive needs to hear
F1 on the extraction step is high	82% of documents need no human touch
There’s a human-in-the-loop fallback	Any uncertain document is always reviewed by a person before it enters the ERP
We need more system access	We need you to approve write access at one warehouse for 8 weeks
What do you think of the results?	Will you approve option A today?

The real work happens before the meeting

Because there is no second chance, most of the work has to be done before you walk into the room. Larson calls the practice of aligning with stakeholders ahead of a presentation nemawashi.

In the example above, you would meet IT security separately about write access to the ERP, and meet the documentation team lead to make sure they agree to take on the process-owner role.

If someone in the room hears the recommendation for the first time in the main meeting, there is a high risk the answer becomes “let’s pick this up next week.”

Only then do you get to the deck. Duarte recommends putting a short summary page of the key points up front and treating everything else as appendix. Architecture diagrams, eval tables and failure lists all move to the appendix, opened only when someone asks.

To check whether the summary page is tight enough, use Duarte’s trick: imagine your whole slot has been cut to 5 minutes. Whatever survives the cut is the presentation.

Kiger writes on LeadDev that distilling your thinking like this also forces you to understand the problem better. If you can’t yet write your recommendation in one line, you probably don’t understand the project deeply enough.

The meeting isn’t over when you leave the room

Kiger stresses that important points have to be repeated, and that everything needs groundwork beforehand and follow-up afterwards. On the same day, send a short email confirming the decision, the owner, the scope and the next checkpoint.

That email turns a nod in the meeting room into a written commitment the whole client team can rely on.

If the answer is “not yet” or “next week,” don’t leave the room without asking exactly what they need in order to approve it and whom else you should meet. In that case, the follow-up email records those conditions and the date you will come back with answers.

Mistakes that waste the 10 minutes

The most common mistake is opening with the architecture. Executives need exactly the information they will use to decide because, as Kiger writes, their time and attention are limited. The second is bringing a problem into the room with no recommendation, which turns the meeting into a brainstorm that goes nowhere.

The next one is harder to spot: piling on numbers. Three pieces of evidence carry more weight than twelve metrics, because people can remember them. The last is asking for the decision vaguely. “What do you think?” is not a decision. “Will you approve option A?” is.

This week’s exercise

Take a piece of technical work you finished this quarter, such as a migration or a new feature, and rewrite it as a 10-minute script using the structure above. The first sentence has to answer one question: who needs to approve what, and by when?

The same script is worth taking into interviews if you are aiming for an FDE role. When asked about a past project, open with the decision your results helped someone make, then get to the technical side. On your CV, replace “strong communication skills” with exactly that kind of sentence.

Six weeks of pilot results stay the same however you present them. What decides whether they reach production is the first sentence you say in the meeting room.