The Adoption Blocker You Won’t See Until You Ship

A venture I advise spent months making the AI model more accurate. More examples per case. Careful comparisons between models, scoring which one read the evidence best. The accuracy curve climbed. The team felt the progress in their bones.

Then they put it in front of a real operator, and adoption didn't move. Not a little. At all.

The model was right. The delivery surface was wrong. And no amount of additional accuracy was going to touch the actual problem, because the actual problem had nothing to do with whether the model could read a case correctly.

What was actually blocking adoption

Three things, none of them in the model.

First: nobody agreed on what "approved" meant. The team assumed it was a settled category, a clean yes or no. It wasn't. Different people in the workflow carried different definitions of the same status, and they had never been forced to reconcile them. The model was confidently producing an output that humans downstream couldn't agree how to interpret.

Second: the official system people had to use to record the result was a usability nightmare. Even when the model handed someone a correct answer, getting that answer into the system of record was slow, confusing, and easy to get wrong. The bottleneck wasn't the decision. It was everything that happened after the decision.

Third: the field crews who supplied the evidence had no standard way to submit it. Every submission arrived a little differently. So even a perfect model was reasoning over inconsistent inputs and feeding into a process that couldn't absorb its outputs cleanly.

Look at that list. Definitions. Submission flow. The system of record. Not one of those is a model problem. You could double the accuracy and move none of them.

You cannot research your way to these

Here is the part that stings, because it goes against how most of us are trained to de-risk.

You cannot find these blockers by thinking harder upfront. They don't live in a spec. They don't show up in a requirements doc or a stakeholder interview, because the people you interview will describe the workflow they believe they have, not the one they actually run. Status ambiguity in particular is invisible from the inside. Everyone assumes their definition is the shared one. Nobody discovers the gap until two people with different definitions try to act on the same case.

These blockers live in three places: the workflow, the incentives, and the status ambiguity. All three are behavioral. All three only become visible when a real person tries to do the real job in front of you. That is not a research problem. It is an observation problem, and observation requires something to observe.

So the fastest way to find them is also the most uncomfortable one. Ship to one real operator. Then watch. Don't watch a demo of the happy path. Watch someone try to get through their actual Tuesday using the thing you built, and pay attention to every place they hesitate, improvise, or reach for a workaround. Each hesitation is a blocker you would never have written down.

Read the spread

When that first pilot comes back, it rarely comes back clean. You get a messy spread. Some cases approved. Some held. Some incomplete. The instinct is to treat that mess as noise, or as a sign the model needs more tuning.

It isn't noise. The spread is the product talking to you.

A spread of approved, held, and incomplete is not telling you the model guessed wrong. It is telling you that people don't share a definition of "approved," that some cases got stuck in a submission flow nobody standardized, and that the incomplete ones never had a clean way in. The distribution of outcomes is a map of your real problems. Read it as a diagnosis, not a defect.

And once you read it that way, the priority order flips. The work is shared definitions and a clean submission flow first. The system of record second. The model last.

I want to be precise about that ordering, because it is the whole lesson. Model refinement is not unimportant. It is just the last 20 percent, not the first. It is what you do once the surface around the model can actually carry a correct answer to a person who knows what to do with it. Spend your first cycles on the workflow. Spend them on the boring, human, unglamorous question of what a status means and how evidence gets in and how a result gets recorded.

The venture eventually did this. The accuracy work they'd done wasn't wasted, but it wasn't what unlocked adoption. What unlocked adoption was agreeing on definitions and fixing the path the evidence traveled.

This is the thing that holds up on Tuesday. A model that is right in a notebook is a demo. A model whose correct answer can actually move through a real workflow, into a real system, in front of a real operator who agrees what the output means - that is a product. The gap between those two is almost never accuracy. It is the surface you didn't think to build, because you couldn't see it until someone tried to use it.

Ship to one operator. Watch them work. Let the spread tell you what's broken. It won't be the model.

Field Notes from the Agentic Operator is a personal series. These are my own views, not those of my employer or any organization I work with, and nothing here relies on non-public information.