Draft for Tamir's review. Not published.
Find the cause where the work happens
Sit with people who avoid the system and record what takes longer or works worse. Classify the reasons: missing function, speed, wrong data, training or habit. Wrong migrated data drives many refusals, so check it for their accounts.
Look at what the system logs, including refused, overridden and abandoned requests. Overrides often show constraints the system does not know, such as storage space or local events. Disabled alerts often show floods nobody can act on.
Fix, then switch off the old way
Fix the top complaints before a set date and tell people what was fixed. Make the new system the only source for the numbers that matter, and tie processes such as commissions or reviews to its data. Name a business owner for adoption with authority over the units.
Before renewing a tool people disabled or overrode, find out why. Check what the vendor's warranty or support covers for the fixable items.
Depending on your seat
If you're on the board and management wants to keep funding, set a decision rule. Name the measure that would show a future, the value it must reach and the date. Fund to that date and decide on the number.
If you lead a product, ask customers what they did instead of using the feature. Three causes are common: its place in the workflow, results they don't trust, or a problem they don't have. Only the last means the feature should go.
What to check before you decide
- Sit with people in three units or teams and record what they do instead, and why.
- Classify the reasons: missing function, speed, wrong data, training or habit.
- Check the migrated data behind the complaints.
- Pull refused, overridden and abandoned actions from the logs, with the user's reason where known.
- Fix the top complaints, then set a date to switch off the old system or source.
- Name a business owner for adoption with authority over the units.
- Agree one measure, a target value and a date that decide further funding.
Questions people ask
Our digital product has few users a year after launch and management wants to keep funding, how does the board decide?
Set a decision rule rather than a feeling: the measure that would show the product has a future, the value it must reach, and the date. Fund to that date with the rule written, and decide on the number. It depends on whether the product solves a problem users have and on whether management can name what would change the number.
New system is live, half the sales team won't use it and my numbers disagree, how do I fix this?
Find out what the system makes harder for the people refusing it, because resistance usually points at a real problem in the design or the data. Fix that, make the system the only source for the numbers that matter, and stop reporting from the old source on a date. It depends on whether the refusal is about effort, about trust in the data or about losing control of their accounts.
Customers barely use our AI features but the team wants more AI, what do I decide?
Find out why they skip them: wrong place in the workflow, results they do not trust, or a problem they do not have. Each has a different fix and only the last means the feature should go. Make the next AI investment conditional on a measured answer. It depends on what customers say when asked and on whether the features change an outcome they care about.
Our new system was delivered and accepted but staff still use the old one, what do I do?
Find out what the new system makes worse for the staff who avoid it, because acceptance tested functions and staff test their day. Fix the few things that block daily work, set a date to switch off the old system, and support the staff through it. It depends on whether the problems are missing functions, slow performance, bad data or habit.
Demand responsive transport pilot has low ridership, vendor blames marketing and we suspect the algorithm, how do we find out?
Look at the trip data: requests refused, pickup delays, detours and cancellations tell you whether riders tried and left. If service quality is fine and requests are few, marketing or service design is the issue. It depends on what the software logs and on whether you can see refused and abandoned requests.
Should we renew an alarm tool after operators disabled it?
Investigate why alerts became unusable before renewing. The decision depends on actionable signal quality, configuration responsibilities, and whether the tool improved operators' actual response.
Should we expand retail planning AI when stores keep overriding its recommendations?
Represent operational constraints before judging recommendation quality. The decision depends on storage, assortment rules, local events, and whether exceptions are governed or merely hidden in staff knowledge.
How I can help with this decision
- Ask or talk (Free)
- I give my view on what non-adoption like yours usually hides, and the visits or data that show the cause.
- Review (Pay if it was worth it)
- I write an independent assessment of the system's fit, the data and the adoption problem. I recommend fixes, a switch-off plan and a decision rule, or a stop.
- Retain (When it makes sense)
- I stay close through the fixes to review adoption results against the measure you set.