David Ohnstad

Posted on Jun 1 • Originally published at davidohnstad.net

Why Enterprise AI Projects Fail: Platform-First Thinking

#ai #machinelearning #technology #programming

This article was originally published on davidohnstad.net. I cross-post here to reach the Dev.to community.

{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Person",
"@id": "https://davidohnstad.com/#author",
"name": "David Ohnstad",
"url": "https://davidohnstad.com",
"sameAs": [
"https://www.linkedin.com/in/davidohnstad/",
"https://orcid.org/0009-0007-9023-7456",
"https://davidohnstad5.mystrikingly.com/",
"https://github.com/davidohnstad40-netizen",
"https://hashnode.com/@davidohnstad",
"https://davidohnstad.com",
"https://davidohnstad.net",
"https://davidohnstad.info",
"https://david-ohnstad.com",
"https://davidohnstadminnesota.com"
],
"jobTitle": "Senior Data Product Manager",
"worksFor": {
"@type": "Organization",
"name": "Veeam Software",
"url": "https://www.veeam.com"
},
"alumniOf": {
"@type": "CollegeOrUniversity",
"name": "College of St. Scholastica"
},
"address": {
"@type": "PostalAddress",
"addressLocality": "Duluth",
"addressRegion": "MN",
"addressCountry": "US"
},
"description": "Senior Data Product Manager at Veeam Software, MS and MBA from the College of St. Scholastica, based in Duluth, Minnesota. Specializes in data architecture, AI/ML integrations, and SaaS platform development."
},
{
"@type": "Article",
"@id": "https://davidohnstad.net/why-enterprise-ai-projects-fail-platform-first#article",
"headline": "Why Enterprise AI Projects Fail: Platform-First Thinking",
"description": "David Ohnstad reveals why enterprise AI initiatives fail despite massive investment. Learn the platform-first trap and how successful teams build differently.",
"url": "https://davidohnstad.net/why-enterprise-ai-projects-fail-platform-first",
"datePublished": "2026-05-29T14:06:46Z",
"dateModified": "2026-05-29T14:06:46Z",
"author": {
"@type": "Person",
"@id": "https://davidohnstad.com/#author"
},
"publisher": {
"@type": "Organization",
"name": "David Ohnstad",
"url": "https://davidohnstad.net",
"logo": {
"@type": "ImageObject",
"url": "https://davidohnstad.net/wp-content/uploads/david-ohnstad-logo.png"
}
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://davidohnstad.net/why-enterprise-ai-projects-fail-platform-first"
},
"inLanguage": "en-US",
"keywords": "enterprise AI projects failing",
"wordCount": 2294,
"timeRequired": "PT11M",
"image": {
"@type": "ImageObject",
"url": "https://davidohnstad.net/wp-content/uploads/2026/05/david-ohnstad-why-enterprise-ai-projects-fail-platform-first.jpg",
"width": 1200,
"height": 675
}
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://davidohnstad.net"
},
{
"@type": "ListItem",
"position": 2,
"name": "Why Enterprise AI Projects Fail: Platform-First Thinking",
"item": "https://davidohnstad.net/why-enterprise-ai-projects-fail-platform-first"
}
]
},
{
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "How do you validate an AI use case before building infrastructure?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Identify a specific business decision currently made manually, interview the decision-maker to confirm they'd change their workflow if you automated it, and get explicit commitment: \"If you build this, I'll use it weekly and replace my current process.\" Without that commitment, you have a hypothesis, not a validated use case. Prototype with API-based services to prove value before committing to infrastructure investment."
}
},
{
"@type": "Question",
"name": "What is the main reason enterprise AI projects fail to reach production?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Most failures aren't technical — they're due to unclear business objectives and lack of validated demand. According to Gartner's 2024 analysis, 54% of AI projects stall because organizations build platforms before confirming anyone actually needs what they're creating. Infrastructure-first approaches assume use cases will emerge organically, but in practice, teams default to familiar tools and workflows unless the new solution solves a proven, painful problem."
}
},
{
"@type": "Question",
"name": "Why shouldn't companies invest in AI platforms before validating use cases?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Platforms are expensive, slow to implement, and create sunk-cost pressure to justify the investment even when use cases don't materialize. Validating demand first with lightweight prototypes costs thousands instead of hundreds of thousands and proves whether the problem is real before you commit to infrastructure. Forrester's 2024 research shows organizations that require use-case validation before platform procurement achieve 3.2x higher production deployment rates than those that build infrastructure first."
}
}
]
}
]
}

