PM Response When Internal Users Reject a Newly Launched Tool

Your team has just shipped a new tool built for an internal customer team. That team is refusing to adopt it: they believe the new system will do little for their work. As the product manager, how would you handle the situation? ```hint Test the objection before answering it Before planning how to win the team over, work out whether their complaint points at a gap in the tool itself or at a gap in how it reached them; the two call for very different responses. ``` ### Clarifying Questions - Which team is the internal customer, and which part of their daily work is the tool meant to replace or support? - Was that team involved in defining requirements or testing the tool before release, or is this their first real look at it? - Is adoption mandated by leadership, or can the team keep its current process indefinitely? - What outcome was the tool built to deliver, and who sponsored it: the customer team, its leadership or another group? ### What a Strong Answer Covers - A diagnosis of why the team resists, grounded in direct conversations and usage evidence rather than assumption - An honest test of whether the tool actually improves this team's work compared with how they work today - A response matched to the diagnosis, covering both changes to the product and changes to how it is rolled out - How the resisting team, its leaders and the team that built the tool are kept aligned, including what happens if the objection turns out to be valid - Adoption and outcome measures that show whether the situation is resolved ### Follow-up Questions - If you find the tool really does make the team slower at its core task, what do you do with the release, and how do you tell the engineers who built it? - Leadership proposes forcing adoption by switching off the old process. How do you respond? - How would you change the way your team builds internal tools so this does not happen again?