Playbook · Strategy · All stages

Building an AI strategy tied to business outcomes

A strategy is not a vision statement. It's a set of specific commitments about where you will spend money, time, and attention this quarter — and, more importantly, where you won't. The one-page artifact worth writing has five parts: the outcome, the bets, the boundary, the constraints, and the checkpoint.

Stage
All stages
Discipline
Strategy
Time to read
12 min
Time to do
~2 hours + a review
You'll leave with
One-page strategy
Owner
Executive sponsor + transformation lead
Prerequisites
Access to a real business metric
The trap
Writing a strategy in isolation from what the business actually measures

The premise

The AI strategy most organizations have isn't a strategy at all. It's a list of things AI could do, ordered loosely by how exciting they sound when said out loud. That list is not a strategy. It's the reason most AI budgets produce a portfolio of half-finished pilots instead of a transformed workflow.

A strategy is what stops you buying three overlapping products, funding four unrelated workflows, and pivoting twice before year-end. Not because it's inspiring — because it's decisive. It says this and not that, on purpose, with reasons you can defend in a budget review.

Why a strategy at all

Because AI is the first technology in a decade where the tool is the easy part. You can buy Claude, GPT, Gemini, or an industry-specific model by lunch. You can spin up an agent framework in an afternoon. What you cannot do — cheaply, quickly, or without a lot of organizational pain — is decide which workflows to change, which to leave alone, and how to know whether you were right. That decision is the strategy.

Without one, three specific failure modes are almost guaranteed:

  • Portfolio sprawl. Forty use cases, two funded. Every team has "an AI initiative" and none of them have a baseline. The board asks for a portfolio view; you have a mailing list.
  • Tool-led purchases. Three overlapping products solving the same problem, because two functions bought independently and a third wanted to "not be left behind." The integration bill arrives a year later.
  • The pivot problem. Three strategies in eighteen months, no plan surviving a full quarter. Every new executive brings a new direction, and none of them are wrong — they're just uncoordinated.

None of these are strategic errors. They're the absence of a strategy, expressed three different ways.

The one-page structure

The word "one page" is load-bearing. Not because shorter is better, but because if you can't fit the decisions on one page, you haven't made them yet. What you have is a set of topics you're still working through — which is fine, as a draft, but it's not a strategy.

The honest minimum has five parts. Every part answers a question a board member, a CFO, or a skeptical function leader will ask. Every part is written to be defensible, not impressive.

1 · The outcome

Not "become AI-first." Not "unlock productivity." A specific business metric that already appears in a board deck or quarterly review. The phrase "already appears" is the test: if leadership measures it, the strategy has an anchor. If leadership doesn't measure it, the strategy is asking the organization to trust a metric nobody is tracking.

Examples of the right shape: reduce claims cycle time by 20%. Increase ARR per rep by 15%. Cut non-billable hours by 10%. Not "improve customer satisfaction" — that's a direction, not a metric. Not "drive AI adoption" — that's an input, not an outcome.

One metric, not three. The reason is that a strategy with three primary outcomes has none. If everything matters, nothing prioritizes the tradeoffs that will come. Pick one, and accept that the first version of the strategy will be wrong about whether it's the right one.

2 · The bets

Two to four workflows. Not five. Not ten. Every bet is a hypothesis with three parts:

We believe [specific workflow change] will move [specific metric] by [specific amount], verifiable in [specific window].

Three parts, because each part is a claim that can be tested. Without the workflow change, it's a wish. Without the metric, it's a feature. Without the window, it's permanent, and permanent bets never get retired. With all three, it's a decision — which is what a strategy is made of.

Why two to four and not more

Every bet costs the same two things: attention and a baseline. Five bets means five baselines, five sets of checkpoints, and five chances for the leadership team to be in three different meetings about three different results on the same Friday afternoon. Three bets is the number of things a team can hold without dropping one. If you have ten candidate workflows, the strategy names the three you're doing this quarter, and the other seven are what you're explicitly not doing — which is part three.

3 · The boundary

What you're not doing is a strategic commitment, not a gap. The failure to name the boundary isn't humble — it's expensive. If every idea looks equally worth pursuing, every idea gets equal investment, which means no idea gets enough. The boundary is what makes the bets possible.

