Most AI projects fail. The data on this is now reasonably clear, and the failure rate isn’t dropping as the tools improve. The conventional read of the failure data is that companies need better engineers, more data scientists, sharper ML expertise. I think the conventional read is wrong.
The pattern I see across the projects that fail is not technical inadequacy. It’s something simpler and more inconvenient: nobody in the room was asking whether the right problem was being solved.
That role: the one that asks whether the right problem is being solved, before the team commits months of effort to solving it, is the product manager. AI projects are starving for it. The consulting market should be paying attention.
How AI projects actually fail
Strip away the press releases and the postmortems. The recurring failure modes look like this:
The “we trained a model on it” project. Someone notices a data set the company has. Someone with ML chops trains a model on the data. The model gets reasonable accuracy on the held-out set. Then six months pass and nothing has shipped, because no one ever asked who would use the model’s output, in what workflow, at what point in the day, and what decision the output would change. Accuracy on held-out data turns out to be a poor proxy for “useful in someone’s actual job.”
The “AI feature for the sake of AI” project. Product wants an AI feature because the CEO/board wants an AI feature. Engineering builds something. Marketing announces it. Customers don’t use it because it doesn’t solve a problem they actually have, and the team has no instrumentation to detect the silence.
The “automation that automates the wrong thing” project. Operations identifies a manual process and replaces it with AI. Six months later, the team that owns the process can’t explain why throughput is lower, error rates are up, and customers are complaining. The AI is automating the wrong unit of work, the part that was easy to automate, not the part that was constraining throughput.
The “data scientist’s pet project” project. A talented data scientist proposes something interesting. The interesting thing gets built. It works, in a strict technical sense. It also doesn’t tie to any roadmap commitment, any customer request, or any operational metric anyone tracks, and it withers.
In every one of those failure modes, the gap is product judgment, not engineering capability. A senior product manager in the room, one with the authority to push back, would have caught the gap in week one.
Why the gap exists
The gap exists because AI work tends to get organized around technical capability rather than around customer outcome. When a company decides to do AI, the staffing plan starts with engineers and data scientists, and the product manager, if there is one, gets attached late, often as a project manager rather than a product manager. The PM ends up coordinating sprints, not setting direction.
This is the inverse of how good product organizations work in non-AI domains. In a healthy product org, the PM is upstream of the build. They translate business strategy into product priorities, define what success looks like, set the metric, decide what’s in scope and what isn’t, and act as the buyer of the product on behalf of the customer. The engineers and designers execute against that direction.
In AI work, the order tends to invert. The engineers and data scientists figure out what’s technically interesting, build it, and then someone, usually too late, asks who’s going to use it.
The companies getting AI right are running the healthy version: PM upstream, engineering, and data science downstream of a clearly defined product direction.
What a PM brings to AI specifically
Several things, all of which are absent in their absence.
Problem definition. “Customers complain that onboarding takes too long” is a problem statement. “We should use AI to improve onboarding” is not. The PM forces the first version and refuses the second. AI projects without that discipline burn months building solutions to problems no one has named.
Success metrics that aren’t proxies. Model accuracy is a proxy. Latency is a proxy. The actual metric is something like “percentage of customers who complete onboarding without contacting support” or “time-to-first-useful-output.” The PM is the person who insists on the actual metric, against the gravitational pull of the easier proxies.
Scope discipline. Every AI project I’ve seen has a moment where someone proposes adding a vector database, fine-tuning a model, building a custom evaluation harness, or rebuilding the whole thing in agent-architecture. Sometimes those are right. Often they are not. The PM is the person whose job is to ask “what does this buy us against the metric we agreed on, and is it worth the time?” Without that role, AI projects expand until they collapse.
Workflow integration. A model that produces a correct output but lands in the wrong queue at the wrong time, with no surrounding context, is worthless. AI lives or dies based on workflow design, what triggers it, who reads its output, what they do with that output, what happens when the output is wrong. This is fundamentally product work, not model work.
Evaluation discipline. Continuous review of AI outputs against the success metric. Calibration on edge cases. A red-team practice. A documented rollback procedure for when the model degrades. Most engineers will build the model and call the project done; most data scientists will do the same. The PM is the person who insists on the discipline that makes the model deployable in a context where customers can see it.
Stakeholder bridging. AI projects touch legal, ops, customer support, sales, marketing, finance, and security. Engineering can’t run those conversations. Data science can’t run those conversations. The PM does, every day, in non-AI work, and it transfers directly.
The implications for hiring and consulting
If this read is right, two things follow.
For companies hiring: stop putting AI engineers and data scientists at the front of the org chart for AI initiatives. Put a product manager there. Specifically: a senior product manager with operational scars, who has shipped products that customers used, and who has been around long enough to recognize the failure modes I described above. Then staff the engineers and data scientists under or alongside that PM.
For consultants advising on AI: the work that matters most is not technical advisory. It is product advisory. What problem is being solved, why does it matter, what would success look like, what are the failure modes, who in the customer’s organization will use the output, what will they do with it. The consultants who can run those conversations and produce a defensible plan are doing work that the technical advisors can’t do at all.
This is the consulting market I’m building Local Value into. Not “AI implementation.” AI product strategy and adoption, for businesses that want AI to actually move a metric, not just appear in their press release.
A working principle
Here’s the principle I keep returning to: AI lives or dies based on whether someone in the room is asking what an actual user is going to do with this, on a Tuesday afternoon, in their actual job.
If that question is being asked, by someone with the authority to redirect the work when the answer is unsatisfactory, the project usually ships and produces value.
If it isn’t, the project usually doesn’t.
The role that asks that question is the product manager. AI doesn’t need more engineers. It needs more PMs in the right seats.
Related reading: Why Most SMBs Are Doing AI Wrong covers the same failure modes from the buyer’s perspective.
Rob Lewis is the founder of Local Value LLC and an AI Product Consultant for SMB and mid-market businesses. He has three decades of senior product leadership experience and ships production AI applications. Reach him at [email protected].
