Knowledge Base · Software & AI
How do I get people to actually use a new tool after launch?
Involve the team in choosing and testing it, train hands-on with real work, adjust workloads during the learning curve, and measure outcomes rather than logins. The book's failed CRM and rescued scheduling system teach the same rule from opposite ends: adoption is a people problem long before it is a software problem.
Adoption fails for human reasons far more often than technical ones, and the book's two software stories bracket the lesson. In Chapter 7, a bank's CRM died because training was one webinar and a PDF, workloads were never adjusted, and the people expected to use it had no part in choosing or shaping it. In Chapter 5, a leader's second scheduling system succeeded only after he involved the team in picking it: they named the features they actually needed and tested options before choosing.
The adoption pattern that falls out of the book is consistent. Involve early: people defend what they helped build, and resist what was done to them. Equip properly: hands-on training with realistic scenarios from the team's real work, plus named super-users in each team who learn first and coach their peers. Protect the learning curve: adjust targets and workloads while people are beginners, or the old spreadsheet will always win because it is faster today.
Then measure the right thing after launch. Do not track logins or licences activated, which are the vanity metrics of adoption. Track the outcome the tool exists to improve, the Chapter 5 discipline: response time, completion rate, follow-up consistency. If the tool genuinely will not move that outcome after people have been properly equipped and involved, the book's verdict is honest: stay loyal to the outcome rather than the tool, and be willing to replace it.
One more lever from Chapter 7: watch the first weeks at the gemba. Sit with real users doing real work and you will see the workarounds the training missed: the extra field nobody needs, the step that doubles a busy person's clicks. Fixing those small frictions visibly, and quickly, is how a sceptical team decides the tool is theirs.
Related questions
- What do I do when a new tool flops with my team?
- What is the knowledge gap in continuous improvement, and how do I close it?
- What software do I actually need for continuous improvement?
Source: Continuous Improvement in the Workplace, Ch. 7 (Pitfalls to Avoid in Continuous Improvement Initiatives) and Ch. 5 (Measuring Success and Ensuring Sustainability).