We work with a lot of enterprise level teams who are eager to deploy and integrate AI tools and tech into their teams. Naturally, they first reach for training that focuses on how to use the tools. This makes a ton of sense and often takes a consistent pattern of prompt libraries on a shared drive, workshop on building a custom GPT or Claude skill, a Slack channel where people post the clever thing Gemini did for them that morning. This is important and foundational. 

This is also the easy part. “Now go and be more [insert adjective here]”, they’re told by their leadership. Be more productive, efficient, faster, etc. Most of these folks are talented, smart, experienced practitioners and most of them have no idea what to do next. They were trained on the tool and sent back to their desks with the same backlog, the same roadmap, and the same quarterly pressure to ship more of what was already planned. The training taught them how to prompt (more or less). It said nothing about what to prompt for or how to put it to consistent productive use. 

This is like teaching folks how to use a hammer and then expecting them to go and build a comfortable chair. They want to. They just don’t have the experience nor the bandwidth to figure out how to do that with this new tool. 

Why AI tool training produces more features, not more customer value

Tool training is easy to buy and easy to measure. You can count the seats, the certifications, the prompts in the library. It feels like progress because it is binary. It either happened or it didn’t. 

I understand the appeal.The trouble is that the entire frame around it is cost. We trained the team, the team is faster, faster means cheaper, cheaper feels like a win. So that’s what teams do. They point the new tool straight back at the existing roadmap and produce more features, faster, against the same untested assumptions and vague goals they had before.

Creating more output against unvalidated assumptions isn’t innovation. It’s the feature factory on steroids. The customer feels none of it (or at least nothing positive), because nothing about the speed of production changes whether you were building the right thing in the first place. Not to mention you’re now flooding your user experience with new features at a pace no human can consume. 

Tools training buys you speed. But it’s permission, psychological safety and an explicit organizational backing for experimentation that buys you exponential innovation with AI.

Innovation needs a safe space to experiment, not just a faster tool

Here’s the question I wish more leaders were asking themselves: when AI hands a team three or four extra hours per week and brand new powerful tools to use, does the organization actually give them anywhere to spend those hours other than the backlog?

In most places, the honest answer is no. There’s no slack in the system for a team to chase a hunch about an unmet customer need. There’s no budget line for an experiment that might not work. There’s no part of the quarter that’s protected for discovery. The AI capability now exists, but the permission doesn’t, and capability without permission just gets absorbed by the feature factory output machine that was already running.

The companies getting real value out of AI, the small number of them, are doing something different. They’re using the time the tools give back to create deliberate room for experimentation. This can be a protected day a week to just play with the new tools or a small budget a team can spend without three approvals on some guesses they’ve never been able to dig into before. The AI tool training created the capability to do, at times, miraculous new types of work. Leadership now has to create the bandwidth for it to happen.

Teach product teams to ship, sense, and respond

I’ve spent years arguing that good product organizations work as a continuous loop: you ship something small, you sense how customers actually respond to it, and you respond by changing what you do next. AI can amplify these learning loops to incredible new levels of learning and iteration. The issue is that most organizations are focusing on the first part, the shipping, and ignoring the value of AI in the rest of the learning loop.

When producing a small thing costs almost nothing, the differentiating work is sensing (reading real customer signal out of the noise) and responding (having the judgment and the authority to change course based on what you learned). Those are learnable skills. They are also the ones being crowded out, because a team drowning in “ship more, now” never gets to the sensing part. They’re too busy producing to notice what any of it did.

If you’re going to train your teams on anything beyond the tools, train them to close that loop. Teach them to instrument what they ship so a customer signal actually comes back. Teach them to read it. Then, and this is the part that’s on leadership, give them the room to act on it.

Make it safe to fail, or you’ll only get more features faster

None of this works without the unglamorous foundation underneath it: it has to be safe to run an experiment that fails. If the only thing that gets rewarded is shipped features, and a failed experiment goes on someone’s performance review as wasted time, every rational PM will quietly stop experimenting and go back to the backlog. They’d be right to. There’s a clear disincentive to trying something new.

I suspect this is where most AI transformations are currently falling short. It isn’t ultimately a tools question or even a skills question but rather a permission question, and permission is something only leadership can grant. You can buy every seat of every AI tool on the market and you will still get a faster feature factory if the people using it don’t believe it’s safe to try something that doesn’t work.

Instead consider how to enable your PMs to run experiments in safe environments on real data. Give them better access to the usage data that can improve their prompts. Provide clear governance rules that make it clear how to experiment safely with the new AI tools. We’re now working with non-deterministic tools and systems. Assuming we can use the old guardrails for experimentation and learning is naive. “Safe to fail” has to explicitly evolve as we further integrate AI tools and tech into our workflows and products. 

What to do before your next AI training session

If you lead a product organization, here’s the thing I’d put on the table before you book another tools training workshop. Pick one team. Take a slice of the newly found bandwidth AI just gave them, even a single protected day every two weeks, and point it at a customer problem nobody has been allowed to work on. Tell them explicitly that the goal is to learn something, not to ship something, and that a result of “this didn’t work, here’s what we found out” is a success you’ll defend out loud.

Then watch what they do with the permission they didn’t have last quarter. As that new model plays out, note the factors that made it successful and where it struggled. Scale the positive constraints to a few more teams and grow from there. The tools are important to learn but even more important is how to put them to good use. How do you improve your team’s ways of working with AI? How do you improve your customer outcomes as well? Give them the space and safety to learn and your teams will figure it out quickly on their own. They can’t wait to do it.