An unused tool is a failed project

There's a meme that does the rounds in every builder community, and it stings because it's true. Two doors. Behind one, an enormous queue of people building AI apps. Behind the other, one person, standing alone: the users.

Inside firms, the same picture just wears a lanyard. The tool gets built, the demo gets applause, the launch email goes out — and three weeks later the usage dashboard is a flatline. Nobody says the project failed, because the deliverable was delivered. But an unused tool is a failed project, however elegant the build. The only honest metric is week-six usage.

01Why good tools die

It's rarely because the tool was bad. In my experience the causes are mundane and almost entirely predictable:

• It lives in the wrong place. A new portal, a new login, a new tab. If the team works in Excel, Outlook and the deal drive, a tool that lives anywhere else is fighting gravity daily.
• It was built for the team, not with them. The people who were supposed to use it first saw it at launch. They had no stake in it, so they had no patience with its rough edges.
• Nobody re-shaped the workflow. The old process stayed in place, so the tool became an optional extra step — and optional extra steps lose to deadline pressure every single time.
• Training was a launch event, not a habit. One demo session, then silence. The first time the tool did something unexpected, people quietly went back to the old way.

The research backs the intuition. MIT's study of enterprise GenAI found the core failure wasn't model quality but the "learning gap" — organisations feeding shiny tools into workflows that couldn't absorb them, with adoption driven top-down by central labs rather than by the line managers who own the actual work^[1]. And people clearly want to use AI: Microsoft found 78% of AI users bringing their own unsanctioned tools into work^[2]. When official tools go unused while personal ChatGPT accounts thrive, the problem is not appetite. It's fit.

02The 70% nobody budgets for

BCG's rule of thumb for AI transformation is 10-20-70: roughly 10% of the effort is the algorithms, 20% is technology and data, and 70% is people and process — training, workflow redesign, governance, communication, support^[3]. Most internal AI projects invert this. They spend 70% on the build, 20% arguing about data access, and whatever's left on a launch email.

03What embedding actually looks like

Embedding isn't a phase after the build. It's a set of decisions made throughout, and it's most of what I actually do on an engagement:

The go-live email is not the finish line. Week six is the finish line. If the team is still using the thing in week six — without you chasing them — you shipped. Anything else was an expensive demo.

04The uncomfortable corollary

If an unused tool is a failed project, then some projects should die before the build — and saying so is part of the job. Gartner expects over 40% of agentic AI projects to be cancelled by 2027, mostly for costs and unclear value that were visible at the start^[4]. The cheapest failed project is the one you never green-lit. That's why I put so much weight on use-case discovery done properly: an afternoon of prototyping with the actual team tells you more about eventual adoption than a quarter of requirements gathering.

Build less. Embed more. The queue at the wrong door is long enough already.