Product Management and AI: Why the Role Has Changed More Than Most PMs Realise

Product management has absorbed a lot of technology changes over the years without the fundamental nature of the role shifting much. Mobile changed the surface. Cloud changed the delivery model. APIs changed what was buildable. But the core job stayed recognisable: understand the problem, define the solution, align the stakeholders, ship the thing, measure the outcome.

AI is different, and I think a lot of product managers are underestimating how different.

It's not that the fundamentals of good product thinking have changed. They haven't. Understanding users, making hard prioritisation calls, translating between business needs and technical reality, those things are as important as they've ever been. What's changed is that AI is now woven through the product itself, the team building it, and the way decisions get made, simultaneously, in ways that make the role meaningfully harder and meaningfully more interesting than it was three years ago.

The PM who hasn't grappled seriously with that shift is not running the same race slightly slower. They're running a different race without knowing it.

Writing Specs for Things That Don't Behave Deterministically

Start with the most immediate practical change: what it means to specify an AI feature versus a conventional software feature.

Traditional software is deterministic. Given the same input, it produces the same output, every time. A product manager writing a spec for a conventional feature can describe exact behaviour: if the user clicks this, this happens. The engineering contract is clear. The acceptance criteria are testable. Either it works as specified or it doesn't.

AI features are probabilistic. The same input can produce different outputs on different runs. The system's behaviour changes as the model is updated. Edge cases that weren't in the test set will surface in production in ways that nobody anticipated. "The AI summarises the document" is not a specification. It's a wish.

Writing good requirements for AI features means thinking differently. What does good output look like, and how will you know when you're seeing it? What does failure look like, and what are the consequences of each failure mode? Where does a human need to be in the loop, and at what confidence threshold does the system need to escalate rather than decide? What happens when the model is updated and the output distribution shifts?

These questions don't have answers that fit neatly into a standard user story format, and the PM who tries to shoehorn them in will produce specs that set their engineering team up for frustration and their users up for disappointment. Developing a new vocabulary for AI feature specification is not optional for any PM whose product has AI in it. At this point, that's most products.

Discovery Changes When You Can Test Hypotheses Overnight

The discovery process, traditionally the most human-intensive part of product work, is being compressed by AI in ways that are still playing out.

The parts of discovery that involved gathering information, synthesising large volumes of qualitative feedback, identifying patterns across user interviews, reviewing competitive landscapes, summarising research, are now significantly faster. An AI-assisted analysis of a thousand support tickets can surface patterns that would have taken a product analyst two weeks to pull together manually. That's a real and meaningful change to how discovery work gets done.

What hasn't changed, and what AI cannot replace, is the judgment about which problems are worth solving. Faster synthesis of what users are saying doesn't tell you which of those things to prioritise, which are symptoms of a deeper problem rather than the problem itself, or which align with where the business needs to go. That judgment still requires a product manager who understands the business, the users, and the strategy well enough to make calls that aren't just data-driven but are actually right.

The risk of faster discovery is that it creates an illusion of more certainty than actually exists. A very thorough-looking AI-generated research synthesis is still only as good as the underlying data and the quality of the questions asked of it. The PM who mistakes a well-formatted output for a rigorous conclusion is making a specific and increasingly common error.

The PMs who are getting the most out of AI-assisted discovery are using it to do more discovery, not to do the same discovery faster. They're running more user interviews because transcription and synthesis are faster. They're testing more hypotheses because the cost of each test has dropped. They're covering more of the problem space because the information-gathering bottleneck has loosened. That's a genuine capability expansion, and it produces better product decisions, but only in the hands of someone who knows what to do with the extra signal.

Prioritisation When AI Is Part of the Build

Here's where the role gets genuinely complex in a new way. When AI is not just a feature but a component of the delivery capability itself, prioritisation decisions change shape.

The classic build-vs-buy question has a new variant: build vs. automate. Before committing engineering time to a feature, the question is increasingly whether an AI layer can deliver 80% of the value in a fraction of the time. In many cases the answer is yes, and the PM who isn't asking that question is building things that didn't need to be built. In some cases the answer is no, and the PM who assumes everything can be automated is accumulating technical debt in a different form: AI implementations that seem to work in a demo and fail in production.

