Why AI features get scrapped, and the three fixes I use before writing code

In March 2025, S&P Global reported that 42% of companies had abandoned most of their AI initiatives, up from 17% a year earlier. On average, 46% of proofs of concept were scrapped before reaching production. These are not small startups testing a chatbot. They are companies with budgets, data teams and board-level pressure to "do AI".

The usual explanation is that the models are not good enough yet. That is almost never what I see. When RAND interviewed data scientists about why AI projects fail, the first root cause on their list was that the problem to be solved was misunderstood or miscommunicated. The model worked. It was pointed at the wrong job.

The pattern behind most scrapped features

A founder sees a competitor add an AI assistant. A customer asks for "something with AI". An investor mentions it. A feature gets built that does several things moderately well for nobody in particular. Usage is low, the output is sometimes wrong, and three months later it is quietly removed from the roadmap.

The research backs this up from several angles. MIT's 2025 study of generative AI in business found that around 95% of the organisations it looked at saw no measurable return, and that tools failed mostly because they did not fit how people actually worked. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing unclear value and weak risk controls. Different studies, same shape: the feature was not attached to a job.

Fix 1: one user, one job, written down

Before I design or build an AI feature, I write one sentence: who the user is, what they are trying to get done, and what the feature does for them. "A sales rep, after a call, gets the three follow-up actions without re-listening to the recording." If I cannot write that sentence, I do not build the feature yet. If the sentence has two users or three jobs, I split it.

This is not a formality. The sentence becomes the acceptance test. When the feature is built, I ask the user to do the job with it, and either they can or they cannot. It also decides what the model needs to be good at, which is usually a much narrower skill than "general assistant".

Fix 2: design for the wrong answer first

Every AI feature will sometimes be wrong. The products that survive are the ones that planned for it. In the Stack Overflow 2025 developer survey, 84% of developers used AI tools, but 46% distrusted the accuracy and 66% said their biggest frustration was answers that are almost right. Almost right is more dangerous than clearly wrong, because people act on it.

• Show the source. If the answer came from a document or a call, link to the exact passage. Users check, and checking builds trust.
• Offer a fallback. When confidence is low, the feature should say so and hand over to the normal path, not guess.
• Keep a human check where the cost of a wrong answer is high. Drafts are reviewed; actions are confirmed.
• Make correction cheap. One click to fix or dismiss, and the fix is remembered.

Fix 3: ship small and measure one thing

The first version of an AI feature should be the smallest thing that does the one job. One input, one output, one place in the product. Then measure one number that tells you whether the job got done: how many users completed it, how often the output was accepted without edits, or how much time it saved. Not "engagement". One number tied to the sentence from Fix 1.

McKinsey's 2025 State of AI survey found that the organisations seeing real financial impact were about three times as likely to have redesigned the workflow around the AI rather than bolting it on, and far more likely to have a human validation step. Both are easier to do when the feature is small.

What this looks like in practice

At Ringover I work on AI features inside a call-intelligence product: an assistant, a coaching tool, an AI dialer. Each one started as a single job for a single role, shipped small, and grew only once the first number moved. The features that stuck were the ones where the user could see why the AI said what it said and could fix it in one click when it was wrong.

The same discipline applies whether you are a two-person startup or a team inside a larger company. The model is rarely the constraint. The sentence is.