Wrong Idea, Ages to Build, Start Over

Here's how most enterprise innovation projects actually go.

Someone at the top has an idea. Maybe it came from a board meeting, maybe from a competitor's press release, maybe from a conference keynote that felt inspiring at the time. The idea gets handed down. A team gets assembled. Requirements get written. Budgets get approved. Vendors get selected.

Then the building starts. And it takes forever.

Months pass. Sometimes a year. The team is heads down, building to spec, because the spec is what got funded. Nobody is talking to actual users yet because there's nothing to show them. The product isn't ready. It needs more features. It needs to be "complete."

Finally, the thing launches. Real users touch it for the first time. And almost immediately, the feedback starts rolling in. The core assumption was wrong. Users don't want what was built. They want something adjacent, something simpler, something nobody thought to ask about because nobody asked them in the first place.

But here's where it gets worse. The feedback gets ignored. Not maliciously. Structurally. The team has spent a year building this thing. Leadership approved this thing. Careers are attached to this thing. So the team "iterates" by adding more features on top of the same broken foundation, hoping that volume will fix a direction problem.

The metrics stay flat. Or they're inconclusive. Nobody can prove the project failed, but nobody can prove it succeeded either. Eventually, someone blames the market timing, the technology choice, or the team composition. The project gets quietly shelved. A new idea surfaces. The cycle starts again.

I've watched this pattern play out in corporations of every size, across every industry. And in 2019, I stood on stage at the first international no-code conference and described it in exactly these terms.

Why this keeps happening

The conventional wisdom used to be that competitive advantage was sustainable. You built a moat (a patent, a distribution network, a brand) and you defended it. Strategy was about finding a position and holding it.

That world is gone. And it's been gone for a while.

Today, advantages are transient. Barriers to entry collapse faster than anyone can rebuild them. A competitor can replicate your product in weeks using tools that didn't exist six months ago. The companies that win aren't the ones with the best first idea. They're the ones that can cycle through ideas faster than everyone else.

Think about what happened to Dell. They perfected the direct-to-consumer PC model. Built an empire on it. Then the market shifted to mobile, to cloud, to experiences over hardware. The moat they spent decades building became irrelevant almost overnight. Not because someone out-executed them on PCs. Because the entire game changed.

This is the environment every large company operates in now. And yet most of them are still structured as if advantages last forever.

The structural problem

Large corporations are exceptional at one thing: optimizing what already works. They're built for it. Process, efficiency, margins, scale. These are the muscles they've trained for decades, and they're genuinely world-class at flexing them.

But innovation doesn't live in that part of the curve.

Innovation lives at the beginning, where everything is uncertain. Where you don't know if the idea is right, if the market exists, if the timing is correct. That phase requires a completely different set of capabilities: speed, tolerance for failure, direct contact with users, willingness to throw away work that isn't landing.

Corporations are structurally allergic to all of this.

They can't move fast because every decision requires approval chains. They can't tolerate failure because failure threatens careers and budgets. They can't get close to users because there are layers of hierarchy, research teams, and legal reviews between the builder and the person who'll actually use the thing. And they absolutely cannot throw away work, because sunk cost isn't just a fallacy in enterprises. It's a political reality.

So what happens? They try to innovate using the same processes they use to optimize. They write detailed specs before building. They plan 18-month roadmaps for products that don't exist yet. They treat uncertainty like a risk to be mitigated instead of a signal to be explored.

And the cycle repeats.

What changed (and what didn't)

In 2019, I argued that no-code tools weren't just a shortcut for non-technical people. They were a strategic approach to breaking this cycle. The idea was simple: if you can build a working product in days instead of months, you fundamentally change the economics of innovation. You can test ten ideas in the time it used to take to build one. You can put something real in front of users before you've committed to it. You can fail cheaply and learn fast.

I called it the Lego analogy. When you have a box of Lego bricks, you don't spend months planning what to build. You start building. You try things. You tear them apart and rebuild. The cost of being wrong is almost zero, so you can afford to be wrong often. And because you're building with real pieces, not abstract plans, you see problems and opportunities that no spec could have predicted.

Seven years later, the technology has changed completely. No-code gave way to low-code, which gave way to AI agents that can build entire applications from a conversation. The tools are incomparably more powerful now.

But the argument is identical. Word for word.

Replace "no-code" with "AI" in my 2019 talk and every single point lands harder. The cycle is the same. The structural problems are the same. The solution is the same: treat rapid-build tools as a strategy, not a software category.

The companies that are actually using AI well in 2026 aren't the ones buying enterprise AI platforms and running 12-month implementation projects. They're the ones using AI to collapse the time between idea and user feedback from months to hours. They're running the Lego playbook, just with better bricks.

What actually works

The lesson is painfully simple, which is probably why so few organizations follow it.

Speed of iteration beats quality of first idea. Every time. Without exception.

If you can put a working product in front of real users within days of having the idea, you will learn more in that first week than in six months of planning. Not because planning is useless, but because plans are built on assumptions, and assumptions are almost always wrong in ways you can't predict.

A working product generates real data. Real data settles arguments. When you have actual usage metrics, actual user behavior, actual feedback from people who tried to accomplish real tasks with your tool, the debates about strategy and direction become irrelevant. The product tells you what it wants to become.

This means accepting some uncomfortable truths.

Your first version will be embarrassing. Ship it anyway. The feedback from ten real users is worth more than the opinions of fifty internal reviewers. Perfectionism in the early stages isn't quality. It's fear.

Most of your ideas will be wrong. That's not a problem if each idea only costs you a few days. It's a catastrophe if each idea costs you a year.

The people closest to the problem should be building the solution. Not writing requirements for someone else to build. Every layer of translation between the person who understands the problem and the person building the solution adds noise and removes speed.

The video is still up

I said all of this almost ten years ago, standing on a stage in San Francisco. The speech is still on YouTube. You can watch it and judge for yourself how much has changed.

The technology is unrecognizable. The tools I was excited about in 2019 look primitive compared to what's available now. But the diagnosis? The failure pattern? The structural barriers? The solution?

Identical.

The problem was never the technology. It was never no-code versus code, or AI versus traditional development. The problem is that large organizations are designed to optimize, not to explore. And until that changes, no tool (no matter how powerful) will fix the cycle on its own.

The tool gives you the ability to move fast. But moving fast requires permission to be wrong, structures that reward learning over planning, and leaders who understand that the best strategy is the one you can test tomorrow.

That was true in 2019. It's true in 2026. I suspect it'll still be true in 2033.