Systems go live. Adoption doesn’t.

The five things everyone has already heard

Most conversations about adoption begin with the same set of statements. They appear in many transformation and leadership discussions and they sound reasonable enough to pass as common sense.

1. People do not accept change automatically

2. Systems must be useful and easy to use

3. Leaders must set the example

4. Training alone never creates adoption

5. Activity is not adoption

   
   

All of this is correct. All of it is familiar. And none of it explains why adoption still fails so reliably in real programmes.

To understand why systems get implemented, but not used, you have to look beyond these surface-level truths and examine how behaviour actually forms in organisations.

Programmes expect behaviour they never designed

Most programmes invest heavily in designing the system and hardly anything in designing the behaviour around it. They define workflows, integrations, data models, training plans and rollout timelines. But they do not define where work should begin, which old practices must end, how decisions should be made inside the system or how leadership will reinforce the new routines.

Instead programmes assume that once the tool exists, people will adjust their behaviour accordingly. In reality, behaviour follows cues, norms, shortcuts and perceived risks rather than the intentions written into a process diagram. If the old way still feels safer faster or more predictable, the old way wins. This is not resistance. It is a perfectly rational response to the environment.

A system can be technically strong and still be ignored, if no one defines the behavioural shift that must accompany it.

---

Why real behaviour beats good design

A system can solve real problems and still lose to routines that have existed for years. Behavioural patterns operate on a different logic than system design. Habits reduce mental effort and pull people back to familiar actions. Social norms signal what is actually

expected in day to day work. Local optimisation beats global templates when the central design does not align with local realities. Under pressure people choose the path that minimises perceived risk not the one that satisfies the business case.

You see this in every domain. A CRM is bypassed because leaders still ask for Excel and PowerPoint. An ERP template is half used because local teams need exceptions to keep operations stable. AI tools remain untouched because no one defines when and why to use them. Call centre agents skip steps when the process slows down their call handling.

None of these behaviours are emotional or irrational. They are structural. Design works only when it aligns with the behaviour patterns that shape everyday work.

---

How to recognize adoption

Most systems do not provide the data needed to measure adoption reliably. They capture activity, but rarely capture the flow of real work. In practice adoption cannot be measured directly. You understand it through behaviour and through the choices people make while doing their actual tasks.

The simplest and most reliable method for PMs and POs is to ask targeted questions. They reveal what dashboards cannot.

One question is about where work actually begins. People either start their tasks inside the system or somewhere else and copy the results later. A single question surfaces this instantly: “Where did you begin your last task?” If the answer is email, Excel, chat, threads or personal notes the system is not the entry point.

Another question exposes shadow processes. Teams keep spreadsheets, notes, screenshots or private trackers because something in the system is unclear, missing or slower than the old routine. You do not need monitoring to find them. You simply ask: “What do you still need Excel for?” The answer shows the gap between intended and actual behaviour.

Or you can ask where decisions happen. If decisions are made outside the tool and only documented afterward, the system is not driving the work. Ask: “Show me the last decision you made in the system.” If the answer comes in the form of a slide or a message thread the behaviour is clear.

Adoption becomes visible not through KPIs but through the paths people consistently choose in their real workflow.

---

How to build adoption into the design

If adoption is supposed to happen it must be part of the design from the beginning. Most user stories describe system behaviour but not human behaviour. They state what the system should do but not what the user should do or stop doing.

A better approach defines behavioural intent for each workflow. Where does the task start. Which decision must happen in the system. Which old routine is replaced. This clarity prevents dual work and ensures the system is not an additional layer but the central path.

Leadership plays a different role than the usual slogan suggests. It is not about “going first”, but about shaping the environment in which behaviour forms. People take their cues from the questions their managers ask, the information they consider valid and the decisions they make. If leaders continue to request old reports or make decisions outside the system, the old path stays alive by default. If they consistently work with system-based information, behaviour shifts almost automatically.

Designing for adoption means designing for the way people actually work, not the way the process map imagines they should work.

---

Too late: implemented and not used: what now?

Many organisations encounter the same moment. The system is launched the dashboards are green and the organisation still works exactly as before. At this point the technical work is finished but adoption has not begun.

Three steps help even when it is late.

First, diagnose behaviour. Ask where work starts, which steps feel slow or risky and which leadership expectations contradict the new workflow. These conversations reveal the real blockers far more clearly than user feedback about convenience or preference.

Second, reduce friction. Adoption often fails because the moment of action is harder than it needs to be. Small adjustments like removing fields, simplifying navigation, setting smarter defaults or reducing repetition can make the new way easier than the old one. These changes have more impact than additional training.

Third, retire the old paths. As long as old templates, legacy reports and parallel processes remain available, people will continue to use them especially under pressure. Removing the old way and having leaders rely on system data makes the new path the only path that works.

Fixing adoption after go live is not ideal but it is possible. Once the focus shifts to behaviour rather than system completeness, real adoption can still develop.

---

The Flip Side Conclusion

Adoption is not a matter of willingness. It is the result of design choices leadership signals and behavioural patterns. Programmes fail when they expect behaviour without designing it. They succeed when the new way becomes the easiest most supported and most coherent option.

Adoption does not happen by default. It happens when the environment makes the new behaviour make sense.