
I speak to senior product leaders every week. Right now, nearly all of them tell me the same thing: Their organization is undergoing an AI transformation, and it’s challenging, but they’re making headway. And when I ask them what that actually means in practice – what's changed, what the organization can now do that it couldn't do before – the answers all share a familiar shape: Licenses have been rolled out, a champions group has been formed, teams have been encouraged, and somewhere, someone proudly declared the company was “leaning into AI”.
That’s all great stuff. And I'm not saying none of it matters. But what I am saying is that none of it is a transformation. And the gap between what's being called an AI transformation right now and what would actually constitute one is, in my view, one of the most consequential and least-discussed problems in product organizations right now.
Book a demo
Let me concretely describe what I'm seeing, because the discourse around AI transformation tends to operate at altitude: broad claims about competitive advantage, workforce disruption, productivity multipliers. What's actually happening in most organizations is more specific and more concerning.
Someone somewhere makes a decision: The organization needs to be doing AI, rightly so. Licenses get purchased. Teams get access. Some organizations go further: They create task forces, appoint champions, run workshops. The more progressive ones explicitly ask their teams to integrate AI into how they work.
And in the vast majority of cases, the “transformation” stops there.
What you're left with is not an AI-native organization. What you're left with is a collection of individuals who have access to AI tools and are solving their own problems in their own way, in isolation from each other. Single-player AI, as John Cutler likes to call it. Every person builds their own workarounds, using their own prompts, creating their own micro-workflows. The person sitting next to them does something entirely different. Nothing connects. Nothing compounds. Nothing speaks to anything. And the organization as a whole is not more capable than it was before; just noisier.
This is the problem: There’s a prevailing belief that access equals adoption, and that adoption equals transformation. It doesn't. What you've effectively created is yet another silo layer. Except this time, the silo goes all the way down to the individual.
There is a deeper version of this problem that I want to name directly, because it frustrates me more than almost anything else I see in my work.
Some organizations do go beyond licenses. They identify processes that AI can accelerate and then do so: PRD generation, meeting summaries, research synthesis, status updates. The old work, done faster.
And here is what I want to ask every leader who has celebrated this kind of progress: Did you ever stop to ask whether the thing you're now doing faster was the right thing to be doing in the first place?
Take PRDs, for example. The premise of the AI-powered PRD is that producing them more quickly and at a higher quality is in itself a good outcome. But what is a PRD actually for? It exists to create alignment, to ensure that the people building a thing and those with a vested interest in seeing it built agree on what success looks like before significant time and money are spent. If your organization has a problem with that, the answer does not lie in producing more of them faster. The answer is to ask why alignment is failing, and whether a PRD is still the best mechanism to achieve it with the tools we have today.
And this is my problem with most “AI Transformations”: uUsing AI to do the old thing at higher volume or speed is not transformation. It's optimization. And optimization, for all its value, does not change what you're optimizing towards. If you're running fast in the wrong direction, AI just helps you get further from where you want to be.
There’s one last thing missing from this picture, and it’s not new: For most transformation efforts, nobody has ever concretely defined what success actually looks like.
Are you expecting to move faster?
How much faster, and in which parts of the process?
Are you expecting higher quality outputs?
How will you measure quality? Fewer bugs? Better decisions? More product-market fit? Reduced time to insight? More revenue?
These are not rhetorical questions. They are fundamental. They are the questions that determine whether your transformation has worked. And in my experience, almost nobody has asked them. Which means that even where AI adoption is high and enthusiasm is genuine, there is no basis on which to evaluate whether the real, monetary investment is returning value, or to know when to change course.
The irony is not lost on me that the people most likely to be leading AI transformations are product folks; the same people most trained to ask these exact questions. We know better than anyone that you don't commit to a direction without first defining what success looks like. We know that measuring output is not the same as measuring outcome. We know that enthusiasm and activity are not evidence of progress.
And yet when it comes to transforming our own operating models, we apply almost none of that rigor. We celebrate adoption rates. We count the use cases. We showcase the time saved on easy-to-measure things. But we rarely ask the harder question: Is this actually making us a better organization? And if so, at what, specifically, and by how much?
You wouldn’t build a feature without knowing what good looks like. So why build your organization this way?
I’ve spent enough time diagnosing transformation failures to have an opinion on what I believe an actual AI transformation demands.
A genuine AI transformation requires your organization to rethink, from the ground up, how work gets done. Not which tools assist the existing work. Not which micro-actions you can speed up. How the work itself is structured, sequenced, and owned.
That means asking which parts of your operating model genuinely benefit from AI involvement and which parts require human judgment that cannot and should not be delegated. It means being explicit about where humans and agents collaborate, where humans must stay in the driver's seat, and where automation can be trusted to operate independently. And it means building guardrails and risk trade-offs into the model itself, not as an afterthought.
But crucially, it also means building the information infrastructure that makes any of this possible at all. AI, whether that's a tool your team uses or an army of agents operating inside your lifecycle, will only ever be as good as the context you give it. That means your strategic intent needs to be explicit, accessible, and current. Your data, quantitative and qualitative, needs to flow through your organization in a way that is legible to both humans and machines. Your decisions, trade-offs, and constraints need to live somewhere findable, not scattered across inboxes and presentation decks from eighteen months ago.
This is not a technology problem, and it’s not a people problem. It is an operational one. And it is the hardest kind of problem to solve, because it requires your organization to do the uncomfortable work of making its own thinking explicit, and discovering, in the process, how much of it was never that explicit to begin with.
I want to be direct about the stakes here, because I think they are genuinely underappreciated.
Most organizations have always had operating model dysfunctions: vague strategic intent, unclear decision rights, siloed information. And most organizations have coped, because the humans inside them are remarkably good at navigating ambiguity. They use experience, intuition, relationships, and hard-won context to make things work despite the system.
AI does not navigate ambiguity the same way. An agent operates on the context you feed it. If that context is incomplete, it will still confidently execute, but to your detriment. And as AI becomes more deeply embedded in how product work gets done, the dysfunctions that humans could work around now become operational failures that cannot be papered over.
This is what keeps me up at night when I look at how most AI transformations are run: The teams that think they are ahead because they have the most licenses and the most enthusiastic champions are often the ones most exposed. Because they are layering AI onto a foundation that was never strong enough to support it.
The organizations that will genuinely benefit from AI are not the ones moving the fastest. They are the ones with the clearest operating models. The ones where strategy is legible, information flows coherently, and accountability is baked in rather than assumed. They are the ones who slowed down long enough not just to ask "can we use AI for this?" but also "are we set up for AI to actually work?"
Giving everyone a license is the beginning of a sentence. The rest of the sentence is the hard part. And most organizations haven't written it yet.
Antonia Landi










