There is a question I have started asking when colleagues show me a new AI tool they have built. It is not "what does it do" or "what model is behind it" or "how does it perform". The question is: who, specifically, is opening this every day in three months' time, and what would have to be true for them to keep coming back?
The answers are revealing. Sometimes the question lands and you can see the builder mentally fast-forward through the next quarter and admit that nobody has been picked, the user journey is unmapped, the workflow integration is theoretical. Sometimes the builder can answer cleanly: a sales manager, every Monday morning, because the alternative is opening eight tabs and writing the same three queries by hand. The clean answers correlate, in my experience, with the tools that go on to matter.
The question is a proxy for an older argument that the AI industry keeps relearning the hard way. You can optimise for capability, where the goal is the technical impressiveness of the artefact, or you can optimise for adoption, where the goal is durable use by people doing real work. Capability is cheaper to demo. Adoption is expensive to earn. The current AI cycle is almost entirely funding the demos.
Why capability-first wins demos and loses deployments
Capability-first thinking is rational at the level of the individual builder. You have a budget, a deadline and a stakeholder who needs to see progress. The fastest path to "progress" is a slide deck with a working prototype. The prototype shows the model doing something it could not do six months ago. The stakeholder is impressed. The slide deck moves up the chain. You get the budget for v2.
Nothing in that cycle requires that anyone actually use the prototype. The prototype is the evidence of progress. Use is downstream, somebody else's problem, conveniently invisible until the all-hands six months later when somebody asks why ROI is hard to point to.
Adoption-first thinking inverts this. The goal is not to demonstrate that the tool can do something. The goal is to demonstrate that someone has stopped doing it the old way. The metric is not "does the model produce the output", it is "what was the worker doing in this fifteen-minute window six weeks ago that they are not doing now". Capability is necessary but not sufficient. Adoption is the actual deliverable.
The reason this matters is that AI capability is no longer a differentiator. Five different vendors can ship the same capability inside a quarter. What none of them can ship for you is the operating change inside your business that turns that capability into compounding productivity. That is yours to build. And it is built one careful adoption decision at a time, not in a launch announcement.
Four design choices that change the adoption curve
I am going to skip the high-level platitudes and get into the four concrete design choices I see distinguishing tools that compound from tools that decay.
Pick the user before you pick the capability. Most AI tools are built by picking a capability ("we should do meeting summarisation") and then handing the result to a vague audience ("anyone in sales"). The tools that stick reverse this. Pick a specific person. Map their week. Find the single task you can take off their plate. Build for that. The capability is determined by the user, not the other way around.
Reduce, do not expand. The first instinct in every AI product I have built was to add options, settings and modes. The user does not want options. The user wants one good default. If the tool needs configuration to be useful, the tool is not useful. Strip the v1 down to the single workflow you are confident in. Add options later, only when actual usage demands them. The user will tell you what to add. They will not tell you what to remove, because they will simply have stopped using it.
Build for Monday morning, not Friday demo. Demos run on best-case prompts and clean inputs. Monday morning runs on rushed prompts, half-typed queries and a user who has not yet had their coffee. If the tool only works in the demo configuration, the tool does not work. Stress-test against the actual conditions of the actual user. The model is fine. The brittleness lives in the gap between what the user types and what the tool needs to function.
The story is half the product. I have shipped tools that were technically sound and saw no uptake because the framing was wrong. I have shipped lesser tools that saw immediate adoption because the framing was tight. The story is not a marketing concern, it is a design concern. The story tells the user what to expect, what behaviour the tool replaces, how to fit it into the week they already have. Skip the story and the tool is just another browser tab.
The adoption test before you build
The single most useful question I have stolen from product management and applied to internal AI tooling: write the launch announcement first. Before you write a line of prompt logic, write the email that announces the tool to its users.
If the announcement reads as a list of features, the tool is not ready to build.
If the announcement reads as a description of how someone's week is going to change, the tool is worth building.
The discipline of writing the announcement first forces you to commit to a user, a workflow change and a concrete shift in behaviour. It is the same discipline as Amazon's "working backwards" approach but applied to internal tooling, which is where the discipline is most often skipped. Try it on your next AI tool. You will find about a third of your backlog quietly disappearing.
What this means for the AI buyer
Most readers of this will not be the people building AI tools. You will be the people approving budget for them.
The single most valuable question you can ask the people pitching you an internal AI initiative is the question I started this essay with. Who, specifically, is opening this every day in three months? What would have to be true for them to keep coming back?
The pitches that fall apart under that question are the pitches that were going to fail anyway. Saving the budget upstream is cheaper than mourning the unused tool downstream. The pitches that survive the question are the ones worth funding, and they are the ones you should fund generously.
There is a version of the AI cycle in 2027 where the businesses that pulled ahead were the ones who funded fewer initiatives more deeply, with sharper user clarity, and refused to celebrate launches that nobody actually used. I think that version is the one that wins. Adoption-first is not a style preference. It is the only way I can see for an AI strategy to actually compound.