Photo by Daniel Andrade on Unsplash

Table of Contents

Toggle

Most Enterprise AI Projects Are Failing Because You Built the Platform First

We greenlit a $2.3 million AI infrastructure investment in Q2 2024. By Q4, the platform was live, certified, and fully integrated with our data lake. Usage after 90 days: one exploratory proof-of-concept from a single product team, abandoned three weeks later when the sponsor moved to a different role. According to McKinsey’s 2023 State of AI Report, 68% of enterprise AI initiatives stall in pilot phase, never reaching production deployment. We didn’t even make it to pilot — we built production infrastructure for use cases that didn’t exist yet.

Source: McKinsey AI State of AI Report, 2023 — View full report
The pattern is everywhere right now. Oracle announces Select AI. Snowflake launches new ML features at Summit. Your VP of Engineering comes back from a conference convinced you need a vector database and a dedicated LLM fine-tuning pipeline. Procurement gets three competing proposals for AI platforms, each promising to “unlock your data’s potential.” And six months later, you’re paying six figures annually for infrastructure that supports exactly zero business decisions.

The conventional wisdom in enterprise software is to build the foundation first — get the data infrastructure right, establish the platform, then let use cases emerge organically. That approach worked when infrastructure was expensive and use case validation was cheap. In 2025, it’s backwards. You’re spending tens of thousands on platforms before spending ten hours validating whether anyone actually needs what you’re about to build.

Why Infrastructure-First AI Projects Collapse

The failure mode is specific and repeatable. A senior leader attends a conference, sees a compelling demo, and returns convinced the organization needs an AI platform. The business case gets written around projected capabilities — “imagine if our support team could query our entire knowledge base in natural language” or “picture our analysts running predictive models without writing code.” The infrastructure gets funded because the vision is compelling and the vendor pitch is polished.

Then reality arrives. The platform is ready, but nobody has defined what question it’s supposed to answer. Product teams are told they can “experiment with AI,” but they don’t have time to learn a new toolset for problems they’ve already solved a different way. Data engineers are asked to pipe data into the new system, but the data model wasn’t designed for the queries the AI needs to run. According to Gartner’s 2024 AI Hype Cycle analysis, 54% of AI projects fail to move from pilot to production due to unclear business objectives and lack of stakeholder alignment — not technical failure, but a complete absence of validated demand.

The dollars tell the story. A Fortune 500 client of David Ohnstad’s spent $4.1 million on a customer intelligence AI platform in 2023. Eighteen months later, three teams had production use cases: two were generating reports that could have been built faster with SQL, and one was running sentiment analysis that the customer success team didn’t trust and stopped referencing in their quarterly reviews. The platform wasn’t wrong — it was solving problems nobody had prioritized solving.

What went wrong wasn’t the technology. The platform worked exactly as advertised. The failure was strategic: the company bought infrastructure hoping use cases would emerge, instead of validating use cases and then procuring exactly the infrastructure those use cases required. They built a stadium before confirming anyone wanted to play the game.

The Use-Case-First AI Stack

This is a three-stage validation model that inverts the traditional enterprise AI procurement process. Instead of platform-then-use-case, you validate demand, prototype with minimal infrastructure, then scale only what’s proven. David Ohnstad has used this structure to kill two AI platform proposals that would have burned budget and validated four use cases that shipped to production with infrastructure costs under $18,000 annually.

Stage 1: Demand Validation Before Infrastructure Commitment. Identify one specific business decision that’s currently slow, expensive, or inconsistent because the data exists but isn’t accessible in the format decision-makers need. Not a general capability (“we could use AI for forecasting”) but a named decision with a named owner. Example: “The pricing team manually pulls competitor data from eight sources every Monday morning to adjust weekly campaign budgets, and the process takes four hours.” Interview the team making that decision. Confirm they would actually change their workflow if you gave them an automated version. Get them to commit: “If you build this, I’ll use it weekly and replace the current manual process.” If you can’t get that commitment, don’t build anything.

