Adoption is the unglamorous half

Building the system is the half with the architecture diagram in it. The half that decides whether anyone opens the thing in month three has no diagram at all. It is mostly a refusal to skip the boring parts, and it is where every rollout is actually won or lost.

Open with a diagnostic question, not a pitch

The first question I asked a reserve-study firm was not what I could build for him. It was what the agency he paid a thousand dollars a month was actually doing for him.

Blog posts, page creation, analytics. Two follow-up questions later the real picture arrived: he was writing most of the blog content himself, supplying every image, and doing the analytics on his own. He was paying a thousand a month for coordination on work he was already doing.

He diagnosed his own problem while answering me. That is worth more than any diagnosis I could have handed him, for a reason that has nothing to do with accuracy: a diagnosis you are handed gets evaluated, and one you arrive at yourself gets defended.

Build something before writing a proposal

I did not fully understand the need yet, so rather than write about it I went and built. A working artifact beats a scoping document twice over. It is more convincing, and it surfaces the misunderstanding early, while correcting it is still cheap.

A proposal gets agreed to. A working thing gets argued with, and the argument is the useful part.

Treat the handoff meeting as the deliverable

Not a document drop, not a recorded walkthrough. One working session, and it ends with his account configured: the plan picked, the settings changed, connected to the model, the repository and the deploy target. Then we test things live, together, so he watches the pieces work instead of reading that they do.

Anything he does not understand becomes a written guide that same day. The documentation is generated from observed confusion rather than from my guess about what would confuse him, which is why it is short and why it gets read.

Setting up somebody else’s account is the least impressive-sounding step in the entire engagement. It is also where rollouts quietly die, because a system nobody can log into is a system nobody uses, and no one will ever tell you that is the reason.

What the unglamorous half bought

A three-person operation now performs the function of a team of fifteen, and it has already saved more than a thousand dollars a month. We are still early on it. The saving is his, not my revenue: that engagement is pro bono, and a dollar figure floating free of an owner implies otherwise.

At larger scale it looks identical and photographs no better. More than a hundred people open the system I built at work every day, and more than twenty of them were onboarded and trained by me personally, one at a time.

And then leave

The goal is that they run it without me. A system that only works while I am in the room is a system I built badly. The test is not the launch, which everyone attends, and not the demo, which everyone enjoys. It is month three, once the novelty is gone and nobody is asking me anything.

Adoption is not a training problem and it is not a change-management problem. It is a trust problem. People stop using a system the first time it confidently tells them something wrong, and they do not come back. Every unglamorous step above exists so that first time never happens.