If they don't use it, it doesn't exist

A model that everyone overrides has failed, even though every launch metric says otherwise. Adoption is the metric the others report to.

There is a version of failure that never shows up in a post-mortem, because from a distance it looks like success. The system shipped. The accuracy was fine. The launch email went out. And then: the analyst keeps her spreadsheet open in the other window. The salesperson reads the recommendation and calls who he was going to call anyway. The reviewer overrides every suggestion, politely, forever. Nothing crashed — and as far as any outcome is concerned, the model does not exist.

I learned to treat adoption as the product metric — not a change-management afterthought, not a rollout KPI, but the number the other numbers report to. Precision means nothing multiplied by zero usage. This sounds obvious written down. It is violated by most AI deployments I have seen, because adoption is the one constraint you cannot engineer from your desk, and so it gets scheduled last, after all the parts you can.

Adoption is designed, not driven

The phrase "drive adoption" gives the game away — it imagines adoption as a push you apply after building. In every system I've shipped that people actually used, adoption was a set of design decisions made before the model was chosen. Three of them do most of the work.

Day-one usefulness beats eventual brilliance. A knowledge assistant I shipped into a large sales organization reached seventy percent adoption — not because it was the smartest system available, but because on its first day it answered the questions new hires were already asking someone, in the language they already used, faster than the person they'd have interrupted. The bar for a new tool is not "better than nothing." It is "better than the workaround the user already trusts," on the first try, or there is no second try.

Explainability before cleverness. A matching model I built began life deliberately dumber than it could have been: its first release ranked on a handful of factors any regional leader could verify from their own experience. It earned the room's trust because the room could check it. Only then did later releases add the features that made it precise. Run the sequence in reverse — maximum sophistication first — and you get a black box asking people to trust it before it has earned anything, and the override rate shows you their answer. Trust is not a launch communication. It is an architectural property, built in or permanently absent.

Meet the workflow where it lives. Every additional tab is a tax collected daily. The systems that survived went where the decision already happened — inside the CRM, inside the queue, inside the tool already open. The ones that asked users to come to them were simply never visited.

What this changes about the work

It reorders the first month. Before benchmarking a single model, get one real user to commit that a specific output would change a specific decision they make — and watch them walk through a paper version. If they wouldn't act on a perfect answer, a real one won't save you, and you learned it in week one instead of after the build. Then instrument usage with the same seriousness as accuracy: adoption curve, repeat usage, override rate, and who has stopped using it — because one team quietly going dark is the earliest signal you get, and it never appears in the model metrics.

None of this diminishes the modeling. It locates it. The model determines how good the product could be; adoption determines how good it is. The gap between those two numbers is the part of the job that is actually yours.

If you take one thing: put the override rate on the dashboard, next to precision, from day one. A model no one acts on has an accuracy of zero.