Most AI strategy decks are written backwards

Every few months a team presents an “AI strategy” that begins with a slide titled “What AI Can Do For Us.” A grid follows: departments across one axis, AI use cases down the other, cells filled with ticked boxes. The deck ends with a roadmap. Quarter one: pilots. Quarter two: scale.

The strategy never ships.

The capability-first trap

A capability-first strategy begins with one question: here is a model that can summarise text, extract structured data, generate copy, write code, and answer questions. Where can we apply it?

That question is not without value. But it has a structural flaw: it starts from the technology and searches for problems, rather than starting from the problems and asking whether technology helps. The grid fills quickly. Slides multiply. The strategy looks done before anyone has made a single real decision.

A strategy is only a strategy when it chooses: this workflow over that one, this quarter over next, this user segment before the others. A capability-first AI strategy produces the appearance of choices without making them.

Three tells — all visible in the first three slides

A backwards AI strategy is usually identifiable within the first few minutes of a review.

Tell 1: The capabilities grid

Department names down one axis, AI use cases across the other. Marketing: content generation, personalisation, ad copy. Support: ticket summarisation, chatbot deflection, sentiment analysis. Engineering: code review, documentation, test generation.

Nothing in the grid is technically wrong. But the same grid could describe almost any software company. It was assembled by reading a model provider’s documentation, not by analysing where the company’s time, money, or margin actually goes. Two companies in completely different industries will produce nearly identical grids.

Tell 2: The ‘AI-powered’ feature roadmap

Every existing feature has been prefixed with ‘AI-powered.’ AI-powered search. AI-powered recommendations. AI-powered onboarding. This is a product roadmap written backwards: features first, product thinking second. Prefixing an existing feature with ‘AI-powered’ is not a product decision. It is investor relations copy dressed as product strategy.

Tell 3: The vendor comparison slide

A matrix comparing the major LLM providers on context window, cost per million tokens, and benchmark scores. This slide appears early in backwards decks because it creates the impression of a hard analytical decision. But a real vendor decision requires weeks of testing against your specific task and your data. A team that started from the problem would not know which vendor was right until they had prototyped. The comparison slide is a tell because it appears before that work has been done.

What the AI strategy failure rate is actually measuring

Deloitte’s 2026 State of AI in the Enterprise found that 95% of generative AI pilots fail to reach production. The number surprises people inside the field. It shouldn’t.

Capability-first strategies produce capability-first pilots. A pilot that asks ‘can this model do X?’ produces a quick, clean answer: yes, with caveats. The pilot ends. Then someone asks what happens when users encounter the caveats. Nobody planned for that. The model goes live. Users hit the caveats. Adoption drops. The pilot is declared complete, but the feature is dead.

The failure is logged as: ‘the model wasn’t accurate enough’ or ‘adoption was lower than expected’ or ‘data quality issues.’ All of those can be true. But the root cause is almost always that nobody started by asking what problem they were solving, for whom, at what acceptable error rate, and measured how.

What problem-first actually looks like

A problem-first strategy starts from one question: what is the most expensive thing your company does repeatedly that does not require genuine human judgement?

‘Expensive’ means time × wage × volume. A task that takes 20 minutes, involves someone at Rs 60,000 a month in total comp, and happens 400 times daily is a candidate worth examining. A task that takes two minutes, happens twice a week, and still requires a human to review every output is not.

‘Does not require genuine human judgement’ is the constraint that matters most. AI is a fast, cheap, high-variance pattern-matcher. It handles tasks with stable schemas and checkable right answers well. It is unreliable on tasks that require weighing incommensurable values, navigating genuine ambiguity under accountability, or producing genuinely novel output. Knowing which kind of task you have is more useful than knowing which model to use.

Once you have the right task, the questions become concrete: what does correct output look like? At what error rate does the system become worse than the person it replaces? Who reviews the output when it is wrong? What does wrong look like? Those things are specifiable. They can be measured. They become the acceptance criteria for the pilot, which is why the pilot has a chance of actually shipping.

The question that resets any AI strategy review

There is one question worth raising the next time you sit through an AI strategy review: ‘What does a failure look like, and who is accountable for it?’

A backwards deck cannot answer this. Failure modes were never in scope, because the deck was assembled by exploring capabilities rather than reasoning about deployment. The question is met with silence, or with general talk of ‘monitoring’ and ‘feedback loops’ — processes, not failure definitions.

A problem-first strategy can always answer it, because it started there. The task is specified. The error budget is defined. The review process is planned before launch, not after. That is not pessimism. It is the minimum viable spec for a system someone will actually use.

The 5% of AI projects that reach production have this in common: they started with a problem expensive enough to justify the build, and they knew what failure looked like before writing the first line of code.

The capability-first approach is not a bad place to learn about the technology. It is a bad place to write a strategy.