We've Commoditised Innovation (And Most of You Haven't Noticed)

We've commoditised innovation. Not the ideas — you can't commoditise human creativity. But the ability to experiment? The ability to go from "I wonder if this works" to "let me try it"? That used to be expensive, slow, and bespoke. Now it isn't. Except where it is.

We've now commoditised innovation.

For cloud services in local government, it still is. And that gap — between the components that have commoditised and the access that hasn't — is where most of your strategy is quietly dying. I should explain what I mean, because "commoditised innovation" sounds like something a consultant would say on a stage before selling you a three-year transformation programme. It isn't. It's an observation about evolution — specifically, about what happens when the evolution axis shows you two things that should be moving together but aren't.

Cloud compute has commoditised. Storage is a utility. Even sophisticated AI services — natural language processing, computer vision, translation — are moving rapidly from product to commodity. Available, standardised, cheap. But the ability to experiment with those commoditised services in local government? That's stuck in the custom-built phase. 209 NHS organisations and 320 local councils each independently navigating procurement for substantially similar tools. Every council negotiates its own path. Every team writes its own business case. Every experiment requires bespoke approval.

The components have commoditised. The access hasn't. And the strategy for each is completely different. If you can't see that gap, you're playing chess without a board.

Both sides are right (and both are wrong)

Here's the debate I keep hearing. On one side: "We need sandboxes! Let people experiment! Remove the barriers!" On the other: "Sandboxes are theatre. 88% of AI pilots never reach production. You're just generating experiments that go nowhere."

Both sides are right. Both sides are wrong. Because they're talking about different things at different stages of evolution.

The sceptics are right that a sandbox without a path to production is theatre — expensive, demoralising, innovation-flavoured prattle that changes nothing. But the advocates are right that without a sandbox, you never discover what the path to production should look like. You can't write a business case for something you haven't been able to try. And you can't know what's worth scaling until you've seen it work at the smallest possible scale.

The resolution, as usual, sits on the evolution axis. Experimentation is a component. The sandbox is a component. The path from sandbox to production is a different component. And they are not independent — experimentation access enables sandboxes, sandboxes generate learning, and the path to production converts that learning into operational value. Break the chain at any point and the whole thing stalls. Most organisations haven't mapped any of this, let alone worked out what evolution stage each one is at. That's the problem. Not sandboxes. Not the absence of sandboxes. The absence of a map.

The silent majority

Let me tell you about someone I'll call Sarah. She's a data analyst at a district council — one of the smaller ones, the kind where you're expected to do three jobs and be grateful for two. She's been there since 2014, when she applied for something in planning and ended up in data by accident. Last year she had an idea: use an AI language model to draft initial responses to Freedom of Information requests. Not the decision — the drafting. She reckoned it could save her team fifteen hours a week.

Sarah looked into it. She'd need access to a cloud environment. That meant a business case. The business case meant her line manager, who said it was a good idea and, with genuine sympathy, said it would take about a year. Then the digital board, who meet quarterly. If approved, procurement would take twelve to twenty-four months. By which point the AI services she wanted to test would have evolved twice over. Sarah felt the energy drain out of the whole thing somewhere between the second email and the third form.

Sarah didn't fail. Sarah didn't even start. She went back to her day job, because people have day jobs, and I don't blame them for doing the thing they're actually paid to do. Her idea exists only as an unexpressed hypothesis. We have no idea how many Sarahs there are, because their innovations are invisible. They don't show up in any metric. The MHCLG Future Councils pilot found that the number one blocker to innovation in local government was "no way to de-risk innovation." Not lack of ideas. Not lack of ambition. No safe way to try.

That's a landscape problem, not a people problem.

Conway's Law is eating your cloud migration

Melvin Conway observed in 1968 that organisations produce designs that mirror their communication structures. Give an organisation a cloud platform and what do they build? The organisation they already have. On the cloud. 52% of cloud migrations are lift-and-shift. McKinsey estimates that lift-and-shift wastes roughly two-thirds of the potential value. Two-thirds. That's not a migration strategy. That's an expensive relocation.