Write down three things: which workflows you are explicitly not automating this year, which tools you are explicitly not buying, and which outcomes you are explicitly not chasing. Add one sentence of reasoning to each. The reason is what makes the boundary defensible when someone proposes the opposite in a steering meeting.

  • Not
    Building a customer-facing chatbot this year. Reason: the support volume doesn't justify the maintenance cost until we've validated internal triage first.
  • Not
    Replacing the billing system. Reason: an eighteen-month replacement cycle would consume the AI team's capacity for the entire strategy period.
  • Not
    Automating time entry. Reason: the process is a symptom of a compensation-system problem that AI would formalize, not fix.

A boundary without a reason is a boundary that gets crossed. A boundary with a reason is a conversation the strategy has already hosted — internally, before anyone proposed the alternative.

4 · The constraints

The conditions that must hold for the bets to work — surfaced honestly, not assumed away. Constraints are not obstacles to overcome; they are the sequencing reality that determines which bet starts first.

Four constraint families are worth naming, in order of how often they slow pilots:

  • Data. Which workflows depend on data that isn't ready — stale warehouses, missing labels, inconsistent schemas. Data constraints rarely block the pilot; they block the expansion, six months later, when the pattern library becomes a maintenance burden.
  • Skills. Who can actually build this? If the answer is "we'll hire for it," the answer is that the first two bets slip by a quarter. If the answer is "the AI team," name how many FTEs of their capacity each bet consumes, because that's the real currency.
  • Governance. What decisions require legal, risk, or compliance review? Which reviews are gating, and how long do they take? A 3-month legal cycle isn't a detail — it's a constraint that determines whether a bet starts in Q1 or Q3.
  • Capacity. The honest FTE count for the work. Not "we'll find the time." If whoever needs to run the pilot doesn't have a spare 20% of their week for 8 weeks, the pilot isn't happening — the calendar will confirm this by week three.

The constraints section is what turns the strategy from "aspirational" to "schedulable." When the bets compete for capacity, the constraints tell you which one takes the first slot.

5 · The checkpoint

A specific date and a specific decision criterion. Not "we'll review in Q2" — March 1st, based on the three baselines. Not "we'll see how it's going" — two of three bets must show measurable improvement against baseline to continue in their current form; zero or one means the portfolio is retuned, the strategy is not.

The difference between a checkpoint and a review meeting is that the checkpoint has a decision criterion pre-agreed. The review meeting produces a discussion. The checkpoint produces a decision. Which one you're actually having is determined by whether the criterion was written down before the numbers arrived.

Why we baseline before we set the checkpoint

The checkpoint criterion measures a workflow against a baseline. If the baseline doesn't exist yet, the checkpoint is hypothetical. This is why the sequencing matters: map the workflow → baseline the current state → pilot → hit the checkpoint with real numbers. A strategy that skips the baselining step is a strategy whose checkpoint will be negotiated, not signed.

Worked example

A mid-size professional services firm — 400 people, $120M revenue, professional services, partner-led delivery. Expand to see how the five parts map onto a real one-page strategy.

Show the one-page strategy for a services firm

Note that even the "signed before bets started" line is part of the artifact. A strategy whose criterion is agreed before results is a strategy. A strategy whose criterion is agreed after results is a rationalization.

The trap, in depth

The trap

Writing a strategy in isolation from what the business actually measures. If the strategy commits to outcomes the CEO doesn't track, the strategy is decoration. It will not survive the first budget review — because the first budget review will ask whether the number moved, and the answer will be "which number?"

The trap has five specific forms. Each produces a document that looks like a strategy and functions like a mission statement.

1 · Metrics the leadership team doesn't track

The strategy commits to "improve customer experience" while the CEO's quarterly scorecard tracks NPS, service-level response time, and cost-to-serve. The strategy is now measuring something that isn't on the board agenda. Symptom: the strategy's outcomes don't appear in any existing report. Test: paste the strategy's outcome section onto the last board deck. If it looks like it belongs there, good. If it looks like it was copied from an analyst report, the trap has already fired.

