Software Adoption Strategy: Three Levers, and Training Is the Weakest
Most software adoption strategy is a training plan in disguise. The two levers that move adoption, distance and feedback, get almost no budget. Here is how to rebalance it.
A software adoption strategy is the plan for getting people to actually use the software they were given, and a good one pulls three levers, distance, feedback, and knowledge, in that order of power, rather than treating adoption as a training problem.
A software adoption strategy, on most slides, turns out to be a training calendar with a strategy label on it. There is a kickoff, a set of courses, a library of documentation, a launch email, and a hope that exposure will turn into habit. It rarely does, and the reason is not effort. It is that the plan spends nearly all its budget on the one lever that moves adoption least and almost nothing on the two that move it most.
A software adoption strategy is the plan for getting people to use the software they were given the way it was meant to be used, and a good one pulls three levers, distance, feedback, and knowledge, in that order of power, rather than treating adoption as a training problem. Get the order right and adoption follows. Get it backward, the usual case, and you train a team that still works around the tool. A good user adoption strategy is the same idea applied to people rather than a single product: design the system, do not exhort the user.
The stakes are large enough to be worth a number. Gartner has reported that a significant share of CRM and enterprise-software spend underdelivers because the tools go underused, and the standing industry estimate, repeated for years across analyst notes and vendor postmortems, is that roughly 70 percent of large software and digital-transformation efforts fall short of their goals, with adoption the most common point of failure rather than the software itself (McKinsey on transformation success rates). The license gets bought. The training gets run. The behavior never arrives. That is not a software problem and it is not a knowledge problem. It is an adoption-design problem, and it has a structure.
What are the three levers of a software adoption strategy?
Adoption is a system property, not a virtue, and three system factors govern it. Ranked by how much they move the number, they go like this.
- Distance. How far the right action sits from the flow of work. When using the tool costs a tab switch or a separate login, friction wins and the behavior dies. This is the strongest lever, because it removes the friction directly.
- Feedback. Whether anyone can see the behavior happening in time to coach it. You can only sustain what you can observe, and most rollouts are flying blind until quarter close.
- Knowledge. Whether people know how to use the tool. Usually they do, or can find out in seconds, which is why this is the weakest lever and the most overspent.
The ranking is not a matter of taste. Distance sits at the top because it is the only lever that changes the cost of the right action in the moment a person decides whether to take it, and that moment is where adoption is won or lost. Feedback comes second because a behavior you cannot see is one you cannot sustain: drift that stays invisible until quarter close has already cost you the quarter. Knowledge ranks last not because it is worthless but because it is the one input the modern workplace already has in abundance. Any answer is a search away, and the bottleneck has moved from knowing to doing.
The reason distance dominates is captured in BJ Fogg’s behavior model from Stanford, which holds that a behavior happens only when motivation, ability, and a prompt arrive together, and that the cheapest way to get more behavior is almost always to raise ability by making the action easier (Fogg Behavior Model). A tab switch lowers ability. So does a separate login, a stale document, a tool that sits outside the work. Distance is friction, friction is the inverse of ability, and ability is the lever you can move tonight.
Why does the training-first strategy fail?
Because training raises knowledge, and knowledge was rarely the bottleneck. The State of Sales Enablement work found reps could find the right information and still did not act on it, the signature of a behavior gap rather than a knowledge gap. Pour more training onto a friction-and-feedback problem and you get a thoroughly trained team that still works around the tool, which is the most expensive kind of failure because it feels like diligence. The instinct to train more is the instinct to push harder on the lever that is already pushed too far.
It is worth being fair to the training-first camp, because the best version of it is not naive. Change-management frameworks like Prosci’s ADKAR put “Knowledge” and “Ability” as distinct stages on purpose, and ADKAR’s own data has long held that the late stages, where a person actually does the new thing and keeps doing it, are where most change initiatives stall, not the early awareness-and-knowledge stages. The framework is right that knowledge is necessary. Where the typical rollout goes wrong is in treating knowledge as sufficient, spending the whole budget getting people to “know” and almost nothing getting the “ability” and “reinforcement” stages, which is precisely the distance-and-feedback work. The serious change-management literature already agrees with us; it is the slide-deck version that forgets the last two stages exist.
How should a software adoption strategy measure success?
Honestly, which means at the behavior level, not the usage level. The two diverge constantly.
A login is not an arrival. A completed tour is a fact about the tour. The metric that matters is whether the process the software exists for is being followed, at the level of the work, visible while there is still time to act. Chase that, and report usage only as a leading sanity check.
The divergence is not theoretical, and it is worth a concrete case. A revenue team rolls out a CRM and the dashboard lights up: logins daily, fields populated, the usage chart healthy. Six months later the forecast still misses, because the reps are logging in, filling the required fields with whatever moves the deal forward on screen, and running the actual qualification in their heads and their inboxes where no one can see it. Every usage metric is green. The behavior the CRM existed to instrument, a disciplined, inspectable qualification on every deal, never happened. Usage measured the odometer. The trip never reached the destination. This is why a usage-first dashboard is worse than no dashboard: it manufactures false confidence, and false confidence is what stops a leader from fixing the distance and feedback problems that are sinking the rollout.
The reason behavior is harder to measure is also the reason it is the only honest target. Usage is a property of the tool and trivial to log. Behavior is a property of the work and only visible if something is watching the work itself, at the level of the individual task, in time to coach. That is a heavier instrument to build, which is exactly why most strategies default to the easy odometer and call it measurement. The strong strategy refuses the substitution.
What we recommend
Build the strategy in the order the levers rank. Start with distance: curate the tool to the few actions that matter and surface the right step in the flow of the work, so using it costs no detour. Add feedback: measure the process being followed, not the logins, so drift is visible in days. Then, and only then, add knowledge, reserved for the genuine gaps that remain after friction is gone, which are fewer than the training calendar assumes. Teams whose process reaches people in the flow of the work, in our research, hit quota at 49 percent versus 15 percent for those whose process does not. Placement is the strategy. Training is the footnote most plans mistake for the headline.
From here: the system view in user adoption, why the curve stalls in technology adoption, and the tool category in best digital adoption platforms.
Frequently asked questions
What is a software adoption strategy?+
Why do most software adoption strategies fail?+
How do you measure software adoption?+
What is the fastest way to improve software adoption?+
Your process, running itself.