Your board wants an AI strategy. Here's the honest one-page version.

This is the first post in a small series I’m calling Board Room Tech Story. It’s for founders and CEOs who have to talk about technology, AI, and engineering in rooms with investors, non-executive directors, and the occasional acquirer. The audience for this kind of conversation has changed in the last twelve months. The bar is higher, the patience for theatre is lower, and the honest answer almost always wins.

Today’s post is the one I get asked about most often, usually two weeks before a board meeting. “What does the AI strategy section actually need to say?”

Why most AI strategy decks fail at the table

The most common mistake is to show up with twenty slides covering market context, model comparisons, a build-or-buy matrix, a roadmap with twelve workstreams, and a risk register that reads like the ISO 27001 audit. The board reads it as one of two things: the founder doesn’t know what to focus on, or the founder is hiding the fact that nothing is actually shipping yet.

Neither is the message you want sitting on the page when the chair flips to “any other business.” Investors who have funded a hundred AI-adjacent companies in the last two years can spot the difference between a thought-through plan and a defensive wall of text. They are tired of the second one.

What they want, mostly, is to be told three things. Where AI is meaningfully changing the business, what bets you’ve taken on it, and what could blow up if you’ve taken the wrong ones. That’s a page. Sometimes it’s a page and a table.

The one-page structure

Here’s the shape. Five sections, each one paragraph or one bullet list. If a section is taking you more than 120 words, you haven’t decided yet.

1. The single sentence on where AI matters for us

One sentence. Not “we’re an AI-first company building the future of work.” That sentence has been used so often it now reads as a confession that the founder hasn’t done the work. The sentence I’m looking for is more like: “AI changes our cost-to-serve in customer support by roughly half, and changes the product surface in onboarding from a 14-step form to a conversation.”

Concrete. Domain-specific. Two places, maybe three. If you can’t name the places, the rest of the doc doesn’t matter.

2. The bets we’ve taken, by category

Three categories, every time:

• Internal leverage. How AI changes how our team works. Engineering velocity, ops automation, the founder’s own use. Not glamorous, but the highest-confidence ROI in the doc.
• Product surface. Where AI shows up in what the customer sees. Features built on AI, features remade by AI, features killed because AI made them irrelevant.
• Defensibility. The thing that makes our position harder to copy because of how we’ve built with AI. Data we collect, workflows we own, distribution we have. The honest answer here is often “nothing yet” and that’s fine to say.

For each category, one or two specific bets. “We’ve rebuilt the support agent assist tool using Claude with our own ticket history as the knowledge base, and reduced average handle time from 9 to 4 minutes” is a bet. “We’re exploring AI to improve customer experience” is not.

3. What we’ve shipped and what’s still in flight

A short table, four columns: bet, status, lead measure, decision review date. Status is one of “shipped,” “in flight,” “validated, not yet built,” “killed.” The lead measure is the one number that tells you whether this bet is working. The decision review date is when you’re next going to look at the number and decide whether to keep going.

This table is the most powerful thing on the page. It separates “we’re doing AI” from “we’re running AI bets with a measurement loop.” It also gives the board a calendar of when to expect updates, which means they ask fewer ad-hoc questions in between.

4. What could go wrong, said plainly

Three risks, not a register of thirty. The honest ones, not the easy ones. Things like:

• The cost curve assumption. If model prices don’t fall the way we’ve assumed they will, the cost-to-serve win disappears. Watch quarterly.
• The vendor concentration. We’re heavy on one provider. The fallback plan is real, not theoretical, and takes about six weeks to flip if we need to.
• The team gap. The two engineers who actually understand our AI plumbing both joined this year. If either leaves, our velocity halves for a quarter. Mitigation in progress, not done.

Boards do not punish founders for naming honest risks. They punish founders for being surprised by ones nobody named.

5. The ask

