AI has made it cheap to build almost anything. That is exactly why most AI initiatives fail, and they fail before a line of code is written.
The old constraint was engineering. Building was slow and expensive, so the discipline lived in execution: ship the thing, make it work, optimise it. AI collapses that cost. A capable team can now prototype a credible version of almost any idea in days. The bottleneck has moved, and most organisations have not noticed. The scarce skill is no longer building the thing. It is choosing the right thing to build, and that is a muscle most teams never had to develop because the cost of building used to do the choosing for them.
So the failure mode has moved upstream. The projects that collapse rarely collapse because the team could not build them. They collapse because the team built something nobody needed, solved a problem that was not painful, or chose a place where AI was the wrong tool, and no amount of engineering excellence rescues a well-built answer to the wrong question.
The initiative that started with the answer
The pattern is easy to spot once you know its shape. It starts at the top, with a sentence like "we need an AI strategy" or "we should be using AI here." The decision that AI is the answer is made first. Then a team is sent to find the question: to hunt through the product for somewhere to apply the technology that leadership has already committed to.
This is a solution in search of a problem, and it runs backwards. The team is not asking "what is our most painful, frequent, valuable problem, and what is the best way to solve it?" They are asking "where can we plausibly bolt AI onto what we already have?" The output of that search is almost always a feature that demos well, impresses the steering committee, and quietly goes unused, because it was built to satisfy a mandate rather than to relieve a real pain.
The tell is the order of reasoning. When the technology is chosen before the problem, discovery becomes a justification exercise: the conclusion is fixed and the team works backwards to defend it. Real discovery can end in "AI is not the right tool for this," and an initiative that cannot reach that conclusion is not discovering anything. It is rationalising a decision already made.
Discovery starts from the problem, not the technology
The correction is almost embarrassingly simple and almost never done: start from the problem. Not from AI, not from a competitor's launch, not from a board member's enthusiasm. Start from a specific, observed, painful thing that specific people do today, and only then ask what the best tool to help them is.
This sounds obvious because it is the oldest rule in product, but AI breaks people's discipline about it in a way few technologies do. The capability is genuinely impressive, the demos are genuinely seductive, and the pressure to be seen doing something with AI is genuinely intense. All three push teams to lead with the technology and reverse-engineer a use for it. Resisting that pull is most of the job.
The practical move is to keep the problem and the solution strictly separate for as long as possible. Describe the problem in a way that does not mention AI at all: who has it, how often, what it costs them, what they do today, why that is bad. If the problem does not stand on its own as worth solving once the word "AI" is removed, it was never a problem worth solving. It was an excuse to use the technology, and the technology will not save it.
The four questions before you build
Before committing to build anything with AI, four questions decide whether it is worth it, and skipping any one of them is how good teams end up with expensive, unused features.
The first: is this a real problem? Not a hypothetical one, not a nice-to-have, but something people visibly struggle with often enough and painfully enough that they would change their behaviour to get relief. The second: is AI actually the best tool for it? A great many problems framed as AI problems are better solved by a form, a rule, a better default, or fixing the underlying process, and reaching for a probabilistic model when a deterministic one would do is a common and expensive mistake. The third: can you tell whether it worked? If you cannot define and measure success before you build, you will not be able to tell a working system from a broken one after you ship, and for probabilistic systems that is fatal. The fourth: is it worth the cost, including the ongoing cost to run, maintain, and watch it, not just the cost to build it once?
A real problem, where AI is genuinely the best tool, with a measurable definition of success, that clears its full cost. Only the ideas that pass all four earn a build. The value of the four questions is almost entirely in the ones they kill.
The demo trap
The single most expensive mistake in AI product decisions is mistaking a good demo for a viable product. AI is uniquely good at producing an impressive demo, because a demo is a curated happy path and a language model on a happy path looks like magic. That magic is real, and it is also the easy ten percent.
The hard ninety percent is everything the demo skips. The messy real inputs instead of the clean example ones. The edge cases, the ambiguous requests, the adversarial users, the long tail of situations the demo never showed. The integration into a real workflow where people actually are, rather than a standalone screen they have to remember to visit. The reliability needed to trust the output, the handling for when it is wrong, the cost at full volume, the monitoring to know it is still working. None of this shows up in the demo, and all of it is where the effort, the risk, and the value actually live.
So the demo is the beginning of the question, not the answer to it. The right response to a compelling AI demo is not "ship it," it is "now show me the ten hardest real cases, the cost at scale, and how we will know when it breaks." A decision made on the strength of the demo is a decision made on the easiest ten percent of the problem, and the ninety percent you did not look at is the ninety percent that decides whether it works.
Where AI actually earns its place
Part of choosing well is knowing the shape of problem where AI is genuinely the right tool, rather than the most exciting one. The technology has a grain, and working with it is far easier than working against it.
AI earns its place where the work is high in volume and language or pattern heavy, where perfect accuracy is not required and a good answer most of the time beats no answer at all, where a human can cheaply check or correct the output, and where the cost of a mistake is bounded and recoverable. Summarising, drafting, classifying, extracting, routing, and surfacing the right thing from a large pile: these play to the grain. The technology is probabilistic, so it fits problems that tolerate being right most of the time.
It works against the grain exactly where the opposite holds: where the answer must be exactly right every time, where a single error is costly or irreversible, where the logic is simple and deterministic and a rule would be more reliable and cheaper, or where there is no way to check the output and no tolerance for it being wrong. Forcing AI into those places is how you get an unreliable version of something a simpler tool did perfectly well, and recognising them early is as valuable as recognising the good fits, because it stops a build before it starts.
Killing the wrong bets early
Because building is now cheap, the expensive thing is commitment: the months spent, the roadmap displaced, the organisational attention spent defending a bet that should have been killed. The discipline that matters most in AI product work is the discipline of the early no, and it is the one most organisations are worst at.
The reason they are bad at it is not analytical, it is social. Once a team has demoed something impressive and leadership has seen it, killing it feels like failure and admitting waste, so the dead idea limps on, absorbing resources, because no one wants to be the one who stops it. The fix is to make killing cheap and expected by deciding, before you build, what would prove the idea wrong, and to run the cheapest test that could produce that disproof first. A fake door, a manual version, a tiny pilot with real users, a back-of-envelope on the unit cost at scale. The goal of early discovery is not to prove the idea works. It is to find the fastest, cheapest way to find out that it does not, so you spend your real build budget only on the bets that survived a genuine attempt to kill them.
A team that kills nine ideas cheaply to fund one that works is far ahead of a team that half-builds all ten, and the difference is almost never talent. It is the willingness to say no early, out loud, on purpose.
A portfolio, not a moonshot
Put it together and the shape of good AI product work becomes clear. It is not a single bet-the-company moonshot, and it is not a hundred half-finished experiments. It is a disciplined portfolio: many ideas entered cheaply, most killed fast, a few survivors funded properly and taken all the way through the hard ninety percent to something people actually rely on.
That requires holding two things at once that feel contradictory. A low cost of starting, so ideas are easy to try and the organisation explores widely. And a high bar for continuing, so only the ideas that clear the four questions and survive a real attempt to disprove them get the expensive commitment. Teams that get only the first half generate endless demos that never ship. Teams that get only the second half are too cautious to find the non-obvious wins. You need both: generous at the door, ruthless at the gate.
The organisations getting real value from AI are not the ones that built the most, or the ones with the best models, which everyone rents from the same providers anyway. They are the ones that got good at choosing: that treated deciding what to build as the actual hard problem, pointed their cheap, abundant building capacity only at the things worth building, and had the discipline to stop the rest. Building was never the constraint. Choosing is, and choosing well is the skill the whole AI era quietly rewards.
I write a field-note series on shipping AI that actually works in production. The original of this piece, and the rest, live on my LinkedIn. Originally published on LinkedIn.
Top comments (0)