The 90-day rule: why the adopt stage decides every AI rollout

Launch day is the easiest day in the life of any new tool. There is an announcement, a demo, a short video, perhaps cake. A marketing team gets an agent that drafts campaign briefs from a product sheet, and that afternoon half the team tries it. A month later, three people use it. By the end of the quarter, one person does, and she is the one who asked for it.

Nothing broke. The agent still writes perfectly serviceable briefs. What happened is that nobody owned the stretch between "it works" and "it's how we work", and that stretch is where most AI rollouts quietly end.

Build, launch, and then nothing

Most projects are planned in two phases. There is the build, which has a budget, a team and a deadline. And there is the launch, which has a date. After the launch there is usually a line on the plan marked "business as usual" or "hypercare", which in practice means the build team moves on and the tool is left to fend for itself.

That made a sort of sense when software took a year to build and the launch was the climax. It makes much less sense when building takes weeks. Once production is quick, the bottleneck moves downstream, to the slow human business of changing what people do on a Wednesday morning. A rollout plan that stops at launch has budgeted for the cheap part and left the expensive part to luck.

We think of every piece of software in three movements: build, adopt, improve. The middle one is the one most organisations skip, because it doesn't look like work. Nothing ships. Nobody gives a demo. It is mostly sitting next to people while they try a new thing and noticing where they hesitate.

Why three months

Ninety days is not a law of nature, but it is roughly how long a tool takes to stop being new. In the first month people try it out of curiosity or obligation. In the second it collides with real work: the deadline week, the awkward case, the colleague who still sends things the old way. In the third a habit either forms or it doesn't. By the end of the quarter the tool is either the default or a curiosity, and once a team has settled that, the question is very hard to reopen.

The second month is the dangerous one. Picture a legal team given an agent that produces first-pass reviews of standard supplier contracts. Month one goes well; novelty helps. In month two a deadline lands, two contracts arrive with unusual indemnity clauses, the drafts need more editing than usual, and a senior lawyer says, reasonably, that it is quicker to do them by hand this week. This week becomes every week. Nobody decides to abandon the tool. It simply stops being the first thing anyone reaches for.

Had someone been watching, that moment was fixable. The agent could have been told to flag the clauses it was unsure of rather than draft straight through them. The senior lawyer could have been asked what would make it faster than doing it by hand. Instead the signal arrived as silence, and silence is easy to miss in a usage report.

Skipping adoption also costs more than the one tool. A rollout that fades leaves a residue: a team that has learned, from experience, that new tools arrive with fanfare and leave without anyone noticing. The next launch starts in debt. People wait to see whether this one will last before investing any effort, and that wait is often what makes it fail. Diffusion of innovations describes early adopters pulling the majority along; a fizzled rollout teaches the early adopters to stop volunteering.

What the adopt stage actually involves

Adoption sounds soft, so it gets treated as optional. In practice it is specific, unglamorous work, and it can be planned like any other.

• Someone with time and authority owns adoption, separately from whoever owns the build.
• Usage is tracked by person and by task, not as a single total, so you can see who stopped and when.
• The old way is made slightly harder, by retiring the duplicate report or the shared inbox, once the new way is genuinely better.
• Every workaround people invent is treated as a requirement, not as disobedience.
• A fixed date at the end of the quarter is set for deciding whether the tool stays, changes or goes.

The fourth item does the most work. When an engineering team starts running a coding agent's pull requests through a private checklist before review, they are telling you something the tool should do. When a support team pastes agent replies into a separate document to soften them, they are telling you where the tone is wrong. Done properly, adoption is three months of listening with a build team on standby.

Be careful with the numbers, though. Goodhart's law applies with some force here: make logins the target and people will log in, then do the real work somewhere else. Usage figures tell you where to look. They don't tell you what you will find.

Improve is where the value compounds

The third month exists to turn what you learned into changes. Small ones, mostly: a field added, a default changed, a step removed, an instruction rewritten so the agent stops doing the thing that annoyed everyone in week five. Each change is minor. Together they are the difference between a tool that was rolled out and a tool the team considers theirs.

There is a second effect. When people see the tool change because of something they said, they start saying more. A team that watches its complaints turn into fixes within days becomes a team that reports problems instead of quietly working around them. That loop is worth more than any training session, and it only exists if the build team is still around in month three.

This is also when the hidden waiting shows up. An HR team's agent may draft offer letters in seconds and then leave them sitting for days in a sign-off queue nobody drew on the diagram. You won't see that from the build. You will see it in month two, if someone is looking.

Run every stage on the same clock

The rhythm scales beyond a single tool. In our Built to Fit programme, each of the four stages lasts three months and runs the same way: a month to ship working software into the real workflow, a month of adoption until the old way is the one that feels odd, and a month to refine against real use before the next stage begins. On paper that is slower than launch-and-leave. In practice it tends to be faster, because nothing has to be rolled out twice.

It also changes what a launch date means. Instead of a finish line, it marks the start of the month that matters most, and the people who built the thing are still in the room when the first complaints arrive. That alone changes how the complaints get made.

You don't need a programme to apply the rule. Take the last AI tool your company launched and answer three questions: who owns its adoption today, which teams have quietly stopped using it, and what was the last change made because of their feedback. If the answers are nobody, you don't know, and nothing, the tool isn't finished. It has only been delivered.