If your procurement process takes eighteen months, your innovation cycle takes eighteen months. If your governance requires a business case before anyone touches a cloud console, you've built a structure that guarantees nobody will discover the things that business cases can't predict. And here's what most people miss: procurement itself is a component on the evolution axis. It's sitting in the custom-built phase — every council designing its own process — while everything it governs has moved to commodity. That mismatch is the real architectural problem.

And what happens when the rational choice is not to try officially? You already know. 71% of UK employees are using unapproved AI tools at work. Shadow IT isn't a mystery. It's Conway's Law applied to experimentation: if the official structure won't support the work people need to do, they'll create an unofficial structure that will. The NCSC understands this — their guidance explicitly says to "avoid unnecessary IT lockdowns" because the alternative is worse.

You lock down environments to prevent risk. People experiment unofficially, outside your governance, outside your visibility. You've created exactly the risk you were trying to prevent. Brilliant.

What commoditised experimentation actually looks like

So what if you could push the ability to experiment from custom-built towards commodity? Not the ideas. Not the cloud services. The access.

That's what NDX:Try appears to be doing. It's part of the National Digital Exchange, and the proposition — if it works, and I'm genuinely not sure yet — is to remove the procurement wall between people like Sarah and the cloud services that have already commoditised. Free sandboxes for local government. You do a quiz, pick a scenario, get a working environment. Whether that means anything useful is the question I can't answer yet. And there's a landscape question worth asking: lowering the barrier to experimentation on a hyperscaler's platform is not the same thing as building public digital infrastructure. Whose sand are these sandcastles built on? That matters, and I'd want to see it mapped.

Now, I've seen enough "innovation platforms" to be deeply sceptical. Most of them are rubbish — consultant-designed, workshop-delivered, context-free. But let me be honest about what makes this different on the evolution axis: it's not trying to make innovation happen. It's trying to make the cost of trying low enough that people try without needing permission, funding, or irrational conviction. That's an infrastructure play, not an innovation theatre play. And the distinction matters.

The bit I'm less sure about

Here's where I hedge, because this is gameplay, not doctrine. I don't know whether commoditised experimentation leads to better outcomes or just more experiments. That 88% pilot purgatory number deserves more than a passing glance. If all you're doing is making it easier to create things that go nowhere, you've commoditised innovation theatre. Well done. Slow clap.

But I don't think that's the whole picture. Let me be precise about what I think is doctrine and what's gameplay here.

Doctrine: reduce the cost of experimentation and you increase the rate of learning. That's always true. It doesn't depend on context.

Gameplay: whether this particular platform delivers on that doctrine for this particular set of organisations — that's context-specific. I might be completely wrong. NDX:Try might gather dust in six months. Who knows.

What I do know is that the sandbox-to-production gap is real, and it's a separate component that needs its own strategy. The people building this need to map that gap as carefully as they've mapped the sandbox itself. If there's no path from "I tried something interesting" to "this is now running in production," then the sceptics are right and this is sandcastles. The path from sandbox to production is where the hard work lives — and where most innovation platforms quietly die. I'd want to see that map before I'd call this a success. But the fact that someone is addressing the experimentation access component at all? That's worth paying attention to, because almost nobody else is.

Where's your map?

If you're in local government technology, here's my challenge. Map your experimentation landscape. Not your cloud landscape — your experimentation landscape. How long does it take to go from idea to prototype? What are the dependencies? Where's the friction? Is it there for a reason that still makes sense, or is it one of those institutional habits where nobody remembers why it started but everybody assumes it must be important?

Map it. You might be surprised by what you find.

The mapping might reveal something I haven't considered. That's rather the point. At least with a map, you can see where you're wrong. Without one, the Sarahs in your organisation will keep having ideas and keep not trying them, and you'll never even know what you lost. And if you are a Sarah — if you can see the wall but can't move it — then at least this map gives you the language to name what's being lost. Making the invisible visible is sometimes the first act of change.

The 400+ councils standing at that procurement wall aren't short of ideas. They're short of a way to test them. The ideas that would have saved time, reduced cost, and actually improved services for residents — those ideas are sitting in people's heads, unexpressed, untested, and decaying. Every month that wall stays up, the gap between what's possible and what's attempted gets wider. That's not a technology problem. That's a situational awareness problem. And you won't solve it until you can see it.

(Views in this article are my own.)