2 · Silent on the tradeoff

Every AI dollar comes from somewhere — another capex program, a headcount plan, or next year's budget. The strategy that doesn't acknowledge the tradeoff is a strategy that assumes AI is free. Symptom: the strategy never mentions what it's NOT doing (see the boundary). Test: ask the CFO what AI is displacing in the budget. If they can't answer, the strategy is answering a question nobody asked.

3 · Tool names instead of workflow names

"We will use Claude for customer support." That's a purchase decision, not a strategy. The workflow is: drafting first replies to routine tickets, with a specific data-in and HITL posture and a metric. The tool is a choice inside the workflow, not a substitute for it. Symptom: the strategy mentions specific vendor names before it mentions specific workflow changes. Test: cover the tool names. Does the strategy still make sense? If not, they were carrying the strategy.

4 · No "no"

The strategy names what you'll do and never names what you won't. The implicit hope is that "we'll pursue opportunities as they arise" reads as flexible and strategic. It reads as "we have no idea what we're prioritizing." Symptom: the boundary section is missing, or contains only vague hedging ("we may consider future opportunities"). Test: every "we will" without a paired "we won't" is a commitment that hasn't been negotiated with the rest of the organization.

5 · No checkpoint, or a checkpoint with no criterion

"We'll review in Q3." Review what, against what, and decide what? A checkpoint without a pre-agreed criterion becomes a post-hoc negotiation about what "success" means — usually resolved by whoever has the most executive sponsorship, not by the data. Symptom: the review meeting ends with "let's continue and revisit in another 90 days" more than once. Test: can you name the specific number that constitutes success, and the specific number that constitutes failure, before the first pilot starts? If not, there is no checkpoint.

What to do about it

The single most useful intervention is the pre-commitment conversation. Before any baseline is measured, ask the executive sponsor: "If the numbers come back and this pilot looks hard to succeed, are we still doing it?" If the answer is "yes, we're doing it because it's the right thing to learn" — good, the strategy is real. If the answer is "we'll see" — the strategy has not yet been written, and the document in front of you is a draft of something else.

Quality bar — what "good" looks like

  1. Fits on one page. Actually. Printed. Not "conceptually one page because we can compress the bullets."
  2. The outcome already appears in a board or executive scorecard. Not a metric you invented for the strategy — a metric the leadership team was already tracking.
  3. Every bet is a hypothesis with three parts — workflow change, metric, window. Two bets is acceptable; five is not.
  4. The boundary has three or more named exclusions, each with a one-line reason. If the boundary is shorter than the bets, it isn't a boundary — it's a caveat.
  5. Every constraint names an owner and a date. "Data taxonomy cleanup by Month 2, operations" is a constraint. "Data quality is a concern" is not.
  6. The checkpoint has a specific date, a specific number, and a signature. Signed before the pilots started. If the signature is missing, the checkpoint is a hope.
  7. No tool names in the outcome or bets section. Tools can appear in the constraints (as platform dependencies) but not as the strategy's purpose.

Red flags — signals the strategy isn't done yet

If any of these are true, do not circulate the strategy
  • The strategy fits on three pages and everybody thinks it's tight. It's not tight. It's unfinished. A strategy that's been through twelve review cycles grows; a strategy that's ready is one page because every other word got cut.
  • More than four bets. Either the strategy is unfocused, or some bets are actually sub-bets of others. Both mean: not done.
  • "AI-first" or "AI-native" appears without a specific definition. These are mission-statement words. If the strategy uses them, they need qualification — AI-first compared to what, and in which workflows?
  • The boundary section is missing or defensive. "We'll remain open to opportunities" is not a boundary. A real boundary names three or more things you're not doing, each with a reason.
  • The checkpoint date is more than 12 months out. A 12-month checkpoint is the same as no checkpoint. Set it at 6–9 months, and if the pilots aren't ready by then, that's the result.
  • Nobody can name the previous quarter's results. If the last strategy cycle didn't produce a decision, this one won't either. Fix the review cadence before writing the next strategy.

When to revise — this is not a one-time artifact

