Then I tried it on my own work

So I handed it a problem I actually cared about. I had roughly 50 customer interviews sitting in a folder from a client project. The kind of asset you know is valuable and never mine properly, because reading all of it takes a week you never have. I set up a repository in Claude to pull the jobs to be done out of those interviews and map them onto a customer journey. Again it surprised me. You check the output, you do not hand it your judgement. But the week of work became an afternoon.

The gap is enablement, not capability

In both stories the technology had been ready for a while. What was missing was someone sitting down and giving it a fair shot on their own work. That is the gap I see across most product teams. The problem is enablement, not capability.

It comes down to three things.

1. Time

The first is time. Most product managers have never had an hour that was explicitly set aside to poke at AI on a problem they care about. Adoption starts with a use case someone finds for themselves and gets a little excited about. When we decided to go AI first, we ran an internal hackathon around one small, concrete problem. For us it turned into the interview repository. One protected block of time, one use case, and suddenly there was an asset nobody had before.

2. Visibility

The second is visibility. Nothing moves a skeptic like watching someone they respect get a result. My weekend with Thomas is exactly that. I did not read a whitepaper about AI coding. I watched Thomas do it, and then I opened his code myself. Make that visible inside your team. A colleague with a working result convinces faster than any pitch.

3. Tooling

The third is tooling, and here most people hit a wall. A lot of organizations still do not provide proper tools, and that becomes the reason nobody starts. Look closer at what your organization actually allows. Almost all of them let you work with AI on public information, and they do not stop you from putting public information into any tool, because anyone could do that anyway. We see this constantly in the Product Masterclass. People who are not yet allowed to touch internal data still get a lot out of what is public. Your own product documentation. Your website. Feed those in and you can pull out positioning, vision, the shape of the story you are telling the market. It works well enough that the penny drops. And once you can show that internally, you have made the case. The conversation moves from whether this is worth it to how you get the tools that are far more powerful than the public workaround.

Go first, or go together

For leaders, the job is straightforward: go first. Learn to use this yourself and show your team what is possible. Once a leader does that, the conversation in the team changes. People stop asking whether it is worth the time and start asking what else they can do with it.

You do not have to do it alone. Going through it as a team is often what makes it stick, one person figuring it out in a corner rarely spreads. That is the idea behind our company cohorts, where a whole product team learns to work this way side by side. Bring it to your team.

Christoph Leonhardt, who leads a cross-functional team of product managers at Siemens, is the clearest example I have. He went in himself, rebuilt a stakeholder feature request in minutes, and showed his team what it meant. From there they built a shared AI repository for their roadmaps and shipped a prediction game in five days that would have taken six weeks. You can read his full story here: Leading by Example: Introducing AI in Product Management at Siemens.

The whole thing fits in an afternoon. An hour, a problem you care about, one person willing to go first, and the honesty to look at the output and say when it is good.

At Product Masterclass, we train product managers to work effectively in the AI era. Our 8 week intensive program covers everything from customer interviews to vibe coding to building your personal AI workflow. Check out the next cohorts