The hardest sentence in my job is "nobody uses it". Not "it does not work" — it works, it passed testing, it demos well. It just sits there.
My MD wrote the rule into my scorecard before I could argue with it: a tool that gets built but nobody uses scores zero. Not half marks for effort. Zero. It is the most useful constraint anyone has put on my function, and the first year of running against it changed how my team ships.
Why good tools die
When I went back through everything we had built and sorted it into used and unused, the unused pile had patterns.
- It solved a problem the team did not feel. We measured it, leadership agreed it was expensive, and the people doing the work had already built a workaround they were comfortable with.
- It required a behaviour change with no owner. Someone had to start doing something differently on a Monday morning. Nobody in that department had agreed to be the person who made that happen.
- It lived somewhere new. Another login, another tab, another app. Attention is finite and a new URL is a real tax.
- Training was an event, not part of delivery. One session, no follow-up, and the tool quietly stopped being used in week three.
- It shipped without a name attached. No business owner meant no one to ask when it broke, and nobody whose week got worse if it went away.
Who, by name, will be worse off if this does not exist? If I cannot answer that, we are building for an idea of a user rather than a person.
What actually makes it stick
A named owner in the business, agreed before the build. Not a stakeholder list. One person whose work the tool changes, who has agreed to use it and to tell me when it is wrong.
Land it inside an existing workflow. The tools with the best adoption in our estate are the ones people did not have to go anywhere to use. The answer arrives in the system they already have open, or in a message they already read.
Training as delivery, not as a follow-up. If the handover is a session, the tool is already at risk. Sit with the team for the first week of real use. That is when you find out that the field on screen two has a name only IT understands.
Bilingual where the users are bilingual. Our teams work in Hindi and English. A tool that only speaks one of them has narrowed its own audience for no reason.
The confirmation, in writing
The change that made the biggest difference is small and slightly awkward. An outcome is not done when we ship it. It is done when the department head confirms, in writing and with a date, that their team is using it.
They are not asked to rate the tool or the person. One sentence: yes, my team is using this, as of this date. No confirmation, no credit. It takes the argument out of performance reviews, and it surfaces the uncomfortable cases early, while there is still time to fix them.
Report the zeros
When I present the estate to the board, I show three columns: in use, built but not adopted, and not started. The middle column is the one people skip. I put it first in the conversation, with a date against each row: either it gets adopted by then, or we switch it off.
Switching things off is part of this. Unused software is not neutral. It carries maintenance, security surface and support load, and it clutters the story of what the function actually does.
None of this is an argument for building less ambitiously. It is an argument for finishing. A pilot that nobody moved onto is not a milestone, it is a cost — and the scoreboard should say so.