A one-page strategy is not written once. It's revised — quarterly, or when one of the bets hits its checkpoint, or when a constraint the strategy assumed has changed. The strategy is supposed to be durable across quarters and revisable across years.

Three triggers warrant revision, and only three:

  • A checkpoint produces a decision that changes the portfolio. Retire a bet, add a new one, or shift resources between them. The strategy is edited, not rewritten.
  • A constraint materializes differently than assumed. Data readiness was going to take 3 months and took 6. Governance shipped a new policy that changes what bets are legal. The constraints section gets updated and the bets re-sequenced.
  • The business outcome itself changes. The board no longer prioritizes non-billable hours — it prioritizes customer retention. The outcome line changes; the bets probably survive; the boundary probably doesn't.

What does not warrant revision: a new tool releases, a competitor announces an AI feature, a consulting firm publishes a report about AI adoption trends. Those are inputs to how the strategy is executed, not reasons the strategy itself is wrong. Teams that revise the strategy on every external signal end up with — as the trap section says — three strategies in eighteen months and none of them surviving.

What this sets up

A one-page strategy is the artifact every subsequent decision in the program checks against. It's what a pilot sponsor cites when the pilot scope wants to creep. It's what the CFO references when the AI budget line is questioned. It's what the steering committee consults when a new proposal lands that isn't in the plan.

  • The workflow map. The strategy names the workflows; the next playbook maps them. Without the strategy, the mapping exercise has no shortlist and the first candidate picked is usually the loudest, not the best.
  • The baseline. Each bet carries a metric and a window. The baseline playbook produces the number the bet's hypothesis will be tested against.
  • The adoption plan. When a bet succeeds, the workflow goes into production. The adoption playbook (Expand stage) names the operators, strategists, and HITL posture per team — anchored to the workflow the strategy sanctioned.
  • The portfolio review. When the checkpoint arrives, the review is a signature check against the pre-agreed criterion — not a debate about whether the results "actually count."

The next playbook

Mapping a workflow before automating it

The strategy names workflows. The next move is to map one — before you touch a tool. The workflow map is what makes the bet testable, the baseline measurable, and the HITL decision possible.

Read: mapping a workflow before automating it

Common questions

How long should a one-page strategy last before it's revised?

Quarterly cadence, with the option to revise earlier if a checkpoint produces a decision. Most strategies survive their first two quarters essentially intact — the bets change at the edges, the outcome and the boundary hold. A strategy that needs revision every month isn't a strategy; it's a running commentary. A strategy that hasn't been touched in a year has been abandoned, not adopted.

What if leadership wants an "AI vision statement"?

Give them both. A one-paragraph vision statement on top, the one-page strategy under it. The vision gets them through a conference keynote; the strategy gets them through their next board meeting. Both are legitimate communication artifacts, but only one is a decision. Say that explicitly in your draft — it prevents the vision from being shortened into the strategy on the third pass through leadership review.

Should the strategy mention specific tools?

Not in the outcome or bets section. In the constraints section, yes — as a dependency ("bets 1 and 3 run on the existing enterprise contract; bet 2 requires a new vendor, 8-week procurement"). The distinction matters: naming the tool in the outcome turns the strategy into a procurement decision. Naming it as a constraint keeps the strategy focused on what actually changes in the workflow.

What if we don't have a business metric to anchor to?

Then the strategy has surfaced a bigger problem, and this is the moment to say so. The absence of a metric isn't a reason to invent one — it's a reason to fix the measurement system before investing in AI. It's cheaper to fix the metric than it is to run a two-year AI program against a moving target. If leadership won't prioritize fixing the metric, that's information too: the AI program is unlikely to be defended in a budget cycle, no matter how well it runs.

We already have a strategy — how do we test it?

Run it against the five parts. Does it name one metric leadership already tracks? Does every bet have a workflow, a metric, and a window? Does it name what you're not doing with reasons? Does every constraint have an owner? Is there a signed, dated checkpoint with a specific criterion? If the strategy fails on any of these five, that's the revision to make. It usually doesn't need a rewrite — a 20-minute pass against the five-part test is enough to see what's missing.

Further reading and feedback

Search and jump to

↑↓ to move Enter to search everything