We sold our last company, RemoteTeam, to Gusto. Before that, I sold MovieLaLa to Gfycat. People hear “successful exit” and they see the highlight reel. They don’t see the years of grinding, the near-misses, the projects that went nowhere. They definitely don’t see the internal AI projects that burned through cash and delivered nothing but a fancy slide deck.
I’ve been building companies and investing in them for over a decade. I’m an angel in over 200 companies, including some you might have heard of like Anthropic, OpenAI, and Scale AI. I’ve seen this movie more times than I can count, both as the protagonist and as the guy in the audience yelling at the screen.
The movie is called “Our First Enterprise AI Project,” and it’s usually a tragedy.
Everyone is rushing to bolt AI onto their business. The FOMO is real. Your board is asking for an AI strategy. Your competitors are issuing press releases. The pressure is immense. So you hire a team of data scientists, give them a mountain of data, and tell them to find some “insights.”
Six months and half a million dollars later, what do you have? A model that’s 85% accurate on a test set and a PowerPoint explaining how it could theoretically improve efficiency. But it’s not in production. It’s not touching a real customer. It’s not making you any money. It’s shelf-ware.
I’ve made these mistakes myself. I’ve also seen dozens of my portfolio companies make them. The good news is that the mistakes are almost always the same. They’re predictable. And if they’re predictable, they’re avoidable.
Forget the generic advice. I’m going to give you the real, unfiltered list of the 5 mistakes that will absolutely kill your first enterprise AI project. Avoid these, and you’re already ahead of 90% of the companies out there.
Mistake 1: Starting with the AI, Not the Problem
This is the original sin of enterprise AI. It’s so seductive. You have all this amazing new technology—large language models, diffusion models, reinforcement learning. It feels like you have a hammer, so everything looks like a nail. The team gets excited about using the latest and greatest tech, and they go hunting for a problem to solve with it.
This is completely backward.
I remember a project early on at one of my companies. We had a brilliant engineer who was obsessed with a new clustering algorithm. He spent two months applying it to our customer support tickets. He came back with this incredibly complex visualization of ticket categories. It was beautiful. It was also completely useless.
He’d created a solution, but he’d never stopped to ask what the problem was. What was the business goal? Were we trying to reduce response times? Improve customer satisfaction? Automate ticket routing? He didn’t know. He just wanted to use his cool algorithm. We’d wasted two months of his time and a ton of compute resources.
How to avoid it:
Fall in love with the problem, not the solution. Before you write a single line of code, you should be able to answer these questions with absolute clarity:
- What specific business metric are we trying to move? Not “improve efficiency.” I mean a real, measurable KPI. “Reduce the average handle time for support tickets by 30%.” “Increase the conversion rate on our product recommendations by 5%.” Be specific. Be numeric.
- What is the dollar value of moving that metric? If you can’t put a number on it, don’t do it. How much money will you make or save if this project is successful? This is the ROI conversation you need to have upfront, not after the fact.
- How are you solving this problem today? What is the manual process or the existing system you’re trying to beat? You need a baseline. If you don’t know where you are, you can’t measure progress.
Only after you have the answers to these questions should you even start thinking about what technology to use. The simplest solution is almost always the best. Sometimes, the answer isn’t a complex deep learning model. It’s a simple heuristic, a better UI, or just a well-written SQL query.
Mistake 2: The “Big Bang” Launch
The engineering team goes into a cave for nine months. They’re building the perfect, all-encompassing AI system. It’s going to automate everything. It will have every feature imaginable. They’re boiling the ocean. They emerge, blinking in the sunlight, with a monolithic system that is incredibly complex, impossible to debug, and based on a thousand assumptions they made nine months ago, half of which are now wrong.
It’s the “Big Bang” launch. And it almost always ends in a crater.
I’ve seen this happen with a sales forecasting AI. The team spent a year building a model that took in every possible signal—economic data, competitor actions, website traffic, the phase of the moon. It was a masterpiece of engineering. When they finally turned it on, the forecasts were… worse than the simple spreadsheet the sales ops team had been using for years. The model was too complex. It was overfitting to historical data and couldn’t adapt to a changing market. The project was a total write-off.
How to avoid it:
Think like a scientist, not a builder. Your first goal is not to build a system; it’s to validate a hypothesis. The hypothesis is: “I believe that by using [AI technique] on [this data], I can improve [this metric].”
Your job is to test that hypothesis as quickly and cheaply as possible.
- Start with a human-in-the-loop. Don’t try to build a fully autonomous system from day one. Build a tool that assists a human. For the sales forecasting example, instead of replacing the sales ops team, you could have built a tool that gave them a suggested forecast. They could then use their domain expertise to accept, reject, or adjust it. This gets you into production faster, provides immediate value, and—most importantly—generates the training data you need to eventually automate the process.
- Time-box your experiments. Give the team a fixed amount of time, say four weeks, to deliver a working prototype that moves the needle on the target metric. Not a perfect system. A prototype. This forces them to focus on the most important features and cut scope aggressively.
- Deploy to a small slice of the business first. Don’t roll out your new AI to the entire company at once. Test it with a single user, a single team, or a single customer segment. See if it actually works in the real world. Get feedback. Iterate. The goal is to learn as fast as possible.
Mistake 3: Ignoring the Data Plumbing
Data scientists love to talk about models. They love to talk about algorithms. They hate to talk about data pipelines, feature engineering, and data quality.
This is like a chef who loves to talk about plating but doesn’t care about the quality of the ingredients. It’s a recipe for disaster.
Garbage in, garbage out. It’s a cliche because it’s true. Your model is only as good as the data you feed it. I’ve seen projects get delayed by months, even years, because the team underestimated the work required to get the data into a usable state.
At one of my portfolio companies, they were trying to build a customer churn prediction model. The data scientists spent six months building a super-sophisticated model. When they tried to run it on real data, the performance was terrible. Why? The data was a mess. Customer IDs were inconsistent across different systems. Timestamps were in different formats. Half the data they needed was missing.
They’d spent all their time on the fancy modeling and no time on the plumbing. They had to go back to square one.
How to avoid it:
Assume your data is a mess. It is. Budget at least 50% of your project time for data-related tasks. This is not an exaggeration. Sometimes it’s 80%.
- Build a dedicated data engineering team or function. This can’t be a part-time job for your data scientists. You need people who specialize in building robust, scalable, and reliable data pipelines. These are the unsung heroes of AI.
- Create a “feature store.” A feature store is a central repository for the data that your models use. Instead of every data scientist calculating the same features over and over again (e.g., “customer lifetime value”), you calculate them once and store them in a place where everyone can access them. This saves time, ensures consistency, and makes it much easier to deploy models to production.
- Invest in data quality monitoring. Your data is not static. It changes. Upstream systems break. New categories get added. You need to have automated checks in place to alert you when the statistical properties of your data change. This is called data drift, and if you’re not monitoring for it, your models will silently degrade over time.
Mistake 4: The Siloed “AI Lab”
This was a popular model a few years ago. The CEO would read an article about AI, get excited, and decide to create an “AI Lab” or “Center of Excellence.” They’d hire a bunch of PhDs, put them in a separate office with beanbag chairs, and tell them to go “innovate.”
The business teams would throw problems over the wall to the AI lab. The lab would work in isolation and, months later, throw a “solution” back over the wall. The business team would look at it and say, “This isn’t what we need. It doesn’t integrate with our workflow. It doesn’t solve the real problem.”
The AI lab becomes an island of misfit toys. They’re working on interesting technical problems, but they’re disconnected from the reality of the business. Their projects never get adopted. The team gets frustrated and leaves. The lab gets shut down. I’ve seen this exact pattern play out at Fortune 500 companies.
How to avoid it:
Embed your AI talent directly into your business units. Your data scientists should be sitting with the product managers, the engineers, the marketers, the sales team. They should be part of the team that owns the business metric.
- Create cross-functional “squads.” A typical squad might have a product manager, a few engineers, a data scientist, and a designer. They are all focused on a single KPI. The data scientist isn’t a support function; they are a core part of the team responsible for hitting the goal.
- Rotate your talent. Don’t let your data scientists get stuck working on the same problem for years. Rotate them through different parts of the business. This gives them a broader perspective and helps spread AI knowledge throughout the organization.
- Product managers are the glue. Your product managers need to be data-literate. They need to understand the basics of machine learning. They are the ones who translate business needs into technical requirements. They are the ones who ensure that the team is building the right thing. A good PM who understands both the business and the tech is worth their weight in gold.
Mistake 5: Chasing the Last 1% of Accuracy
Your model is 95% accurate. The team says that if they just had another three months and a few more GPUs, they could get it to 96%. Don’t let them do it.
This is a trap. It’s the law of diminishing returns. That last 1% of accuracy could cost you as much as the first 95%. And in most business applications, it doesn’t matter. 95% is good enough. Perfect is the enemy of done.
I saw a team spend an entire quarter trying to improve a recommendation model from 98.0% to 98.5% accuracy. They finally did it. The impact on the business? Zero. The cost? Hundreds of thousands of dollars in salary and compute time that could have been spent on a new project.
How to avoid it:
Define “good enough” upfront. Before the project starts, agree with the business stakeholders on the minimum level of performance that is required for the system to be useful. Once you hit that level, ship it.
- Focus on the user experience of failure. No model is perfect. It will make mistakes. Instead of trying to eliminate all mistakes, focus on what happens when the model is wrong. How do you handle it? Is there a way for the user to correct the mistake? Is there a fallback to a human? A well-designed system with a 90% accurate model can be much more valuable than a poorly-designed system with a 99% accurate model.
- Measure the right thing. Accuracy is often a vanity metric. What you really care about is the impact on the business. Are you saving money? Are you making customers happier? Are you closing more deals? Sometimes, a less “accurate” model can actually have a bigger business impact if it’s faster, cheaper, or easier to understand.
- Create a culture of shipping. Reward teams for getting things into production, not for publishing papers or winning Kaggle competitions. The goal is to deliver value to the business, not to advance the state of the art. There’s a place for research, but your first enterprise AI project is not it.
It’s a Marathon, Not a Sprint
Building a successful AI capability within your company doesn’t happen overnight. It’s not about one heroic project. It’s about building a culture of experimentation, a robust data infrastructure, and a deep partnership between your technical and business teams.
Don’t be afraid to start small. Don’t be afraid to fail. The key is to learn from your mistakes and get better with each iteration. The five mistakes I’ve outlined here are the most common and the most deadly. Avoid them, and you’ll be well on your way.
Now go build something.
Frequently Asked Questions
Do all experts agree with this view?
No, and that's fine. The best ideas in business are often contrarian. I share my perspective based on my experience and data, but I encourage you to seek out opposing viewpoints and form your own conclusions.
How can I apply this thinking to my own situation?
Start by identifying the core principle behind the opinion, not the specific example. Then ask yourself: does this principle apply to my context? If yes, test it in a small, low-risk way before going all in.
What's the most common pushback you get on this?
People often push back by citing exceptions or edge cases. And they're usually right that exceptions exist. But building a strategy around exceptions rather than patterns is a losing game for most founders.
What experience informs this perspective?
This perspective comes from over a decade of building companies in Silicon Valley, two successful exits (RemoteTeam to Gusto, MovieLaLa to Gfycat), and investing in 200+ startups including Anthropic, OpenAI, and Scale AI. I write about what I've lived.