Back to the blog

What a good strategy readout contains

StrategyPractice

Leadership teams have seen a lot of strategy decks. Most of them are handsome, plausible, and filed. The reason is not that the thinking was bad. It is that the deck was built to present, not to decide, so the meeting ended with everyone informed and nothing chosen.

A readout that works is built the other way around. It exists to get a decision made in the room, and to leave behind the reasoning so the decision holds up later. Here is what ours contain.

The situation, in one page

Before any recommendation, a short statement of where the organization actually is: what AI is already in use and by whom, what has been tried and what happened to it, where time and money go today, and what the leadership team said it wanted when we asked them separately. The last part is often the most useful page in the document, because leaders rarely hear each other's version.

If this page is wrong, the rest is wrong, so we get it agreed first.

The roadmap, as a sequence

Then the initiatives, in order, with the reason for the order. Not a ranking. Each item carries its value estimate in units the business already measures, its effort to reach production with evidence, its risk and reversibility, and what it depends on. Item one is chosen for a specific reason, usually that it produces evidence fastest while building something the later items need.

Every estimate has its assumptions written next to it. When one breaks, the sequence can be revisited without starting over.

The clear noes

A readout that only says yes is a sales document. Ours list the ideas that were on the table and did not hold up, and why. The idea everyone was excited about that depends on data the company does not have. The vendor pitch that solves a problem the company does not have. The initiative that would work but is not worth what it would cost.

Saying no in writing is the most valuable thing a strategy engagement does, and it is the thing internal teams find hardest to do for themselves.

Build, buy, or partner, per item

For each initiative, the call on how it gets done, with the reasoning. Which parts are bought, which are built, which need a partner and what the exit from that partner looks like. Where a vendor evaluation was part of the sprint, the comparison is in the appendix and the recommendation is in the body.

The first move, specified

The first initiative is written to the point where a team could start on Monday: the outcome, the acceptance criteria, the owner on the client side, the evaluation that will judge it, and the shape of the engagement to deliver it. If the readout says "start here" but the team would need another planning exercise to actually start, the readout is not finished.

The case for the board

Finally, a short section written for the people who were not in the room: what is being proposed, what it will cost in the first phase, what evidence will exist at the end of that phase, and what the decision point is after it. This is the page that gets forwarded, so it is written to be forwarded.

The session, not the document

The readout is delivered in a working session, not sent as a file. The session has one purpose: leave with a decision on whether and where to start. We do not accept "let's take it away and think about it" as an outcome. The thinking has been done; that is what the sprint was for. If the decision is no, that is a fine decision and we say so.

A strategy that gets decided in the room and written down with its reasons is one that survives contact with the quarter. A deck, however good, is one that gets filed. The difference is in what the document is for.

Tell us where AI is stuck.

One conversation — we’ll tell you if we can help, and what we’d do first.

Book a call