Home / Our roles / AI Product Management
AI Product ManagementGetting AI adopted by the people who will use it
A delivered tool is not an adopted tool. This practice covers the gap between the two: mapping what teams already do with AI, writing usage rules, training role by role, and measuring whether the tool actually serves once the spotlight has moved on.
- Real usage mapped
- Role based training
- Measured adoption
Key challenges
Most AI tools that fail are not badly built, they are badly adopted. Teams already have usages, often informal and never recorded, while leadership discovers the topic through a framing memo. AI change management connects the two: it starts from what is actually happening, writes rules everyone understands, and tracks whether the usage holds once the attention has moved elsewhere.
Usages already there, never mapped
Before any official project, people are already using a model to write, summarise or code, with no written frame and often without leadership knowing. Ignoring these usages means governing the topic half blind.Resistance that has a reason
A refusal to use a tool is almost never irrational. It usually says that a task has become slower, that some information disappeared from the screen, or that nobody explained what happens to the time freed up.Generic training that does not stick
A group session built on a standard demo leaves everyone wondering how it applies to their own job. Adoption is won on real cases, not on an example that looks like the job from a distance.No measurement of real adoption
An installed tool is not a used tool. Without a usage indicator tracked over time, the adoption question gets settled by impression rather than by a checkable fact.
What your PO / PM does
- 1
Map real usage
Record what teams already do with AI, including outside the official tools, and what they would like to do if a frame existed. - 2
Write clear usage rules
Put in writing what can be handed to a model, what never should be, and who decides when a new case shows up, replacing individual improvisation with a shared rule. - 3
Train role by role, with internal champions
Build short training on each team's real cases, and help internal champions emerge who stay available after we leave to answer day to day questions. - 4
Coach managers and measure adoption
Equip managers to carry the change inside their team, and track actual usage rather than declared satisfaction, to know whether the tool really serves.
What stays in your hands
A usage map
The state of what is already happening, official or not, as a shared starting point before any rule or training.A written usage charter
A document everyone can read, stating what is allowed, what is forbidden, and who decides in borderline cases.A role based training programme and a champion network
Short sessions built on each team's cases, and identified people who extend the support day to day.An adoption tracking dashboard
Real usage indicators tracked over time, to tell a tool that serves apart from a tool that was simply installed.
Expected results
Usages made visible and covered by a rule
What used to happen in the shadows enters a written frame, known by leadership and by the teams who apply it every day.Resistance addressed rather than ignored
Every reluctance gets a named answer, whether it is a slower task, missing information, or a concern about the job itself.Adoption measured, not assumed
Leadership has a real usage indicator instead of an impression, and can act on what actually blocks adoption rather than on what it imagines blocks it.
How we move forward
- 1
Diagnostic of usage and resistance
Record existing usages, identify who loses something in the change, and what can be given back in return. - 2
Usage rules and champions
Write the usage charter with the teams concerned, and appoint the champions who will carry it day to day. - 3
Role based training
Train short, on each team's real cases, never on a generic demo that leaves everyone guessing what it changes for them. - 4
Measurement and ongoing governance
Track actual usage, adjust the charter when a new case appears, and keep a governance point so the rules do not freeze in place.
Who it is for
This practice is for leadership teams and managers who are rolling out, or have already rolled out, an AI tool and want it genuinely used, not just installed. It suits a launch that still needs adoption as much as an existing tool nobody can really say is serving.
In the same family
Frequently asked questions
What is AI change management?
It is the work that covers the gap between a delivered AI tool and a genuinely used one: mapping existing usage, writing clear rules, training role by role and measuring adoption, instead of assuming that going live is enough.Why does an AI tool go unadopted even when it works well?
Because adoption does not depend on the technology alone. Resistance almost always says something concrete: a task that got slower, information that disappeared, or a question about the job that was never answered. Left unanswered, the tool stays open and unused.How is this different from standard AI training?
Training passes on a way of working with agents. Change management covers what comes before and after training: mapping usage, writing the rules, appointing champions and measuring whether adoption holds over time.How do you measure adoption of an AI tool?
By tracking actual usage rather than satisfaction declared in a survey: who opens the tool, on what task, and whether that action truly replaces the old way of doing it or simply sits alongside it.Who should own change management inside a team?
Leadership sets the frame and the usage rules, managers carry the change day to day inside their team, and trained internal champions stay available to answer questions once the support engagement ends.Let's talk about your context
We always start by understanding the real work. One conversation is enough to know whether we can help, and how.