In May, I wrote that most enterprises aren’t struggling with AI because the models are weak. They’re struggling because their operational environments were never built to support AI at scale. Get that foundation good enough and you can start delivering real value. So let’s say you’ve done it. You have a data platform you trust and your first agent running in production. What’s next? Build.

The cost of building custom software has dramatically decreased. An idea that used to take a quarter to prototype now takes an afternoon, and it can come from anyone. An analyst, a controller, or a customer success rep who got tired of doing the same thing every Monday might spin up that piece of software locally they’ve always dreamt of in minutes.

However, taking all these ideas to a “finished” state still requires time, effort, and expertise. A prototype has to authenticate against systems that already exist. It has to read and write to the platforms your business actually runs on, under the permissions those platforms already enforce. It has to be observable, so that when it starts returning something wrong you hear about it from a monitor instead of from a customer. Someone has to decide what happens when a call fails, when a model returns something malformed, when volume spikes on a Tuesday. Someone owns it at 2am. That work is slower, it’s expensive, and the capacity to do it is fixed.

So you have an unlimited supply of prototypes and a hard ceiling on how many of them can become real. That gap is the whole problem. The hard part is no longer getting ideas to a proof of concept. It’s deciding which of them are worth the effort of taking all the way to completion.

Here’s what it looks like when nobody owns that decision. There’s no shortage of activity. Business users are building constantly, enthusiasm is high, and nothing reaches production. Nobody’s job is to look at forty prototypes and say these three, and here’s why. Everything gets a little attention and nothing gets enough. A year later leadership concludes that AI didn’t work for them, when what actually happened is that nobody drove the valuable ideas to fruition.

I’ve seen this at a lot of clients now. In one case it was Streamlit apps, nearly 100 of them spun up in a matter of months. Six months later most were abandoned or half finished. I’ve also been on dozens of calls where it turned out two people were building the same thing. It’s good to see that many people are building. It just isn’t adding up to much.

So what separates the winners from the losers here? The winners get three things right.

Visibility

The first is that they don’t stifle any of that creativity, but they do give it somewhere to be seen. A regular cadence where people show off what they’ve built. That one habit kills duplicate effort and gets people early feedback from peers who can add valuable contributions early on. I’ve seen quite a few early projects end up morphing into something far more valuable with the help of feedback. Sometimes those projects end up solving entirely different problems than originally intended.

Guardrails

The second is guardrails. Building freely only works if there are controls on what data goes where, which tools are sanctioned, and which platforms people are building on. Without those, a good portion of what gets built is disqualified before anyone even evaluates it. Guardrails aren’t the thing slowing you down. They’re what makes it safe to let everyone build.

Leadership & Product Sense

The third is leadership that can spot which of those projects has real value and then put weight behind it. Those projects get handed to engineering teams who know how to take a strong prototype and turn it into something you’d be comfortable putting in front of a customer or a regulator, wired into your existing tooling and instrumented well enough that you’d trust it running unattended.

That last one is product sense, internal and external, and it’s among the hardest skills to find in the professional world. It’s the judgment to look at a field of possibilities and pick the ones that will actually matter. It’s what turns cheap prototyping into compounding value instead of noise.

A few questions worth asking when you’re deciding whether something is worth finishing:

• Is this workflow fully hands off? If not, how do I get it there? This is the question I’d push hardest on. A workflow that still needs someone watching it hasn’t been offloaded, it’s been reshaped. You may have made the task more pleasant without making it go away, and those are very different returns. The real value is being able to say “I no longer even have to think about this”.
• Am I doing the same manual task over and over? The most reliable candidates are the ones already annoying you.
• What could we be doing that we never had the bandwidth for? The best opportunities usually aren’t the things you’re doing badly. They’re the things you weren’t doing at all.
• Would I use this every day? If the honest answer is no, that tells you something about whether anyone else will.
• What have I always wanted to build here? Most people have an answer to this. Until recently it didn’t matter, because there was never enough time or any obvious place to start. That isn’t true anymore.

None of this works without a just do it mentality. Anyone should be able to test an idea without asking permission, because the cost of finding out is now trivial. If someone has to write a business case to spend an afternoon on a prototype, you’ve priced the experiment above what it’s worth and you’ll get none of them. You can afford to be wrong quickly and often now. What you can’t afford is being wrong slowly and at scale because nobody stopped to ask whether the thing was worth doing.

Next month: You’ve built some awesome products and workflows. Now how do you control costs and ensure the value of the product greater than the AI bill.

Share: