Technology Adoption: Why the Curve Stalls After the Eager Few

A new tool arrives, and for a week or two it is the talk of the team. The keen few dive in, build clever workflows, and post screenshots. Then the wave breaks against the rest of the team, the ones who were busy that week, and the rollout stops climbing. The instinct is to blame the holdouts and schedule more training. The instinct is wrong, and a Stanford-trained sociologist explained why more than sixty years ago.

Technology adoption is the process by which a new tool spreads through a population of users, and Everett Rogers showed it is governed less by how well people are told to use the tool than by friction, compatibility, and visible feedback in the moment of work. That single reframing, from a people problem to a system one, is the difference between a rollout that climbs and one that stalls.

What is the technology adoption curve, and where does it stall?

In Diffusion of Innovations, first published in 1962 and still the most-cited work in the field, Rogers sorted adopters into five groups by how soon they take up something new: innovators at roughly 2.5 percent, early adopters at 13.5 percent, the early majority at 34 percent, the late majority at 34 percent, and laggards at 16 percent (Rogers, Diffusion of Innovations). The shape is a bell curve, and the rollout that feels like victory in week one has won over the first 16 percent, the people who adopt new things on their own enthusiasm.

Geoffrey Moore later named the gap between the early adopters and the early majority the chasm, and argued that most technologies die in it (Moore, Crossing the Chasm). The reason the chasm exists is that the two groups adopt for different reasons. The early adopters adopt because the tool is new and promising. The majority adopt only when the tool is easy, fits their work, and visibly pays off, which is a far higher bar than enthusiasm.

This is the mistake hiding inside every triumphant week-one rollout. The keen few are not a small version of the whole team. They are a different kind of person, adopting on different terms, and their enthusiasm tells you almost nothing about whether the next 84 percent will follow. Moore’s whole argument is that the reference you build with the early adopters does not carry across the gap, because the majority does not trust an enthusiast’s verdict. They trust whether the thing is easy and whether someone like them, doing their job, got a visible result from it. A team that reads week-one excitement as proof of adoption is reading the wrong instrument. The enthusiasts were always going to climb in. The question the rollout has to answer is whether the reluctant majority ever will, and that question is decided by friction and feedback, not by the noise the innovators make.

Why do most technology adoption efforts fail?

Here is the part the training-more-people instinct misses. Rogers identified five attributes that predict whether an innovation is adopted, and only one of them is about knowledge.

• Relative advantage. Is the new tool visibly better than the old way, to the user, in their own work, today?
• Compatibility. Does it fit how the work is already done, without forcing a new tab, login, or detour?
• Complexity. How hard is it to grasp and use? Less complexity means more adoption.
• Trialability. Can a user try it in small, low-risk steps before committing?
• Observability. Can the user and the manager see the result of using it?

Count them. Four of the five (advantage, compatibility, complexity, observability) are properties of the system and the friction around it. Only knowledge is about instruction. Yet the standard rollout pours nearly all its effort into the knowledge factor, the training, and almost none into the four that decide the outcome. So the team gets thoroughly trained and still does not adopt, because training never touched the reasons they were not adopting.

It is worth asking why teams reach for training anyway, since the answer is human and forgivable. Training is the lever you can pull on a calendar. You can schedule a session, mark it complete, and report a number to a steering committee, all without changing the tool or the workflow. Reducing friction is harder, slower, and less visible: it means redesigning where the action happens, fitting the tool into the existing motion, building feedback loops. So the rollout optimizes for what is easy to do rather than what works, and pours its budget into the one factor of five that was not the bottleneck. The training gets done, the dashboard shows completion, and adoption does not move, because the four binding constraints were never touched.

There is hard field evidence for the friction-over-instruction read. The Sales Enablement research consistently finds that adoption of a process or tool, not its existence, is what separates teams that hit the number from teams that do not. In our own 2026 State of Sales Enablement, 89 percent of leaders had a defined sales process and only 36 percent saw their reps follow it, a 53-point gap that no amount of additional training had closed. The same shape recurs wherever someone measures adoption against intent: knowledge is abundant and adoption is scarce, and the scarcity is a friction problem, not an ignorance one.

How do you move the adoption lifecycle past the chasm?

Reduce friction and add feedback. Make the right action the easy action in the flow of the work, so compatibility and low complexity are designed in rather than trained around. Make the result visible to both the user and the manager, so observability does its work. The reluctant majority is not stubborn; they are rational, waiting for the tool to clear the higher bar. Clear it, and they follow.

Observability deserves a second look, because it is the factor that does the most to cross the chasm. Rogers found that the more visible an innovation’s results, the faster it spreads, and the reason is social: the majority adopts when it sees someone like them get a result, not when it is told the tool is good. A rollout that surfaces the new behavior and its payoff where the team can see it builds exactly the peer proof Moore says the early majority requires. A rollout where the results stay invisible, buried in a system nobody checks, starves that proof and leaves every late adopter to decide alone, which most of them decline to do. So observability is not a reporting nicety. It is the mechanism by which adoption becomes contagious, and most rollouts switch it off without noticing.

This is the same lesson the modern evidence keeps confirming. Adoption is a system property, not a virtue some teams possess: it rises when the right action is easy in the moment and falls with every tab switch and missing feedback loop, a pattern laid out in user adoption. And it is why a digital adoption effort built on training alone underdelivers, while one built on in-the-moment guidance and measurement clears the chasm.

What we recommend

Stop treating technology adoption as a persuasion problem and start treating it as a design problem, because four of Rogers’ five factors say it is one. Audit your rollout against the five attributes honestly: where is the friction, where is the tool incompatible with how the work is already done, where is the result invisible? Fix those, and reserve training for the genuine knowledge gaps that remain, which are fewer than you think. The eager 16 percent will adopt anything. The 84 percent who decide whether the rollout succeeds adopt only when the system makes the right behavior easy and its results visible. Build that, and the curve climbs on its own.

From here: the system view in user adoption, the tool category in best digital adoption platforms, and why knowledge alone does not change behavior in the knowing-doing gap.