Why systems fail on adoption rather than engineering, and the question that would have told you
There is a meeting that happens about three weeks before launch. The build is done, testing is green, and someone asks how we are going to get people to use it. The answer is always some combination of communications, training and a launch event. It goes on one slide. It is the least examined slide in the deck.
Six months later the platform works exactly as specified, and a third of the people who were supposed to use it are still doing it the old way.
The engineering question, will this work, gets months of scrutiny, formal review, and people whose job it is to say no. The adoption question, will they use it, gets a slide and a training budget. The second one is what kills platforms.
I have been on both sides of this. Here are five ways it goes wrong, drawn from things I have built and one thing I watched fail.
1. Adoption is scheduled after the build, as though it followed from it
Communications and training are planned for the weeks after go-live. That sequencing contains an assumption: that people are not using the system because they do not know about it.
Sometimes true. Usually not. People know about it and have decided the terms are not worth it. The effort of changing. The loss of control. The exposure of something they would rather not expose.
Communications does not fix terms. If the terms are wrong, a better launch email produces a better-informed refusal.
Years ago at Ericsson I led the design team on the Global Village Project, bringing a data network to a remote town in Ondo State, Nigeria, to carry telemedicine and digital educational material. It was delivered through a consortium: a multilateral funder, the mobile operator, the national regulator and local government. The engineering was demanding but tractable. Coordinating four organisations with different interests was harder, and it was the part that determined whether anything survived once the funding that built it stopped.
That project is the reason I now assume the constraint is rarely technical.
2. The people who must adopt are not the people who commissioned it
This year I built InventPulse 360, a governed reporting platform consolidating eight profit and loss entities, with roughly 400 metrics under versioned definitions.
A governed metric layer only works if people stop using their own spreadsheets. The platform cannot make them. It can be technically correct, fully lineaged, right in every figure, and still sit beside a finance lead's own workbook that they trust more, because they built it and they know what is in it.
The board commissioned the platform. The finance leads have to change how they work. Those are different people with different incentives, and the second group was not in the room when the decision was made.
If you are building something whose value depends on a behaviour change by people who did not ask for it, that is your risk. Not the architecture.
3. Nobody asks what would make them refuse
Requirements gathering asks what people want. It almost never asks what would make them walk away.
These are not opposite questions, and the second is far more predictive. What someone wants is a wish list, weakly held and subject to revision. What would make them refuse is a constraint, firmly held, and usually a much shorter list.
Earlier this year I wrote to a national membership body about an idea that involved organisations contributing operational data to a shared platform. The reply contained one sentence worth more than a month of requirements workshops: it would be unusual for their members to share what they would consider data with anyone other than their funders and their regulator, because most of it is treated as confidential.
That is a refusal condition. It arrived in an email, before anything was designed, and it reshaped the entire idea. It would never have surfaced from a question about desired features.
4. Joining and staying are treated as the same decision
Launch metrics measure sign-ups. Almost nobody designs for the moment eighteen months later when the terms change: a new fee, a wider use of the data, a governance restructure.
There is good reason to think these are different decisions. People evaluate a change to something they already have differently from an opportunity to acquire something they do not. The same arrangement can be attractive as an offer and unacceptable as an alteration.
If that holds, then what you learned at launch about what recruited people tells you very little about what will keep them. Platforms designed on recruitment evidence end up governed on the wrong assumptions.
5. The thing that would settle it is never measured
Ask five people why adoption will or will not happen and you will get five confident, conflicting answers. It is the cost. It is the effort. It is who controls it. It is that nobody trusts the vendor.
All plausible. All argued. Almost never tested against each other.
On a property data platform I am currently product lead for, we disagreed about how the product should be packaged and priced. Rather than settle it by seniority, we designed a way to find out with the pilot customer. The answer was not what either side had expected, which is the usual result when you check.
That is the whole move. Treat the adoption question as measurable rather than arguable.
The uncomfortable part
Adoption work looks like delay. Asking whether people will use something before building it sounds like a reason not to build it, and there is always pressure to ship.
It is also unglamorous. Nobody is promoted for the platform that was not built because the evidence said it would not be used, even where that is the highest-value outcome available.
But the cost is asymmetric. Establishing the refusal conditions takes weeks. Discovering them after launch costs the build.
What I would actually do
Ask the refusal question early, and ask it of the people who would refuse rather than the people who commissioned it.
Write down the competing theories about what drives adoption, and treat them as hypotheses rather than opinions.
Design for the change, not just the launch. The terms will move, and the people you recruited did not sign up for the terms you will eventually have.
I have spent the past year reading the research on this. The honest summary is that we know a great deal about which factors influence whether an organisation adopts a system, and remarkably little about what each factor is worth relative to the others. That gap is why these arguments never resolve. It is also, I think, solvable, which is what I want to write about next.
I am a product and platform consultant working on governed data and AI platforms. Client, entity and vendor identities are omitted throughout. Figures referenced are architectural and delivery facts.