I’ve seen a lot of AI projects crash and burn. A lot.
After two exits and over 200 angel investments in companies like Anthropic, OpenAI, and Scale AI, you get a front-row seat to the carnage. You see brilliant teams with more PhDs than you can count, armed with the latest models and a mountain of funding, build things that go absolutely nowhere.
For years, I had my own theories about why. Gut feelings, mostly. But I wanted data. So, my team and I did something a little crazy. We spent the last six months digging into the data of over 500 AI teams—some from my own portfolio, some from friends, and some public companies. We looked at everything: team composition, tech stack, funding, data quality, you name it.
We were looking for the golden ticket. The one thing that predicted success.
And we found it. But it wasn't what we expected.
It’s not the number of research papers your team has published. It’s not whether you’re using GPT-4 or a custom-trained Llama model. It’s not even the amount of capital you’ve raised.
The single most important factor that separates successful AI teams from the ones that end up in the startup graveyard is shipping velocity.
That’s it. How fast can you get a real, working product into the hands of real users?
The Obsession with the Perfect Model
I get it. The tech is exciting. When a new model drops, it feels like the whole world shifts. The temptation to re-architect everything around the new hotness is immense. I’ve seen teams spend a year or more in a cave, trying to build the “perfect” AI, the one that will solve everything.
I remember one of my early investments, a company I won’t name. They had a team of absolute rockstars from top AI labs. They raised a $20 million seed round to build a new kind of AI-powered code generation tool. For 18 months, all I heard were excuses. “We’re still fine-tuning the model.” “We’re building a new evaluation framework.” “The new architecture is almost ready.”
They never shipped a single thing. The company folded, and those brilliant engineers went on to get great jobs at Google or Meta. A total waste.
Contrast that with another company I backed, a small team of three working out of a garage in Palo Alto. They were building an AI-powered sales assistant. Their first version was… not great. It was buggy. The UI was ugly. The AI made mistakes all the time. But they shipped it. They got it into the hands of five paying customers within three months of starting.
They listened to the feedback. They iterated. They shipped a new version every single week. Every. Single. Week. Within a year, they had a product that was genuinely useful. They had real revenue. Two years later, they were acquired for a very nice sum.
What was the difference? The first team was obsessed with the technology. The second team was obsessed with the customer.
Why Speed is the Only Thing That Matters in AI
In traditional software, you can map out the problem space. You can write a spec. You can be reasonably sure that if you build X, it will do Y. Not so in AI.
Building with AI is not like building a bridge. It’s like exploring a new continent. You have a general direction, but you have no idea what you’ll find. The only way to find out is to take a step, see what happens, and then take another step.
This is why shipping velocity is so critical. Every time you ship, you get a piece of feedback from the real world. That feedback is gold. It tells you if you’re on the right track. It tells you what your customers actually want, not what you think they want.
AI products are not built, they are grown. You plant a seed (your MVP), and then you water it with user feedback. The faster your iteration cycle, the faster your product grows.
How to Build a High-Velocity AI Team
So, how do you actually do this? It’s not about cracking a whip. It’s about creating a culture and a system that prioritizes speed.
1. Hire for a Bias for Action
When I’m interviewing engineers or product managers, I don’t just look for credentials. I look for people who have a history of getting things done. I ask them to tell me about a time they built and shipped something fast. I want to see a sense of urgency.
A team of B-level engineers who can ship every week will run circles around a team of A-level engineers who are stuck in analysis paralysis.
2. The “One-Week Sprint”
Forget two-week sprints. In AI, that’s an eternity. Your goal should be to ship something meaningful every single week. It doesn’t have to be a major new feature. It could be a small improvement, a bug fix, or a new experiment.
The point is to keep the momentum going. To keep the feedback loop turning. This weekly cadence forces you to break down big problems into small, manageable chunks. It forces you to focus on what’s most important.
3. Don’t Let Perfect be the Enemy of Shipped
Your first version will be embarrassing. That’s a good thing. If you’re not embarrassed by your V1, you’ve launched too late. The goal of the first version is not to be perfect. The goal is to learn.
At RemoteTeam, my last company that was acquired by Gusto, our first MVP was a mess of spreadsheets and Zapier automations held together with duct tape. But it worked. It solved a real problem for our first few customers. And it gave us the feedback we needed to build a real product.
4. Instrument Everything
You can’t improve what you can’t measure. You need to have a clear understanding of how your users are interacting with your product. What are they clicking on? Where are they getting stuck? Is the AI actually helping them?
Set up your analytics from day one. Track everything. This data will be your guide. It will tell you where to focus your efforts.
The Counter-Intuitive Truth
This focus on speed might seem counter-intuitive. Isn’t AI supposed to be about deep, complex research? Yes and no.
The foundational models are built on deep research. But the applications of those models are built on rapid iteration. The value is not in the model itself, but in how you apply it to a specific problem.
And the only way to figure that out is to ship.
So, the next time you’re starting a new AI project, don’t ask yourself “What’s the best model?” or “How can we build the most sophisticated architecture?”
Ask yourself this: “What’s the fastest path to getting a real product in front of a real user?”
That’s the only question that matters.
Frequently Asked Questions
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.
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.
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.
How has this view evolved over time?
My thinking on most topics has changed significantly over the years. Early in my career, I held many conventional views that experience proved wrong. I try to update my beliefs when the evidence changes.