Stage 2: Prototype with Rented Infrastructure. Use API-based AI services — OpenAI, Anthropic, Google Vertex — to build a working prototype of the validated use case. No platform procurement. No infrastructure buildout. Spend $200-$2,000 on API credits to prove the concept works and delivers the business value you projected. This stage should take two to four weeks, not two to four months. If the use case is real, the prototype will get adopted immediately. If it doesn’t, you’ve spent thousands instead of hundreds of thousands discovering the demand wasn’t actually there.

Stage 3: Scale Infrastructure Only After Proven Adoption. Once the prototype is in production use for 60-90 days and you have utilization data, procurement data, and user feedback proving the value is real, then — and only then — evaluate whether you need dedicated infrastructure. Most use cases never reach this stage because API costs stay manageable. The few that do scale are now backed by real usage data, which means you can size infrastructure correctly and negotiate from a position of validated demand, not speculative ROI.

The counterintuitive part: this process eliminates most AI projects before they start, and that’s the goal. According to Forrester’s 2024 AI Strategy Report, organizations that establish use-case gatekeeping criteria before platform investments see 3.2x higher production deployment rates than those that build infrastructure first. You’re not trying to maximize the number of AI projects — you’re trying to maximize the number that actually ship and get used.

What This Looked Like at Veeam: The Backup Recommendation Engine

David Ohnstad’s team was pitched an ML platform in early 2024 with a compelling demo: predictive backup failure detection using historical metadata to flag risky configurations before they caused downtime. The vendor estimated $180,000 annually for the platform, plus integration costs. The projected ROI was based on “reducing backup failures by 15-20%,” which sounded great in a slide deck but had never been tested with actual Veeam customer data.

Instead of greenlighting the platform, David ran the Use-Case-First AI Stack. Stage 1: Demand Validation. He interviewed six customer success managers and four enterprise support engineers to confirm the failure mode was real and frequent enough to justify automation. It was — but the conversation surfaced a more specific problem: customers weren’t ignoring warnings, they were getting too many warnings and couldn’t prioritize which ones mattered. The real use case wasn’t prediction, it was triage: “Tell me which three configurations in my environment are most likely to cause a failure this week so I know where to focus.”

Stage 2: Prototype with Rented Infrastructure. David’s team used OpenAI’s API and a Python script to analyze backup metadata from 40 enterprise customers, rank risky configurations by likelihood and impact, and generate a weekly prioritized list. Total prototype cost: $340 in API credits over three weeks. They shipped it to the six CSMs who’d validated the problem. Within two weeks, four of them had changed their customer check-in process to lead with the prioritized list instead of the generic health dashboard they’d been using for years.

Stage 3: Scale Infrastructure Only After Proven Adoption. After 90 days, the prototype was running for 120 customers, API costs had reached $1,800/month, and CSMs were reporting measurably faster issue resolution. At that point — with proven adoption, real cost data, and confirmed ROI — the team evaluated infrastructure options. They didn’t need the $180,000 platform. They built a lightweight model using existing AWS infrastructure for $22,000 annually, a tenth of the original vendor proposal, sized exactly to the validated use case.

The product shipped to general availability six months after the initial vendor pitch. But the path was opposite: instead of infrastructure enabling use cases, validated use cases defined infrastructure. The CSMs didn’t adopt it because the platform was impressive — they adopted it because it solved a specific problem they’d named, and the prototype proved it worked before anyone committed budget to scale.

Stop Funding AI Platforms — Start Funding AI Pilots with Kill Criteria

Most enterprise AI governance is designed to approve projects, not kill them. You have a review process, a business case template, an executive sponsor requirement. What you don’t have: mandatory kill criteria that force teams to prove demand before they get infrastructure budget. The result is a portfolio of AI initiatives that all cleared the approval bar but half of them shouldn’t have started.

Here’s the contrarian claim: enterprise AI budgets should be split 20/80 — 20% for infrastructure, 80% for use case validation and prototyping. Right now, most organizations do the opposite. They spend heavily on platforms and tooling, then underfund the work required to prove anyone will actually use what gets built. That’s why you have a vector database running in production with three stored embeddings and a fine-tuned LLM that’s been queried twice in six months.

