Millennial AI
AI Strategy

AI strategy that ships: what mid-market companies get wrong

Abhinav PalaparthyMarch 10, 202612 min read

TL;DR

  • --Strategy decks that ignore implementation constraints are fiction.
  • --Start with operational readiness, not technology capability.
  • --Target workflows where manual effort is highest and error cost is measurable.
  • --Adoption speed matters more than feature completeness.

The strategy deck problem

A whole industry exists to tell mid-market companies what AI could do for them. The decks are polished, the TAM slides are enormous — Stanford's AI Index Report tracks just how fast industry investment is growing — and most of it stays in the slide deck. The reason is almost always organizational. As McKinsey's State of AI survey found, the gap between a proof-of-concept and a production system comes down to change management, data quality, and whether leadership agrees on what they want.

We have seen companies spend six figures on strategy engagements that produce frameworks the team opens once and forgets. Same story each time: ambitious scope, underspecified dependencies, zero visibility into whether the initiative is working or just running.

The pattern usually looks like this. An executive attends a conference, gets excited about AI, and hires a firm to produce a roadmap. The firm interviews stakeholders for two weeks, builds a deck with 80 slides, and presents a phased plan that assumes ideal conditions at every step. The executive feels good. The operations team reads it, recognizes none of their actual constraints, and puts it in a shared drive. Six months later, nothing has shipped.

The failure is not ambition. The strategy was designed for a version of the company that does not exist yet. Good AI strategy starts with the company as it operates, not as leadership wishes it operated.

Start with operational readiness

