← All writing

Adoption is the metric

Internal tools don't fail at launch. They fail three weeks later, quietly.

5 min read

Every company of any size has a graveyard of internal tools. The dashboard someone demoed to applause and nobody opened again. The portal that was going to replace the spreadsheet, right up until everyone kept using the spreadsheet. The tools in that graveyard have one thing in common: the team that built them measured delivery, and nobody measured what happened next.

I've spent most of two decades building platforms for demanding internal users, and the single most useful thing I believe is this: adoption is the metric. Not launches, not features, not the demo. Whether people open the thing tomorrow morning without being told to.

Shipped is not done

Delivery is a milestone the building team controls, which is exactly why it's a seductive metric. You can hit it by working harder. Adoption is different. It's a verdict rendered by busy people who owe you nothing, every single day, and you can't make the verdict come out your way by staying late.

That changes how you build. If the goal is delivery, you optimize for scope and dates. If the goal is adoption, you optimize for the first thirty seconds of a skeptical user's morning: does this answer the question I actually have, faster than the way I answered it yesterday, with numbers I trust? Miss any one of those three and the tab quietly stops getting opened.

Discovery means watching, not asking

Users are excellent at describing their pain and unreliable at prescribing their cure. Ask what they want and you'll get a faster version of whatever they already have. An export button. One more column. A refresh that runs at 6am instead of 7.

So I watch instead. Sit next to someone doing the real workflow and the requests decode themselves. The person asking for the export button doesn't want the export. They want to reconcile your numbers against the source they already trust, because they've been burned before. Build the export and you've added a feature. Build the reconciliation into the product, visibly, and you've removed the reason the export was wanted at all. What people ask for is a clue about what they need. It's rarely the answer.

Make the right way the easy way

Governance that lives in a policy document loses to convenience every time. People don't route around the golden path because they're careless. They route around it because it's slower than the shortcut. The fix isn't a sterner document. The fix is making the governed path the fastest one available: one place where the metrics are defined, one way to get them, and tooling pleasant enough that the shortcut feels like extra work.

When the right way is the easy way, adoption and governance stop being rivals. Every new user makes the numbers more consistent instead of less.

Trust compounds, and so does its absence

A platform earns adoption one correct number at a time and loses it much faster. Show a serious user a wrong figure twice and there is no roadmap feature that wins them back. This is why the unglamorous work, data tests, lineage, reconciliation against the sources people already believe, is not a tax on the real work. It is the real work. Trust is the product's load-bearing wall.

The compounding runs the good direction too. Once a team trusts the platform, they bring it their next problem before you've heard about it. Demand starts pulling instead of you pushing. That inversion, when it happens, is the clearest signal you'll ever get that the thing you built is now infrastructure.

Measure habits, not launches

If you measure delivery, you'll celebrate launches. If you measure adoption, you'll build habits. The platform I'm proudest of isn't impressive because of what's in it. It's impressive because dozens of people who could ignore it choose to open it every morning. That choice, repeated daily by people with other options, is the only review that counts.