Making that call consistently requires a level of technical literacy about AI capabilities and limitations that wasn't part of the standard PM skillset three years ago. Not deep model knowledge, but a working understanding of what current AI does reliably, where it degrades, and what the operational requirements of an AI feature look like versus a conventional one. The PM who doesn't have this is dependent on their tech lead for every build-vs-automate call, which is fine as a starting point but not a sustainable model for someone leading a product function.

Roadmap sequencing also changes. AI applications tend to require data infrastructure that takes time to build, and the sequencing mistake that's most common right now is trying to build the AI layer before the data foundations are in place to support it. A PM who understands this will sequence the unglamorous data work into the roadmap explicitly, knowing that it unlocks everything that comes after. A PM who doesn't will overpromise on AI features and underdeliver, which is a very specific and increasingly common credibility problem.

The Translator Premium

The most valuable thing a PM has always brought is the ability to sit between technical possibility and human need, and translate in both directions. From users to engineers: here is the problem, defined precisely enough to build against. From engineers to stakeholders: here is what's possible, described honestly enough to set the right expectations.

AI makes this translation harder and more valuable simultaneously.

Harder because the technical reality of AI is genuinely complex, the vocabulary is unfamiliar to most stakeholders, and the gap between what AI can do in a controlled demo and what it does reliably in production is wider than most people outside engineering appreciate. A PM who can't articulate that gap clearly will either overpromise to stakeholders or undersell capability to users, usually both at different points in the same product cycle.

More valuable because the organisations that navigate AI adoption well are the ones where someone can hold the technical reality and the business need in the same conversation without flattening either. That person doesn't have to be the PM, but in the product functions that are working well, it usually is.

The PMs who are developing this translation capability are doing it through genuine engagement with the technology, not through delegation. They're building small AI tools themselves. They're sitting in on model evaluation sessions rather than just reading the summary. They're reading enough to know what they don't know, which turns out to be the important threshold. You don't need to be able to fine-tune a model. You need to know enough to ask the right questions of the person who can.

What This Means for Product Functions Right Now

For CPOs and heads of product thinking about how to build or restructure a team in this environment, the practical implications are fairly specific.

The PM profile that was most valuable three years ago, strong on process, reliable at stakeholder management, consistent at delivery, is still necessary but not sufficient. The additional layer that matters now is genuine AI literacy: not AI enthusiasm, which is easy to perform, but the specific combination of technical grounding and product judgment that lets someone make good calls at the intersection of what AI can do and what users actually need.

That profile is genuinely harder to hire for than it was, because it requires people to have done things rather than just understood them conceptually. The candidate who has shipped an AI feature, encountered the specific failure modes, and has honest opinions about what went wrong and why is more useful than the candidate who has read everything written about AI in product but hasn't built anything.

For PMs individually, the preparation question is practical: not "how do I learn more about AI" but "how do I get enough hands-on experience with AI development to have genuine opinions about it?" The answer usually involves building something, even something small, because the gap between conceptual understanding and operational reality is where the actual learning happens.

The product managers who are most effective in an AI-integrated product function right now are not the ones who use AI tools most. They're the ones who understand why those tools behave the way they do, can identify when something is wrong with the output, and can articulate the distinction clearly enough that the rest of the team trusts their judgment. That's a harder thing to develop and a correspondingly more valuable thing to have.

The Honest Version

None of this means AI has made product management easier. It has made parts of it faster, which creates space to do more and better work, or creates the illusion of having done more and better work, depending on the practitioner. The difference between those two outcomes is the PM's underlying judgment and their willingness to engage seriously with what AI can and cannot actually do.

The product function that gets this right will have a genuine capability advantage in the next few years. The one that treats AI as a layer of automation sitting on top of unchanged product processes will find out the hard way that those processes needed to change.

Product strategy and AI integration are things I work on across product functions and leadership teams. If you're thinking through how to restructure your product team or want to sense-check how AI is sitting inside your product development process, I'm happy to have a direct conversation.