Someone at the Berkeley AI Conference asked Box CTO Ben Haines a rapid-fire question: what percent of enterprise AI pilots are failing right now?
His answer: "Most. By far."
Then he said something that reframed the entire conversation: "Before you read too far into that, I think most projects fail. What's the base rate of success of large projects? Most technology projects fail."
That response is the most useful thing I heard all weekend. Not because it's comforting. Because it's clarifying.
The Base Rate Problem
The AI industry has a narrative problem. When enterprise AI pilots fail, it gets framed as evidence that AI doesn't work, that the technology is overhyped, that companies should wait for it to mature. The headlines write themselves.
But Haines's framing cuts through it. Enterprise technology projects have always had high failure rates. ERP implementations. CRM rollouts. Cloud migrations. Digital transformations. The base rate of failure for large-scale technology initiatives is somewhere between 50% and 70%, depending on whose research you trust. That's been true for decades.
AI projects failing at similar or even higher rates isn't a signal that AI is broken. It's a signal that organizations are organizations. They struggle with change management, unclear success metrics, misaligned stakeholders, and scope creep whether the project involves AI or not.
The question Haines said matters isn't whether the first attempt fails. It's what happens when they try again.
Why the Second Attempt Matters More
I've led product implementations across multiple industries and company sizes. The pattern is remarkably consistent: the first attempt at any significant technology change fails for organizational reasons, not technical ones. The technology works. The people, processes, and incentive structures don't.
The second attempt benefits from something the first attempt never has: a shared understanding of what actually went wrong. Not the post-mortem version that gets presented to leadership. The real version. The one where the team acknowledges that nobody agreed on success metrics, that the data was messier than anyone admitted, that the sponsor lost interest halfway through.
With AI, this second-attempt advantage is even more pronounced because the technology is improving between attempts. If your pilot failed six months ago because the model hallucinated too frequently, the models available today are measurably better. If it failed because the integration was brittle, the tooling has matured. The ground beneath you is literally improving while you regroup.
This is why Haines's framing matters for product leaders. If you're evaluating AI readiness based on first-attempt success rates, you're using the wrong metric. The right metric is second-attempt success rate. And that number is much higher.
The "Buy, Don't Build" Argument
Haines made another point that's worth unpacking. When asked how he advises Box's large enterprise customers to keep up with AI, he was direct: "Don't build it yourself. Buy a company, invest in a vendor and a SaaS platform that will do that for you."
His reasoning is practical. The rate of change in AI is so extreme that most organizations can't keep up internally. Fifteen major frontier models were released in the past twelve months. Each one was arguably the most impressive piece of engineering in the history of civilization. Keeping up with that pace while also running your core business isn't realistic for most companies.
This is a PM decision that comes up in every enterprise AI conversation I've been part of: build or buy? And the calculus has shifted. In previous technology waves, building gave you customization and control. In AI, building gives you a maintenance burden that compounds every time a new model drops. The teams I've seen succeed are the ones that buy the platform layer and focus their internal efforts on the application layer, the part that's specific to their business, their data, their workflows.
The Practical Takeaways
Here's what I'd tell any PM or product leader navigating enterprise AI based on what I heard at Berkeley:
1. Normalize failure in your stakeholder communication. If your AI pilot's success rate is the same as every other enterprise technology project, say that. Frame it as organizational learning, not technology failure. The worst thing you can do is let a failed pilot become evidence that AI doesn't work. It's evidence that your first attempt wasn't right, and now you know what to fix.
2. Design your pilot for learning, not for ROI. The first AI implementation should be optimized for signal, not revenue impact. What did you learn about your data quality? About user adoption? About where the model struggles? These insights are worth more than whatever incremental efficiency the pilot was supposed to deliver.
3. Plan the second attempt before the first one ships. This sounds counterintuitive, but it's the highest-leverage move I've seen. Before you launch pilot v1, document what you expect to learn and what you'd do differently in v2. This turns a "failed pilot" into "phase 1 of a two-phase implementation" and changes the organizational narrative entirely.
4. Invest in education. Multiple speakers at Berkeley flagged this. Intercom had to teach support leaders how consumption pricing works. OpenAI's enterprise team had to learn an entire industry vertical from scratch. Box has to help customers understand what an AI agent even is. The education layer isn't a nice-to-have. It's the difference between adoption and abandonment.
5. Move from pilot to production faster. The Crossing the Chasm model says there's a gap between early adopters and the early majority. Haines suggested that in AI, once things start working, "a lot of people will very quickly cross the chasm." That means the window between "successful pilot" and "company-wide rollout" is shorter than you think. If you're still running pilots when your competitors are in production, you've already lost.
The Real Risk
The biggest risk in enterprise AI isn't that your pilot fails. It's that your pilot fails and you use that as a reason to stop.
Haines was clear: the companies that are pulling ahead aren't the ones with the highest first-attempt success rate. They're the ones that fail, learn, and try again faster than everyone else. That's not an AI strategy. That's just good product management.
Every technology wave has the same shape. Early experiments fail. Organizations learn. The technology improves. And the companies that stayed in the game during the messy middle end up with an insurmountable lead over the ones that waited for certainty.
We're in the messy middle right now. The PMs who treat this moment as an opportunity to build organizational muscle, not as a signal to retreat, are the ones who'll be running AI-native product teams in two years.