The Lego Set for Innovation

In 2019, I flew across the Atlantic to speak at the first international no-code conference. Webflow organized it in San Francisco. The room was packed with people who believed that how we build software was about to fundamentally change. There was this electricity in the air, the kind you feel when a group of people collectively realize they're early to something big.

I was Head of Product Design at PushApp at the time, and I'd spent the previous years watching large enterprises repeatedly fail at innovation. Not because they lacked talent or resources. Because they were structurally incapable of moving fast enough to learn anything useful before the market moved on.

My talk was about that failure pattern, and about why no-code wasn't just a productivity hack. It was a strategic weapon.

But the part of that speech that stuck with people (the part I still get asked about) was the Lego analogy.

The Lego insight

Here's what Legos taught me about innovation, and I mean this literally.

When you're a kid with a box of Lego bricks, your ability to create is never in question. You have the pieces. You know they fit together. The only question is: what do you want to build?

That shift is everything.

In most organizations, the conversation about innovation starts with constraints. What can we build? How long will it take? What's the budget? Who has the technical skills? Can we find a vendor? These are all questions about ability. And they eat up so much oxygen that the real question (what should we build, and why?) barely gets discussed.

When creation is no longer the bottleneck, vision gets all your attention. You stop asking "can we?" and start asking "should we?" That's when actual innovation happens. Not when you get better tools, but when the tools become so accessible that they disappear from the conversation entirely.

With Legos, you don't plan for three months before snapping pieces together. You start building. You try something. It doesn't work. You pull it apart and try something else. The feedback loop is instant. The cost of being wrong is zero. And because you're working with real objects (not blueprints, not specs, not slide decks) you discover things that no amount of planning could have revealed.

What the Lego analogy actually teaches

People sometimes hear the Lego comparison and think I'm saying innovation should be childish or unserious. It's the opposite. I'm saying innovation should be driven by impact, not by product.

When you have a box of Lego bricks, you don't fall in love with any particular assembly. You fall in love with what you're trying to create. The pieces are means, not ends. You swap them freely. You combine them in unexpected ways. You don't get attached to yesterday's configuration because you know you can rebuild it better tomorrow.

This is exactly the mindset that enterprises lack. They fall in love with the product. With the spec. With the architecture diagram. With the vendor selection. With the 18-month roadmap. And then they can't adapt when reality turns out to be different from the plan, which it always does.

The other thing about Legos: everyone can contribute. You don't need to be an engineer to snap pieces together. A five-year-old and a forty-year-old can collaborate on the same build. The blocks are transparent. There are no hidden layers, no black boxes, no "you wouldn't understand, it's technical" barriers.

That accessibility isn't a limitation. It's a superpower. When everyone in the room can participate in building, the ideas that emerge are richer, more diverse, and more grounded in real problems. The distance between the person who sees the problem and the person who builds the solution shrinks to zero.

From no-code Legos to AI Legos

In 2019, my Lego set was Webflow, Airtable, Zapier, and a handful of other tools that let you build working products without writing code. Those were real, functional bricks. You could create a website, connect a database, automate workflows, and put something in front of real users within days.

In 2026, the Lego set got massively bigger.

AI agents can generate entire applications from a conversation. LLMs can write, analyze, and reason about problems in ways that would have seemed absurd seven years ago. Automation tools connect everything to everything. The bricks are more powerful, more numerous, and more versatile than anything I could have imagined on that stage in San Francisco.

But the principle is identical.

The value isn't in the bricks. It's in what you build with them. And more importantly, it's in how fast you can tear apart what isn't working and try something new.

The companies doing interesting things with AI right now aren't the ones running year-long "AI transformation" programs. They're the ones treating AI tools like Lego bricks: grab them, combine them, test something with real users, learn, rebuild. The same playbook that worked with no-code in 2019 works with AI in 2026. The bricks changed. The game didn't.

The three benefits, updated

In my original talk, I outlined three benefits of this approach: speed, performance, and cooperation. All three are even more relevant now.

Speed meant going from idea to working product in days, not months. With no-code tools in 2019, that was achievable but required some craft. With AI in 2026, the timeline has compressed even further. You can have a functional prototype in hours. The limiting factor is no longer building. It's thinking clearly about what to build.

Performance meant that working products generate real data. Not projections, not estimates, not "market research." Actual usage data from actual humans doing actual tasks. That data is infinitely more valuable than any business case or feasibility study. In 2026, AI doesn't just help you build faster. It helps you analyze the data that comes back, spot patterns you'd miss, and iterate with more precision.

Cooperation meant breaking down the wall between technical and non-technical people. When everyone can participate in building, you get better products. In 2026, AI has taken this further. Tools like cursor, Claude, and dozens of others have made it possible for anyone with clear thinking and domain expertise to build real software. The "you need an engineer for that" barrier is crumbling. That's not a threat to engineers. It's a liberation. It frees them to work on genuinely hard problems instead of translating someone else's requirements into code.

The real lesson

I've been thinking about this for almost ten years now, and the conclusion keeps getting simpler.

The real lesson isn't about technology. It never was. No-code was a vehicle. AI is a vehicle. Whatever comes next will be another vehicle.

The lesson is about removing the distance between having an idea and testing it with real people.

Every process, every approval chain, every "we need to scope this first," every "let's write a requirements document," every "we should do more research before building" is a brick in the wall between your idea and reality. Some of those bricks are necessary. Most are not. They exist because organizations are more comfortable planning than doing, more comfortable being wrong slowly than being wrong quickly.

The best innovators I've met (in startups, in enterprises, in one-person operations) all share one trait: they are pathologically impatient about getting something real in front of real people. They don't confuse preparation with progress. They know that the fastest path to a good idea is through several bad ones.

The Lego set gives you the ability to build fast. But the courage to build wrong, learn, and rebuild? That's on you.

That's what I said in 2019. The speech is still up. Seven years later, I wouldn't change a word.