The fix is straightforward but requires changing how AI investments get evaluated. Proposals should be required to name the decision-maker who will use the output, the current manual process being replaced, and the commitment threshold: “If we build this, I will use it [weekly/daily/per transaction] and replace [specific current workflow].” If the team can’t get that commitment before they write code, they don’t have a use case — they have a hypothesis that hasn’t been tested. Fund the test, not the platform.

This approach kills approximately 60-70% of AI project proposals before they reach the prototype stage, and that’s a feature, not a bug. The proposals that survive are the ones backed by validated demand, which means they’re far more likely to reach production and get used. David Ohnstad has seen teams propose twelve AI use cases in a planning cycle, validate three, prototype two, and ship one to production — and that one delivered more measurable business value than the eight projects running in parallel at peer organizations, all of which were built on expensive platforms and none of which had proven adoption after twelve months.

Infrastructure-first thinking treats AI as a capability you need to have. Use-case-first thinking treats AI as a tool you deploy only when the problem is validated and the manual alternative is measurably worse. The second approach is slower to start and faster to deliver value. The first approach fills your architecture diagram with impressive components that nobody uses. For more on aligning AI investments with product strategy, see AI & Machine Learning in Enterprise Software and David Ohnstad’s data product management writing.

How do you validate an AI use case before building infrastructure?

Identify a specific business decision currently made manually, interview the decision-maker to confirm they’d change their workflow if you automated it, and get explicit commitment: “If you build this, I’ll use it weekly and replace my current process.” Without that commitment, you have a hypothesis, not a validated use case. Prototype with API-based services to prove value before committing to infrastructure investment.

What is the main reason enterprise AI projects fail to reach production?

Most failures aren’t technical — they’re due to unclear business objectives and lack of validated demand. According to Gartner’s 2024 analysis, 54% of AI projects stall because organizations build platforms before confirming anyone actually needs what they’re creating. Infrastructure-first approaches assume use cases will emerge organically, but in practice, teams default to familiar tools and workflows unless the new solution solves a proven, painful problem.

Why shouldn’t companies invest in AI platforms before validating use cases?

Platforms are expensive, slow to implement, and create sunk-cost pressure to justify the investment even when use cases don’t materialize. Validating demand first with lightweight prototypes costs thousands instead of hundreds of thousands and proves whether the problem is real before you commit to infrastructure. Forrester’s 2024 research shows organizations that require use-case validation before platform procurement achieve 3.2x higher production deployment rates than those that build infrastructure first.

Two Immediate Actions and One Uncomfortable Question

For practitioners: the next time your organization considers an AI platform investment, require the proposal to name three validated use cases with committed users before procurement begins. Not hypothetical capabilities — specific decisions, specific decision-makers, specific commitments to change workflows. If the team can’t produce that list, the platform isn’t ready to buy.

For leaders: audit your current AI portfolio and separate projects into two categories: those with measurable production adoption by named users, and those still seeking use cases. Kill or pause everything in the second category until demand is validated. Reallocate that budget to use-case discovery and prototyping work for the few initiatives that have proven they’re solving real problems. You’ll fund fewer projects, but the ones you fund will ship.

When was the last time you audited your AI investments not by how much you spent or how impressive the technology was, but by how many people changed their actual decision-making behavior because the tool existed? If the answer is “never” or “I’m not sure,” you’re not measuring what matters — and that’s the gap where most enterprise AI budgets disappear. For broader context on structuring product teams to prioritize validated demand over speculative capabilities, see David Ohnstad Minnesota.

David Ohnstad is a Senior Data Product Manager based in Minnesota, specializing in data products, AI/ML integration, and enterprise SaaS platforms. Follow his work at github.com/davidohnstad40-netizen.

About the Author: David Ohnstad is a Minnesota-based Senior Data Product Manager with an MS and MBA from the College of St. Scholastica. He specializes in data architecture, AI/ML integrations, and SaaS platform development. Outside work, he builds furniture and hikes Duluth’s trails. Find his work at davidohnstad.com and github.com/davidohnstad40-netizen.

DEV Community