The companies that succeed with AI do something unglamorous first: they audit their own capacity to absorb change. Which teams are already stretched? Which data pipelines are fragile? Where does the institutional knowledge live? (Usually in three people's heads, not in documented processes.)

Operational readiness is an honest assessment of how much disruption the organization can handle in a given quarter. We typically advise clients to target two meaningful AI-driven workflow changes per quarter, at most. The technology can move faster. People need time to trust new tools before they rely on them.

Data pipeline fragility is the most common bottleneck we encounter. Companies assume their data is ready because it exists in a database somewhere. When you dig in, the reality is different. The CRM has 40% of contacts missing industry classifications. The ERP data has three different naming conventions for the same suppliers because three different people entered them over five years. The analytics warehouse runs on a series of SQL scripts that one engineer wrote in 2021, and that engineer left last year. Nobody has touched those scripts since. They run on a cron job and everyone prays.

This is normal. Almost every mid-market company we work with has data infrastructure built incrementally by people solving immediate problems. It works until you try to build something on top of it that requires consistency and reliability. AI requires both.

Institutional knowledge is the other hidden risk. We ask clients: if your three most tenured operations people left tomorrow, how much of their decision-making logic is written down? The answer is almost always "very little." They carry the exception-handling rules, the workaround for that one vendor's invoicing quirk, the knowledge of which customers need special treatment and why. An AI system that skips this knowledge will produce outputs that look correct but miss the nuances that matter. Documenting these rules before deployment is tedious. Skipping it is more expensive.

Pick the right workflows

The AI investments that pay off share a profile: workflows where manual effort is high, error cost is measurable, and the people doing the work would welcome automation. Invoice reconciliation, support triage, content QA, compliance document review. Not exciting projects, but they add up.

We use a simple scoring matrix: time spent per week, error rate, cost of errors, and team sentiment toward the current process. If a workflow scores high on all four, it is almost certainly worth automating. If it scores high on time but low on error cost, the ROI case falls apart quickly.

Three examples show how the matrix plays out. AP invoice matching scores high across the board because each error creates downstream payment delays and supplier friction, and the team finds the work repetitive and thankless. Support ticket routing is similar: misrouted tickets bounce between teams, adding roughly 20 minutes each, and the support team would rather spend time solving problems. Quarterly financial reporting is the counterexample: you cannot have an AI making judgment calls on revenue recognition, the process happens infrequently, and the finance team is deeply skeptical of automation in their domain.

WorkflowTime/WeekError RateError CostTeam SentimentVerdict
AP invoice matching25+ hrs2–5%High ($200+/error)Wants automationStrong candidate
Support ticket routing15+ hrsModerateMediumWould welcomeStrong candidate
Quarterly reportingHighNear zero toleranceVery highSkepticalNot now

The matrix also helps you sequence initiatives. Start with whatever scores highest overall, prove the value, and use that win to build credibility for the next project.

Adoption over features

Feature-complete systems that sit unused cost more than simpler systems everyone relies on. Engineering-led organizations resist this idea, but it holds up.

The measure that matters is adoption speed: how quickly does the team move from "trying it" to "relying on it"? When adoption stalls at the pilot phase, the issue is rarely model accuracy. It is usually that the interface requires too many steps, the output format clashes with existing workflows, or the team was left out of the design process.

As Harvard Business Review notes, every AI strategy should define adoption milestones with the same rigor it defines technical milestones. A Gantt chart with deployment dates and zero adoption targets is a project already drifting.

The adoption curve we see most often has three phases. First two weeks: enthusiasts try it and give feedback. Weeks three through six: the broader team uses it intermittently, often reverting to the old process when under time pressure. Weeks six through twelve: if the tool is well-designed, the new process becomes default and the old process feels slow. If you are still in phase two after eight weeks, something is wrong with the tool, the training, or the workflow fit. Do not push harder on adoption. Go back and fix the friction.

One pattern that accelerates adoption: let the team customize the AI's output format. A support team we worked with rejected an AI triage tool because it presented results in a format that did not match their ticketing system's layout. Same information, different arrangement. Once we matched the format to what they were used to seeing, adoption jumped from 30% to 85% within two weeks. Small details like this matter more than model accuracy improvements.

Was the strategy engagement worth it?

A strategy engagement should produce measurable results within 90 days, or it was an expensive document. We are blunt about this with clients because the industry has a credibility problem. Too many strategy projects get evaluated on deliverable quality ("great deck") rather than business impact.

The KPIs that matter are operational, not strategic. Did at least one AI-driven workflow reach production use within 90 days of the strategy being finalized? If not, the strategy was either too ambitious or too disconnected from reality. What is the measured time savings or error reduction in that first workflow? This needs a number, not an estimate. If you did not baseline the process before deployment, you cannot credibly claim improvement after.

What is the adoption rate among intended users? Not logins. Not "trained users." Actual daily or weekly active usage compared to the eligible user base. A tool with 90% accuracy and 20% adoption delivers less value than a tool with 80% accuracy and 90% adoption.

Has the engagement produced a prioritized backlog of the next three initiatives, with estimated effort and expected ROI for each? A strategy that identifies one project is a project plan. A strategy that sequences multiple opportunities with clear reasoning for the order is actually strategic.

Vanity metrics to ignore: number of use cases identified (anyone can brainstorm a long list), executive satisfaction scores (the exec is not the user), model performance benchmarks disconnected from business outcomes (99% accuracy on a task nobody needed automated is worth zero).

Many strategy engagements are designed to justify themselves rather than produce results. The consultancy gets paid for the deck. Whether anything ships is someone else's problem. We think that model is broken, which is why we tie our engagements to implementation milestones.

What we tell clients on day one

Start small, prove value, expand scope. It sounds conservative, but it is the fastest way to earn buy-in. A single automated workflow that saves 15 hours per week and cuts errors measurably will do more for your AI program than a roadmap that tries to change everything at once.

The companies furthest ahead started with modest scope. They shipped something useful in the first 60 days and built conviction from there.

Abhinav Palaparthy

Abhinav Palaparthy

Partner, AI & Data

Spent years at McKinsey watching AI strategies die in slide decks. Now he builds the systems himself. Runs ai4builders on the side and routinely tells clients their first AI idea is wrong, then shows them why the second is worth 4x more.

LinkedIn
Try our free AI assessment