The Adoption Wall: Why Most AI Projects Die
The real opportunity in AI is shifting.
It is no longer in building smarter models — that is a race very few can win.
The real opportunity is in solving the last mile: getting AI to actually stick inside a real organization.
In previous editions, I have written about where this is heading:
Regulation becoming part of product design
Inference optimization becoming a core competency
Now there is a third piece:
Integration and adoption.
That last mile is where most AI projects die.
Too often, teams start with the tool, not the problem. They build impressive demos that do not survive contact with the organization: legacy systems, existing processes, and people who have to actually change the way they work.
The moment AI meets a real workflow, progress slows down fast.
The data confirms this.
Goldman Sachs estimates that up to $1 trillion will be invested in AI infrastructure over the coming years. However, MIT research suggests that around 95% of organizations are not seeing meaningful returns.
RAND Corporation identifies the culprits:
Unclear problem definition
Poor data quality
A technology-first approach that skips the hard organizational work
That is a large gap between investment and outcomes.
I would even say it is a wall.
Much of that trillion dollars is still looking for the right problem.
This space is less crowded than it looks. And this is where the most interesting companies are being built right now.
Not pure software plays, but what the industry is calling Services as Software — firms that combine AI with genuine domain expertise and operational depth.
I wrote about this pattern in EU-Startups last year when covering AI roll-ups.
Pioneers, an AI-powered staffing platform in our portfolio, is a good example. They acquired traditional staffing firms, plugged AI into existing customer bases, and grew monthly revenue 5x in a matter of months.
The AI worked.
Getting it inside a real organization was the hard part.
Focus Lessons for Building and Scaling
When Focus Becomes Stubbornness — and How to Tell the Difference
When I talk about focus, one question comes up more than any other:
How do you tell the difference between focus and stubbornness?
Two stories illustrate this.
A founder I knew was building a company. His team, deep in the work, built an internal communication tool on the side.
They came to him and said:
This is so good. Let’s turn it into a product.
He said no:
We’re focused. We don’t deviate.
That tool later became one of the most popular messengers.
The founder had something extraordinary in his hands and passed on it.
The opposite story:
I once approached a US founder whose product I loved and offered to help him localize it for the German-speaking market.
More revenue. New geography. A clear opportunity.
He turned me down without hesitation.
We have a plan. We go state by state. It would be a distraction.
He was right.
His company grew into something significant.
I was the unfocused one in that conversation.
Same principle, two very different conclusions.
That is what makes focus genuinely hard — and why building a unicorn is rare.
Focus means knowing your direction clearly enough to evaluate every opportunity honestly against it.
It does not mean rejecting everything by default.
It means asking hard questions:
Does this take me further along the path I have chosen?
Or does it take me somewhere else?
Most of the time, the answer is the latter.
But sometimes, as the first story shows, the answer is more complicated.
Another question I suggest every founder ask regularly:
If I were starting today, would I still build this the same way?
These questions keep you adaptive without making you reactive.
Stubbornness closes them down.
Focus keeps them open.
Why Founder Mode Works
Most of the advice founders receive as they grow is predictable:
Build a strong team
Focus on what matters most
Delegate the rest
That advice is often correct.
But in practice, founders sometimes step back too early and too far from the product, the team, and the customer.
That is when things start to go wrong.
The concept of Founder Mode, popularized by Paul Graham in 2024, captures something I have believed for years.
Staying deeply involved in product is not a sign that a founder cannot let go.
At the right stage, it is the whole game.
This is one of the strongest predictors of success I have seen.
Every company I have backed that reached significant scale — Miro, Deel, Turing, PandaDoc, Babylist, Eight Sleep — operated this way.
Andrey Khusid is the clearest example I know.
From day one of Miro, he was deeply involved in both strategy and product. Today, with over 1,600 employees, he still shapes product direction, speaks with major customers, and drives key hiring decisions.
The founder stayed close, and the company scaled.
Those two things happened together, not in spite of each other.
I have also seen what happens when founders step back too early.
When they delegate their vision before the company is ready, product iteration slows, strategy loses focus, and culture starts to drift.
Hired managers, however experienced, can execute against a plan.
But they cannot replace the founder’s instinct for where the company needs to go next.
Founder Mode does not mean working longer hours or controlling every task.
It means knowing where you want to take the company and staying close enough to lead it there.
Manager Mode has its place.
The mistake is letting it arrive before the company is ready.