One line. The thing you want from the board that you can’t get without them. An intro to a specific buyer, a sign-off on hiring an AI lead, agreement to a build-or-buy decision before the next board, comfort with a particular spend envelope. If there’s no ask, say so. Pretending there’s one when there isn’t trains the board to discount the next one.

The four traps that catch most founders

I’ve seen this page written badly more often than well. The mistakes are predictable enough to list.

Trap one: the model league table. “We evaluated Claude, GPT, Gemini, and Llama on the following benchmarks.” Nobody on the board cares. The model is a means, not the bet. Write about what the model lets you do, not which model you picked. If a board member asks about model choice, answer in conversation. Don’t take page real estate from the actual strategy.

Trap two: the roadmap that’s actually a wish list. “Q3: launch AI-powered onboarding. Q4: launch AI-powered analytics. Q1 2027: launch AI-powered everything.” This reads as the absence of a decision. A roadmap is a sequence of bets where the next one depends on the result of the previous one. If your roadmap survives the next bet failing, it’s not a roadmap, it’s a wish.

Trap three: the AI hire that solves nothing. “We’re hiring a Head of AI in Q3.” Boards have learned to ask: to lead what, exactly, that the engineering function isn’t already leading? In most companies of fewer than fifty people, an AI hire is a sign that the engineering team has not been given the brief or the time. Sometimes it’s the right answer. Often it’s a deferral dressed as a decision.

Trap four: the customer story you can’t back up. One or two boards I’ve sat in have heard the line “customers love the new AI feature” followed three months later by “we sunset the feature, retention was poor.” Use numbers, not vibes. If retention on the AI surface is higher than the non-AI baseline, say by how much. If it isn’t, don’t mention retention. The board will work out which one you’re avoiding.

When to write this yourself, when to bring someone in

Most founders can write this page. It’s not technical. It’s a forcing function for decisions you’ve been putting off. The act of writing it is the work. If you can sit down on a Sunday morning, draft the five sections, and feel honest about every line, you don’t need help.

You need help when one of three things is true.

You can write sections one and two but section three (what’s shipped, what’s in flight, with measures) is mostly empty. That means the strategy exists in your head but the engineering function isn’t running against it. A fractional CTO can close that gap in a few weeks, working with whoever leads engineering today. It’s the bridge between “founder has a view” and “company is executing against it.”

You can write all five sections but you don’t believe section four. The risks you’d actually name in a private conversation are worse than the ones you’re willing to put on the page. That gap is the gap your board will eventually find on their own, and it’ll be a worse meeting when they do. Someone outside the operating team can help you tell the truth on the page before someone else does it for you.

You’re heading into due diligence within ninety days. The AI section of a DD pack is held to a different standard than the AI section of a regular board pack. There’s more cross-checking, more interrogation of the underlying engineering, more pressure on the cost curve assumptions. The first time founders see this is during the diligence itself, which is the wrong time to learn. A pre-diligence run-through with a CTO who has been on the receiving end of one is cheap insurance.

The pre-board, dry-run version

One last thing. Write the page on a Sunday, then read it out loud to someone who doesn’t work in the company on the Wednesday. A founder friend, a non-exec, a fractional CTO you trust. The questions they ask are the questions your board will ask. If you can’t answer cleanly, the page isn’t ready.

The point of this exercise isn’t a polished doc. It’s a forcing function. By the end of writing the page properly, you’ve made three or four decisions you’d been deferring. That’s the deliverable. The page is just the artefact.

If you want a second set of eyes

If you’re sitting on a board pack that’s due in the next month and the AI section is the one you’re least sure of, that’s a 30-minute call I can help with. We’ll read your draft, talk through the four traps, and you’ll leave with a sharper version of the page. If it turns out you need more than that, fractional CTO support around board reporting is one of the most common reasons people start an engagement with me.

Book a 30-minute call, or fill in the short brief on the book page if you’d rather start by writing. Either lands in the same place.

Next in this series: the technical-due-diligence question every founder dreads, and the calm three-sentence answer to it.