Adoption After Launch

Most rollouts are judged on the wrong moment. The project plan ends at go-live, the launch email goes out, the team gets reassigned, and everyone treats the change as done. Then usage quietly erodes and nobody notices until a quarter later when the old spreadsheet is back in circulation and the new tool sits unused. The money was spent, the disruption was absorbed, and the intended benefit never arrived.

The failure has a predictable shape. Teams start a rollout with curiosity, hit friction in the first few weeks, and a known drop-off lands a few weeks in, when the productivity payoff has not yet materialised and the easy old path is still available. A large share of the teams that abandon a new tool do so in this window, after the early push fades and before the new habit forms. The change did not fail on launch day. It failed in the quiet weeks after, when no one was watching the signal.

There is also a measurement trap. A rollout can report that training was completed and the launch email reached everyone, and still have near-zero real adoption. Training completion and communication reach prove the rollout motion happened. They do not prove people are doing the new thing in production and getting the result. The two questions are different, and only the second one is the point.

Get the after-launch work right and the curve bends the other way. A deliberately staffed support window, training on the parts that are genuinely hard, and visible reinforcement push a change past the drop-off point into habit. A healthy adoption rate commonly reaches 60-70% of the target group within the first three to six months when someone owns that window. The mechanism that gets you there is the subject of the next section.

Adoption after launch rests on three moving parts working together: a clear signal you watch, a support and reinforcement system that runs through the drop-off window, and a way to see who is struggling before the average hides it. Name each part in plain words.

Define the signal before you launch

An adoption signal is an observable measure that shows the change took, decided before go-live so you are not inventing it under pressure. The basic one is adoption rate, the share of eligible people actually using the new way: (people using the new way / people who should be) x 100. Add at least one of these:

• Active users, the count of unique people doing the new thing in a period (daily or weekly), so a one-time login does not count as adoption.
• Stickiness, the ratio of daily to monthly active users. A ratio near 0.4 means people return on about 40% of days, which signals a real habit rather than an occasional visit.
• Time to value or time to proficiency, how long until a person completes a real task the new way without help.

One worked instance: if 30 of 50 support agents handle a real ticket through the new flow this week, the weekly adoption rate is 60%. If only 12 of those 30 do it again next week, stickiness is weak and you have an early-revert problem to chase, which is a different issue from training.

Run the reinforcement system

Reinforcement is the final stage of the Prosci ADKAR model (Awareness, Desire, Knowledge, Ability, Reinforcement), the framework Jeff Hiatt published in 2003 to describe the individual journey through change. The first four stages get a person to do the new thing once. Reinforcement is what stops them sliding back. In practice it is a small, repeating set of mechanisms: managers visibly expecting the new behavior, recognition when a team hits the target, quick corrective help where people stumble, and removing the easy old path once a group is steady. Reinforcement runs continuously, well past launch day.

Watch by cohort, not by average

Track the signal segmented by role, team, region, or tenure, because a blended average masks the group in trouble. Everett Rogers’ diffusion-of-innovations curve splits any population into innovators, early adopters, an early and late majority, and a final roughly 16% of laggards who adopt only when the old option is gone. Segmenting tells you which cohort you are dealing with so the intervention fits. Finish this section able to answer three questions for your own change: what signal, what reinforcement, and which cohorts. The next section walks one through end to end.

A support team of 50 agents rolls out a new ticket triage flow, replacing a shared spreadsheet. Priya owns the rollout. The goal is faster, more consistent triage, and the bet is that the new flow delivers it once people actually use it.

