AI strategy consulting that ships
A strategy with the sequencing argued out, the build-vs-buy calls made, and a route through the parts that usually stall: production, change, and adoption.
Most AI strategy engagements end with a roadmap nobody implements. The people who wrote it have never watched a model behave badly in production, so they sequence for how the plan reads rather than for how the work lands. Sequencing is where these documents fail, and getting it right requires having built something.
Seven years of strategy work at Kearney: restructurings and commercial diligence across Asia, Europe, and the Americas. Three companies since, each of which required me to build the AI system rather than commission it.
Engagements are bespoke, because the useful scope depends entirely on which decision is currently blocking you. What follows is the range of areas I cover and the elements that typically make up the work.
Areas of strategy
Enterprise AI strategy. The portfolio view across the business: which bets are worth making, what each is worth, and the order that respects the dependencies between them. This is the right scope when you have more proposed use cases than capacity and no defensible way to rank them.
Function transformation strategy. Rebuilding how a single function operates once AI is doing part of the work. A customer success transformation strategy, for example: which parts of the motion change, what the team structure looks like afterwards, what happens to the people currently doing the displaced work, and how you get there without a service cliff halfway through. The same shape applies to claims operations, collections, sales development, and the finance close.
Product and platform strategy. AI inside what you sell rather than inside how you operate. What to build into the product, what it does to your pricing and packaging, and which capabilities stay defensible once the underlying models improve again.
Build-versus-buy and vendor strategy. Where a vendor fits, where an in-house build earns its cost, and what you pay to switch if the call turns out wrong. Buying is usually correct, so I treat it as the default and concentrate the work on the exceptions.
Data strategy. Which data assets become defensible advantages once models commoditize the reasoning, what you are not instrumenting that you should be, and what has to be true about your data before the rest of the plan is viable.
Operating model and org design. Who owns AI, where those people sit, how existing roles change, and what governance the structure needs to carry. This is the usual scope when AI is already happening in four places with no owner.
Governance and risk strategy. Decision rights, approval paths, policy that survives contact with a real incident, and your regulatory position in the sectors and jurisdictions you operate in.
Adoption strategy. Getting the organization to actually use what you build, which is a different problem from building it. I cover it below, because that is where most of the value quietly leaks away.
Typical elements of an engagement
Because I build the scope around your decision, no two engagements contain the same set. These are the components most often in scope:
- An opportunity map with the value sized and the assumptions written down so you can challenge them
- A prioritized, sequenced plan where each item carries the reason it sits in that position
- Build-versus-buy calls with the reasoning and the switching cost attached
- A target operating model: who owns what, and how roles change
- An evaluation framework your team applies to future vendors without me
- A business case in the form your board or investment committee expects
- A production transition plan, covering ownership, monitoring, and the failure modes
- A change management and adoption plan for the functions whose work changes
The parts that are actually hard
Most strategy documents stop at the roadmap and hand the difficult third to someone else. These three are where engagements fail, so they belong in scope from the start.
Transition to production. A working pilot and a running system are different animals. Getting from one to the other means naming an owner who is accountable when it misbehaves at two in the morning, deciding what gets logged and who reads it, agreeing the quality bar and what happens when a release misses it, and accepting that the pilot’s numbers will get worse under real traffic and real edge cases. Organizations accumulate successful pilots for years without ever crossing this line.
Change management. When AI takes a meaningful share of a function’s work, you are asking the people in that function to do a different job, and often a smaller one. Treating that as a communications exercise is the reliable way to lose your best operators in the middle of a transformation. This means being explicit about what happens to roles, deciding it before the rollout rather than during it, and being honest with the people affected earlier than is comfortable.
AI adoption. The failure mode is quiet: the new system ships, and the organization keeps the old process running beside it because people trust the old process and nobody ever told them to stop. Adoption work means finding where the parallel process survives, understanding what makes people distrust the new one, and closing that gap rather than mandating usage and watching compliance theatre replace the old workflow.
Where I am the wrong choice
If you need a team of forty for a multi-year global programme, a large firm is the correct answer. If you have already decided and want validation, that is a cheaper conversation than an engagement. And if what you need is someone to own the implementation, this is not that service.
Proof, not promises
All client stories →AI Employee Assistance Chatbot
Designed and built a chatbot for a 40,000-employee organization to address questions about policies, asset tracking, and other internal tasks. Integrated with an updated knowledge base with an admin panel and the ticketing interface to create and track support tickets.
Leading financial institution in India
AI Vision for Fraud Prevention
Built a semantic image search interface to detect and present potential fraudulent gold loan applications to auditors for real-time fraud prevention.
Leading gold loan provider
Auto-scaling ML Inference
Designed and deployed a dynamically auto-scaling application for low-cost inference of ML jobs on geospatial data using GCP Cloud Run.
Public markets investor in MENA
Questions
What areas of AI strategy do you cover? +
Enterprise portfolio strategy (which bets across the business, in what order), function transformation (rebuilding how one function operates, such as customer success, claims, or collections), product and platform strategy (AI inside what you sell), build-versus-buy and vendor strategy, data strategy, operating model and org design, governance and risk, and adoption strategy. Most engagements combine two or three of these rather than covering all of them.
What does an engagement produce? +
It depends on which areas are in scope, because the work is bespoke. The common elements are an opportunity map with the value sized and the assumptions written down, a prioritized and sequenced plan, build-versus-buy calls with the reasoning and the switching cost attached, a target operating model, an evaluation framework your team keeps and applies without me, a business case in board-ready form, and a plan for moving from pilot to production.
How is this scoped if it is bespoke? +
In the first conversation I establish which decision is actually blocking you, and build the scope around that. A company choosing between three vendors needs something different from one that has forty proposed use cases and no way to rank them. I would rather scope narrowly around a live decision than sell a full-spectrum review nobody reads.
Can you give examples of engagement types? +
A customer success transformation strategy: which parts of the CS motion AI changes, what the team looks like afterwards, and how you get there without a service cliff during transition. A claims operations strategy for an insurer. A build-versus-buy call on a document extraction platform. An operating model design for a company that has AI scattered across four teams with no owner. A board-level AI position for a company about to be asked hard questions by its investors.
Where do most AI strategies actually fail? +
Three places, and they are the parts most strategy documents skip: the transition from a working pilot to a production system with real ownership, the change management needed when a function's work materially changes, and adoption, where the organization keeps the old process running alongside the new one. Any engagement I run treats these as scope rather than as implementation detail for someone else.
Do you help with execution? +
I stay at the decision layer: what to do, in what order, and how to judge whether a vendor or an internal team is delivering it. I will sit in on vendor calls and review architecture proposals. I am not taking the build itself, so if what you need is someone to write and own the code, I will say so early.
How is this different from a large consulting firm? +
Scale and staffing. A large firm gives you a team, a longer runway, and an analyst layer producing more documentation. You get me at partner level for the whole engagement. If you need forty people to run a global transformation programme, hire the firm.
Let's talk
30 minutes, no slides. We'll work the specific decision you're facing.