Essay · May 2026

Adoption Is a Product Problem, Not a Change Management Problem

When platforms fail to gain traction, the default response is change management. That is almost always the wrong diagnosis, and applying it delays the work that matters.

When a new platform fails to gain traction, the explanation usually follows a pattern. Leaders identify adoption as the problem. A change management plan is created. Communication campaigns launch. Training sessions are scheduled. These efforts sometimes help at the margins and rarely change the outcome.

Most adoption problems are product problems, not change management problems.

The change management response assumes resistance is behavioral: people need education and encouragement, and with the right messaging they will come around. The assumption is usually wrong. People do not resist a new system because it is unfamiliar. They resist because it has not yet made their work easier. That is a product gap, not a communication gap.

Every organization contains an informal market. Employees continuously choose how to get work done, which tools to trust, and which systems to invest time in. Even when a platform is mandated, people exercise choice. They build workarounds and return to familiar tools when no one is watching. These behaviors are signals. They indicate the platform has not earned preference, and preference cannot be mandated.

When a product improves how people work, adoption moves quickly with little promotion. Users tell each other. Workflows consolidate. The platform becomes the default because it removed friction from something people were already doing. When that does not happen, messaging produces temporary compliance followed by drift.

Organizations reach for change management first because it is easier to execute, not because it works better. Improving a platform requires redesigning workflows, restructuring ownership, consolidating systems, and fixing data problems. A communication campaign launches in a week and produces visible activity immediately. It gives the appearance of progress without the system work.

The useful reframe is to stop asking how to get people to use the platform and start asking why they would choose to. That moves responsibility from user behavior to the quality of the experience. Does the platform reduce friction in real work? Does it create a clear source of truth or add to the fragmentation? Does it fit how teams already operate, or does it require them to abandon workflows that function?

Teams never arrive at a new platform from zero. They bring existing workflows and habits built over years. A new system competes with that by being better at the things that matter most. Platforms that win become the easiest place to complete important work. Platforms that lose add steps, introduce ambiguity, or ask users to carry the cost of a system that has not earned its place.

The practical consequence is a different reading of the metrics. Launch is not adoption. Slow adoption is not failure. It is specific feedback that the platform has not reached fit with how the organization works, and the response to that information is iteration rather than persuasion. Read this way, low adoption is one of the more useful signals a platform team receives, with the diagnostic value and the accountability that implies.