The Changing Role of Product in the Age of AI

A few weeks ago, a PM friend of mine was prepping for an interview at a well-known growth-stage company. We were chatting about the interview process and how it's changed since they were last looking for a new role, and one set of questions in particular was different. The hiring manager had asked them:

"Walk us through how you've used Cursor or Claude Code in your product work."

This wasn't a question for an engineering or a technical product manager candidate. It was for a product manager.

I've been hearing versions of this from PM friends across the industry. Interview loops are getting more technical. Companies want to know what tools you use, whether you've prototyped with AI coding assistants, and, perhaps most pointedly, where you think the line between PM and engineer actually is. These aren't idle curiosities. They're signals of a deeper shift in the role of product that every product manager and product leader needs to be reckoning with right now.

The pressure is real

I feel it at Ontra. I hear it from other product leaders I talk to regularly. Everyone is rethinking what the PM role looks like and how teams should be structured when the cost of building has dropped dramatically.

The pressure comes from a simple reality: AI development tools have made it possible to build things faster than ever before. Cursor, Claude Code, Lovable, Replit. These tools are compressing development cycles in ways that would have seemed absurd two years ago. In particular, the Opus 4.6 release inside of Claude Code seems to have unlocked a whole new realm of possibilities. An in-code prototype that once took an engineer a sprint can now take an afternoon. A proof of concept that required a cross-functional team can sometimes be hacked together by a single person with the right tools and a clear idea.

When building gets that much easier, the natural question follows: what exactly is the PM's job now?

Knowing what to build has never mattered more

Here's the thing that I think gets lost in the excitement: faster building doesn't eliminate the need for product thinking. It amplifies and democratizes it.

When the bottleneck was engineering capacity, bad bets were expensive but naturally constrained. You couldn't build everything, so prioritization did some of the filtering for you. Now that you can build almost anything with much less effort than before, the risk isn't that you can't ship. It's that you ship lots of bad things faster (the AI slop of product development).

This is why discovery and validation aren't just still important: they're more important than they've ever been. The ability to talk to customers, understand their actual problems, and validate that your proposed solutions will resonate. That's the work that separates product teams that generate real outcomes from those that generate a lot of output.

There's no substitute for direct interaction with customers. You still need to sit across from them (or hop on a Zoom), listen to what they're struggling with, watch how they work, and pressure-test your assumptions against their reality. Then you need to validate that the solutions you've come up with are actually going to solve the problems you think they will, that customers will adopt them, and that they're technically feasible.

The core loop of continuous discovery hasn't changed. What's changed is the stakes. When you can build anything, knowing what not to build becomes a superpower.

The technical literacy bar has risen

Here's where things get genuinely different for PMs, and where I think a lot of people are behind.

For a long time, product managers could operate with a relatively stable understanding of how technology works. The high-level concepts didn't change that much from decade to decade. You could understand APIs, databases, and system architecture at a conceptual level and be effective in your role. The underlying technology evolved, but it evolved gradually enough that the abstraction layers held.

AI and its pace of development has broken that contract.

The pace of change in AI capabilities is fast enough that PMs who don't invest in understanding the underlying technology will increasingly struggle to assess what's feasible, what's reliable, and what's genuinely novel versus what's hype. You don't need to be able to train a model from scratch. But you do need a working understanding of some foundational concepts:

• How neural networks work at a high level
• How large language models work under the hood, not just as magic text boxes, but as systems with real constraints, failure modes, and capabilities
• What agents are and what different agentic patterns look like
• When agentic solutions make sense and when they don't

This isn't about becoming a machine learning engineer. It's about having enough technical depth to be a credible partner to your engineering team, to ask the right questions during technical design, and to make sound feasibility judgments without defaulting to "let's just try it and see."

In regulated industries like legal–my world at Ontra–this matters even more. When outputs need to be right, when there needs to be a human in the loop who can verify what an AI system produces, understanding the mechanics behind these systems isn't optional. It's table stakes for building products that are trustworthy enough for customers to actually use.

The great blending

All of this is accelerating a trend that I think will define the next few years of how product teams operate: the blending of roles.

Teams are going to get leaner. You'll be able to do more with fewer people. But more importantly, the boundaries between disciplines are going to blur in ways that are genuinely exciting.

Designers will be coding more often, prototyping directly in tools that generate real in-product interfaces rather than static mockups. Product managers will be building functional prototypes to align their teams and communicate ideas, not just writing specs. And engineers (here's the part that gets less attention) will be doing more product and UX thinking. When AI handles more of the implementation grunt work, engineers have more capacity to engage with the why behind what they're building, to participate in discovery, to challenge product assumptions with technical insight.

This isn't about everyone becoming a generalist. It's about the connective tissue between roles becoming thicker. The PM who can prototype, the designer who can code, the engineer who deeply understands the customer problem. These people will have an outsized impact on their teams. Not because they're replacing each other, but because shared context creates compounding returns.

This burgeoning dynamic also makes everyone a teacher and a learner. You need to be willing to help develop product thinking in your cross-functional counterparts and seek them out to learn from them.

I've already seen this playing out in my own work. I'm a former engineer and have my master's in AI, but haven't coded for work in years. That changed last week when I made my first PR at Ontra! I showed a review app to my UX and engineering counterparts with the idea I was playing with. We weren't debating what something might look like or how it might work. We were looking directly at it in-product, poking at it, and iterating from a shared starting point.

What this means for how we structure teams

If I had to bet on how this all shakes out, here's where I'd put my chips:

Teams will be smaller but more capable. The model of large, specialized teams where each person owns a narrow slice of the work is going to give way to smaller groups of people who can operate across boundaries. I don't think this necessarily means companies will downsize, just that the teams are leaner and deployed across a larger surface area. A PM who can prototype, a designer who can implement, an engineer who understands the problem space deeply. Three people like this can outrun a team of ten that's operating in silos.

Technical fluency will be a hiring filter for PMs. The interview question my friend received is a leading indicator. Companies will increasingly expect product managers to demonstrate fluency with AI tools, not just conceptual understanding. "Have you used it?" is a different question than "Do you understand it?", and companies are starting to ask both.

Discovery gets elevated, not eliminated. As building becomes cheaper, the organizations that invest most heavily in understanding what to build will have the biggest advantage. The PM role doesn't shrink. It shifts toward higher-leverage activities. Less time writing detailed specs that serve as engineering handoffs. More time in discovery, validation, and strategic thinking about where to place bets.

What's coming next

To do my part in helping PMs build the technical foundation this era demands, I'm going to dedicate the next several posts to breaking down the key AI concepts I think every product manager should have in their toolkit:

• How neural networks work: the building blocks of modern AI, explained for product thinkers
• How LLMs work under the hood: moving beyond the "magic text box" mental model
• What agents are and how they're built: understanding the agentic patterns that are reshaping product development
• The AI deployment and adoption playbook: how do you encourage internal teams to take full advantage of new tools and lean in?
• Vector databases, embeddings, and RAG: important tools for making the most of LLMs.
• When to use agents (and when not to): the judgment calls that separate thoughtful implementation from hype-driven decisions
• My take on how team structure will change as tech advances: what will the product teams of tomorrow look like once this tech has fully taken hold? How will they work?

These won't be computer science lectures. They'll be practitioner-focused breakdowns, aimed at giving you enough depth to be dangerous in the right ways: to ask better questions, make sharper feasibility calls, and build more effectively with your engineering partners.

The role of product is changing. The PMs who lean into that change and build technical fluency alongside their product instincts are going to thrive. The ones who wait for the dust to settle may find that the ground has shifted beneath them.

Stay tuned. We're just getting started.