You built something good. The model works. The infrastructure is solid. You’ve got buy-in from the business sponsor. You’ve trained the team. You’re ready to go.

Six months later, 40% of the team is using it. Eighteen months later, it’s been deprecated.

This isn’t a technical problem. It’s not a governance problem. It’s an adoption problem that looks like a technical problem, and most organizations don’t see the pattern until it’s too late.

What Most Organizations Get Wrong About Adoption

The standard narrative about adoption goes like this: “We built a tool. People didn’t want to use it. Maybe the tool wasn’t good enough, or the training wasn’t good enough, or the business case wasn’t compelling enough.”

And then the organization either: a) doubles down on training, b) adds more features to make it more compelling, or c) gives up and builds something else.

None of these is wrong exactly. But they’re all treating adoption as primarily a tool or training problem. It’s not.

Adoption in organizations isn’t like adoption in consumer markets. In consumer markets, if you build something better than alternatives, people use it. They compare options and pick. They vote with their usage.

In enterprises, adoption is a work context problem. People don’t choose what to use based on whether it’s best. They choose based on: Does this fit into how I already work? Does using this create friction with other parts of my job? Does my manager expect me to use this? Do the people I work with use it?

The best tool in the world will fail if it doesn’t fit into the actual context of how the work happens.

The Real Adoption Curve (Not The One In The Literature)

Most adoption literature talks about an S-curve: early adopters, early majority, late majority, laggards. You get 10% adoption, then 20%, then it accelerates. Classic diffusion of innovation.

That’s not what happens with enterprise tools.

What happens with enterprise tools is:

Month 0-2 (Honeymoon): High enthusiasm. The team that built it is excited. The sponsor is excited. Early adopters are excited. You see 50-60% usage among people who could theoretically use it. People are trying it. Everyone’s optimistic.

Month 3-4 (Friction Discovery): Usage starts to flatten. You’ve got 50% usage, and it’s not growing. The people who are using it are hitting edge cases. The tool doesn’t work perfectly for their specific workflow. You ask why usage isn’t higher, and you get feedback like: “It doesn’t integrate with my existing process.” “It’s faster for me to do it the old way and copy the result in.” “I can’t use this when I’m at a client site.” “The output isn’t in the format I need for my downstream system.”

None of these are “the tool doesn’t work.” They’re “the tool doesn’t work in my context.”

Month 5-6 (The Push-Back): Leadership decides usage is too low. They mandate using the tool. Or they add requirements: “You have to use this by the end of Q2.” Or they tie it to performance reviews: “Usage of this tool is part of your evaluation.”

This is when you learn whether you’ve actually solved the context problem or just built a nice tool.

Month 7-12 (Deterioration): If you fixed the context problems, usage stabilizes at a higher level. If you didn’t, usage drops below the mandate level as soon as the mandate is lifted. People find workarounds. They convince themselves the tool is “not quite right for my situation” so they go back to the old way. They batch the work they have to do with the tool with work they do the old way, then copy the results in. Adoption grinds down.

Month 13+ (Abandonment): The tool is still there. Some people use it. But it’s no longer the default. New people aren’t trained on it because “it didn’t really take off.” The organization moves on to the next initiative.

The standard response to this pattern is: “The tool wasn’t good enough.” The actual response should be: “We didn’t understand the context well enough.”

What Context Actually Means

When I say “context,” I don’t mean “people don’t like change.” I mean the specific, structural constraints on how work actually happens.

Say you built an AI model that improves sales forecasting. It’s a good model. Salespeople who use it get better at predicting. But your organization has a specific context:

• Salespeople are evaluated monthly on their forecast accuracy
• They’re compensated based on hitting their forecast
• The model updates twice a week
• But they submit their forecast once a week
• And once submitted, changing the forecast requires approval from their manager
• Who is traveling this week

In this context, the salesperson faces an explicit cost to using your better model: they have to get approval to change a forecast they’ve already submitted. The benefit (better accuracy) is diffuse and doesn’t show up in their evaluation immediately. So they don’t use it.

