What To Do When Adoption of an Internal Tool/Process Stalls
Internal tool adoption stalls for the same reason products fail: building without understanding the user. What IT and Ops leaders can borrow from product management to actually move the needle on adoption.
Internal adoption is product work
You paid for the license. JIRA Align. Copilot. ChatGPT. Maestro. Pendo. Gong. ServiceNow. Snowflake. Cascade. Monday. ClickUp. Or maybe it is not a tool at all. Maybe it is OKRs, Scrum, Agile, SAFe, Force Management, or the latest internal process you are deploying.
Now you are trying to maximize usage and show ROI. You create playbooks. You train everyone. One early warning sign is when getting people into training feels like herding cats. Then, at some point in the adoption conversations, you feel nobody is there with you. It is like the dancing guy video, but nobody joins.
It feels like you built it and nobody came.
Here is the thing: deploying a product or process internally is like developing a product. Yes, the product may already exist. The features are there, ready for internal users to use. But the fact that a feature exists does not mean people want to use it. It does not mean they will use it, even if you ask, and especially if you tell.
So what do you do? See yourself as responsible for maximizing value, not adopting a tool. Figure out what problems your users have and what outcomes matter. If managing adoption of an internal product or process is like managing a product, IT and Ops leaders have a lot to borrow from product management.
Practical thinking on turning AI pilots, adoption, and portfolio work into business impact - by finding the constraint, changing the work, and proving value as you go.
Yuval Yeret helps product and tech leaders move from agile theater to evidence-informed delivery. Work with Yuval →
