Here is a common story.
A platform team spends six months building an internal developer tool. It's technically sound. The team is proud of it. They do a launch announcement. They run demos. They write documentation.
Three months later, adoption is at 12%. The team writes more documentation. Leadership mandates the tool. Adoption climbs to 60% on paper, but anyone who looks closely can see engineers routing around it wherever they can.
The platform team is confused. The tool is good. Why won't people use it?
The Wrong Diagnosis
The default diagnosis is communication. We didn't explain it well enough. We need more documentation, more demos, more internal marketing.
The second most common diagnosis is change management. People resist change. We need champions, we need executive sponsorship, we need to bring people along on the journey.
Both of these are wrong. Or rather — they're downstream of the real problem.
The real problem is that the tool is working against human behavior.
How Adoption Actually Works
I've watched a lot of developers interact with a lot of tools. Here is what I've observed:
Developers adopt tools the same way they adopt any behavior: when the new way is easier than the old way, and when the cost of transition is lower than the benefit of switching.
This sounds obvious. It isn't. Because the people who build internal tools almost always underestimate the cost of transition and overestimate the perceived benefit.
The transition cost isn't just learning the tool. It's the mental model switch. It's the moment where the new system asks you to think about something differently than you were already thinking about it. Every one of those moments is friction. And friction compounds.
The Disappearing Tool
The best internal tools disappear.
You don't notice when they're working. They don't interrupt your flow. They don't ask you to remember things. They surface information exactly when you need it and stay out of the way when you don't.
This is harder to build than a feature-rich tool. It requires deep observation of how developers actually work — not how we think they work, not how the JIRA tickets say they work. How they actually work.
It requires removing things as much as adding them. It requires accepting that a tool with fewer features but better integration will beat a tool with more features and more friction every time.
What This Means for Platform PMs
If you own an internal developer platform, here is the question I'd ask about every feature you're considering:
Does this reduce the number of decisions a developer has to make, or does it add one?
Every decision you add is a decision that costs attention. Attention is the scarcest resource your users have. The tools that win are the ones that spend it carefully.
The best endorsement an internal tool can receive is not "the team loves it." It's "I forgot it was there."