User Adoption: A System Property Wearing a People Costume

Each software rollout produces the same autopsy. The tool was good, the training was thorough, the kickoff had snacks, and six months later the team works around the system the company paid for. The diagnosis arrives on schedule too: the people did not adopt it, said with a sigh, as though adoption were a virtue some teams possess and others lack. Then comes the prescription, more training and sterner emails, and then, a few quarters later, the same autopsy.

The diagnosis is the error. User adoption is the degree to which people genuinely work in the software they were given, and the evidence from every field that studies behavior says it is a property of the system, not of the people: it rises and falls with distance, friction, and feedback, three things no training session touches. A team that “failed to adopt” is almost always a team responding rationally to a system that made the right action the harder action. Fix the system and the same people adopt; nag the people and the same system wins again.

City planners learned this lesson long before software existed. Plant a lawn, lay the paved walkways the long way around, and watch what happens: within weeks a worn dirt track cuts straight across the grass, exactly where people wanted to walk. Planners call it a desire path. The naive response is to put up a fence and a sign, to treat the walkers as the problem. The wise response is to pave the desire path, because the people were right and the layout was wrong. Adoption works the same way. A team that routes around your software has drawn you a desire path. The track in the grass is data, and the data says move the pavement.

This is also where most change-management orthodoxy goes wrong. The dominant frameworks, Prosci’s ADKAR chief among them, model adoption as a sequence that runs through the individual: build Awareness, then Desire, then Knowledge, then Ability, then Reinforcement. Three of those five steps are pure communication, aimed at the person’s head, and that is the trouble. They treat reluctance as a deficit inside the user that the right messaging will cure. Sometimes it is. More often the user understood perfectly and declined, because the system asked too much. You can run a flawless awareness-and-desire campaign and still lose to a sticky note, because the sticky note wins on ability, and no amount of desire closes an ability gap. The frameworks are not wrong about people; they are aimed at the wrong layer.

Why do rational people refuse good software?

Walk one rep through one moment and the mystery dissolves. She is mid-call, the buyer says something that matters, and the new system would like her to switch tabs, find the record, locate the right field among forty, and type while listening. The old habit, a sticky note, costs nothing now and a vague penalty later. Under pressure, now wins; it nearly always wins; and the behavioral science treats this as settled mechanics rather than a character flaw. B.J. Fogg’s Stanford behavior model, B=MAP, holds that a behavior fires only when motivation, ability, and a prompt arrive at the same moment, and that the cheapest levers to pull are almost always ability (cut the friction) and the prompt (put it where the eye already is) (BJ Fogg, Behavior Model). The system placed its prompt in another tab and raised its ability cost to mid-conversation, so it failed two of the three. Gollwitzer and Sheeran’s meta-analysis of 94 studies put a number on the other side of the coin: bind the action to its concrete moment (“when X happens, do Y, right here”) and follow-through jumps with an effect size of d = 0.65 (Gollwitzer & Sheeran, 2006). The moment does the reminding, or memory loses to the sticky note.

Three system properties decide nearly every adoption outcome:

• Distance. Where the tool sits relative to where the work happens. A system in the flow of work gets used as a side effect of working; a system one tab away gets used at quarter close, retroactively and resentfully. This is the largest effect in our own field data: process guidance reaching reps in the flow of work correlated with 49 percent quota attainment versus 15 percent when it lived in separate destinations (The State of Sales Enablement).
• Friction. What the tool asks for relative to what it gives back. Forty fields where six matter teaches users the system wastes their time, and they generalize the lesson to the six. Curation is adoption work: every dead field deleted is a small argument that the tool respects its users.
• Feedback. Whether anyone can see the new behavior while it is forming. A rollout measured at the quarterly review is a rollout coached too late; drift hardens into habit in weeks. You can only expect what you inspect, and inspection has to arrive while there is still time to coach.

What does a working user adoption strategy look like?

Like system design, executed in this order:

• Curate before you launch. Cut the tool down to the actions that matter. Software adoption scales inversely with surface area: a short, curated set of expected actions beats a hundred features introduced at once.
• Deliver in the moment, not in the classroom. Training transfers knowledge, and knowledge was rarely the gap. Guidance that arrives at the decision point, in-app, at the step where it applies, removes memory from the chain entirely. The tooling field for this is mapped in in-app guidance and the wider digital adoption platform guide.
• Make the update a byproduct. Wherever possible, the system should capture the work as a side effect of doing the work, the argument of CRM adoption, where this whole pattern shows up at its most expensive.
• Measure behavior, coach in days. Instrument the process the software exists for, at the level of the individual piece of work, and put the signal where a manager sees it weekly. Adoption that is measured gets coached; adoption that is assumed gets autopsied.

Run that list against the standard rollout (demo, training, launch email, quarterly review) and the failure pattern explains itself: the standard rollout invests everything in knowledge and nothing in distance, friction, or feedback, the three properties that decide the outcome.

The scale of the waste is worth naming, because it is the strongest argument for changing the diagnosis. Software that goes unused is one of the largest line items nobody books. Gartner has estimated that a substantial share of enterprise software spend is wasted on licenses that are never meaningfully used (Gartner on software waste), and the pattern is the same every time: the tool was bought, the training was run, and the behavior never formed. If unused software were a people problem, you would expect it to vary with the people. It does not. It varies with the system, with how close the tool sits to the work and how much friction it adds, which is why the same teams adopt the well-designed tool and abandon the badly-placed one.

How do you turn user adoption around?

Retire the people diagnosis; it has never once produced a fix. Treat the next rollout as a design problem: curate the surface, put the guidance at the decision point, make capture a byproduct, and measure the behavior from day one so coaching happens while habits are still wet. The order matters. Most rollouts spend their budget at the front, on launch and training, and run out of attention exactly when adoption is actually decided, in the first few weeks of real use, when the desire path is being worn into the grass. Shift the weight to the back. The launch email is the cheapest part of adoption and the least load-bearing; the measured, coached first month is the expensive part and the only one that changes the outcome.

For revenue teams this is, plainly, the product we build: Supered delivers the process in the flow of work inside HubSpot and Salesforce and makes adherence visible while it can still be coached, the design pattern of this whole post shipped as a layer, with the mechanics at how it works. And when someone in the post-rollout meeting reaches for “the team did not adopt it,” hand them the sales execution gap: 89 percent of teams have a defined process, 36 percent see it followed, and the difference was never the people. The system made the wrong action easier. Fix that, and the same people you were ready to blame will adopt the tool without a single stern email.