1. Signal, set before launch. Priya picks 70% of agents active on the new flow within 30 days, with first-response time holding flat or improving. She adds a stickiness check so a single login does not count.
2. Support window. A staffed help channel runs for the first two weeks, with one named person answering and a known response time. Agents know exactly where to go when stuck.
3. Targeted training. One short session covers the genuinely non-obvious step, the new urgent-versus-routine triage rule, rather than a tour of every screen.
4. Watch by cohort. At day 14 the blended number reads a comfortable 68%. Segmented, the day shift is at 88% and the night shift at 41%. The average hid the gap. The night shift never got a live session and quietly reverts to the spreadsheet after midnight.
5. Intervene where it breaks. Priya runs a hands-on session for the night shift, adds an in-app hint at the triage step, and rechecks the night-shift number the next Friday rather than the blended one.
6. Close the old path. Once each shift is steady above 70%, the shared spreadsheet is archived so there is no easy revert.
7. Reinforce. At 30, 60, and 90 days Priya checks the signal and the first-response time, recognises the shift that improved most, and fixes the single top blocker each time.

By day 90 both shifts sit above 80%, first-response time is down, and triage is consistent. The launch itself took one day. The adoption took the ninety that followed, and the cohort view is what saved it from a quiet partial failure that the 68% average would have let pass. Even a clean run like this hits traps worth naming, which the next section does.

The most common pitfall is reading the blended average and stopping there. It is tempting because one healthy number is easy to report and feels like good news. The fix is to always segment by role, team, or tenure, since a comfortable 68% can hide a cohort sitting at 41%. Report the lagging cohort by name and act on that number.

A second trap is mistaking the rollout motion for adoption. Training completion, email open rates, and attendance prove the change was communicated. They are tempting because they are easy to gather and they arrive early. They do not prove anyone is doing the new thing in production. Treat enablement counts as inputs and keep the production usage signal as the real measure.

A third is leaving the old path easier than the new one. People rarely decide to revert. They drift back to whatever has less friction. Where it is safe, close or hide the old route once a cohort is steady, and remove friction from the new approval or validation steps so the new way is the path of least resistance.

Edge cases the simple version misses

• The signal that moves slowly. Some outcomes, like a drop in escalations or a cycle-time improvement, only show after a quarter. Watch a leading proxy in the meantime, such as weekly active use, so you are not flying blind for ninety days waiting on the lagging measure.
• The J-curve dip. Productivity often falls before it rises, because people are learning while still delivering. Research on technology rollouts describes this as a productivity J-curve. Expect the early dip, tell sponsors it is coming, and avoid killing a change during the trough.
• The leader who endorsed it then ignored it. Reinforcement collapses when managers stop expecting the new behavior. Adoption stays highest when a senior person runs a hands-on session with each team member in the first weeks, rather than only sending the launch note.

These traps are manageable when one team owns a small change. They multiply across many teams and quarters, which is the scale problem the next section handles.

Across many teams, several rollouts, and more than one quarter, adoption work has to become a light habit rather than a one-off heroics push, or it will not survive the second launch. The aim is a repeatable cadence and a small set of artifacts that any rollout owner can reuse.

Make the review a fixed, cheap ritual. A 15-minute weekly adoption check that looks at the segmented signal, names the top blocker, and assigns one fix is enough through the drop-off window. After 90 days, drop it to monthly. The discipline is keeping the metric definition stable across releases, so a 70% this month and a 70% last month mean the same thing and trends are real rather than artifacts of changed counting.

Standardise three artifacts so each rollout does not reinvent them:

• A one-line adoption signal agreed before launch, with the formula and the target cohort written down.
• A support window definition: where people go, who answers, and the end date.
• A reinforcement schedule at 30, 60, and 90 days, naming the manager who is accountable for expecting the behavior. RACI calls for a single accountable owner per task, and adoption is no exception, so one named person owns the number.

Connect this to the other practices in this section. The weekly check is a Feedback Loop applied to a rollout: a regular signal feeding a regular decision. The signal itself is the Outcome the launch was meant to produce, which keeps the team honest about output versus result. And the single accountable owner is the same ownership rule that keeps any workflow from drifting.

The durable principle to keep: a launch is a hypothesis that people will use the new way and get the result. Adoption after launch is the experiment that proves it, and reinforcement is what keeps the proof from expiring.