This isn’t a training problem. This isn’t a “people resist change” problem. This is a structural misalignment between when the tool is useful and when the person is incentivized to use it.

The way you fix this isn’t by training harder. It’s by understanding the structural context and redesigning around it. Maybe the model needs to run on the person’s schedule, not its own. Maybe the forecast needs to be re-submittable without approval. Maybe the evaluation system needs to change. Maybe you need to give people a 30-day look-ahead so they can submit more aggressive forecasts and let the model refine them.

None of this is about the model. It’s all about the work context.

Three Patterns That Kill Adoption

I’ve watched three adoption-killing context problems show up repeatedly:

1. Workflow Mismatch

You built a system that works great if people follow a certain workflow. But that workflow doesn’t match how people actually work.

Example: You built a data preparation tool that works great if people upload data, review it, and run preprocessing. But people’s actual workflow is: I’ve got data in a database, I need to run analysis in a spreadsheet, and I need results in a presentation. Your tool is in the middle of their workflow but doesn’t integrate to the beginning or the end. They have to export from the database to the tool, import the results into the spreadsheet, then copy the numbers into the presentation. That’s three tools instead of two, so they don’t use yours.

2. Incentive Misalignment

You built a system that benefits the organization, but the person using it doesn’t benefit individually.

Example: You built an AI system that optimizes staffing across departments. It’s great for the organization. But a department manager’s bonus is based on their local efficiency, not global efficiency. Using your system might move one of their people to another department, which makes them look bad locally. So they don’t use it even though it’s better for the company.

3. Authority or Credibility Gap

You built a system that provides recommendations or guidance, but the person using it doesn’t trust the system or its recommendations.

Example: You built a model that recommends treatment options for doctors. The model is accurate. But doctors are trained to make their own clinical judgments. They don’t trust a model’s output more than their own experience. Unless you can demonstrate that the model is more accurate than they are—which requires time and data they don’t have—they won’t trust it enough to use it over their existing judgment.

Each of these patterns shows up differently in different contexts, but they all have the same underlying structure: the tool is good, but using it costs the person something (time, authority, credibility, incentive alignment) that makes it rational not to use it.

How To Actually Fix Adoption

The organizations that get adoption right don’t start by building the model. They start by understanding the context.

Map the workflow. How do people actually do this work today? Don’t ask them—watch them. Or better, do the work with them for a few days. You’ll see things they don’t even notice they’re doing.

Identify friction points. Where in the workflow would your tool create extra steps? Where would it require people to change how they work? Where would it require approval or credibility they don’t have yet?

Understand incentives. Is the person who will use this tool evaluated on the thing your tool helps with? Or are they evaluated on something else? If they’re evaluated on something else, using your tool is a cost to them, not a benefit.

Design for the context, not against it. Build the tool to fit into the workflow people actually use, not the workflow you wish they used. If people need results in spreadsheets, make sure your tool outputs to spreadsheets natively. If people are evaluated on local metrics, make sure your tool makes them look good locally, even if it’s making global trade-offs.

Plan for the adoption curve. Don’t expect the S-curve. Expect the friction curve: high, then flat, then mandated, then deteriorating. Plan for each phase. Build in the changes you need to make to get past the friction phase before you deploy.

Why This Matters

The cost of abandoned tools is higher than you think. You spent development time. You spent infrastructure costs. You spent training time. You spent organizational attention. And then six months later, it’s not used.

But the bigger cost is that the organization loses confidence in your AI program. One abandoned AI tool creates skepticism about the next one. The team that built it loses credibility. The sponsor becomes hesitant. By the time you want to try again, you’ve burned through social capital.

The organizations that are winning with AI aren’t the ones building the most sophisticated models. They’re the ones that build models that fit into how people actually work, and then systematically manage the adoption curve until the tool becomes part of the standard workflow.

Adoption isn’t something that happens if you build it right. It’s something you design for, plan for, and manage through the friction phases.