96% of PMs Use AI Frequently - Is the PM Role Converging With Engineering?

[product_david]

I’ve been watching the AI tools landscape evolve rapidly, and a recent industry report stopped me in my tracks: 96% of product managers now use AI on a frequent basis, with nearly half describing it as “deeply embedded” into their workflows.

But here’s what’s really got me thinking: this isn’t just about efficiency gains. The nature of what PMs do is fundamentally shifting.

The Numbers Don’t Lie

• 94% of PMs use AI daily or often
• Product professionals save an average of 4 hours per task with AI assistance
• Across core PM functions, that totals roughly 33 hours saved - almost a full work week

That’s remarkable productivity. But the implications go deeper.

Role Convergence is Real

What I’m seeing in practice - and hearing from PM peers across the industry - is that the boundaries between product, engineering, design, and even GTM functions are getting blurry fast.

Consider what PMs can now do with AI assistance:

• Explore codebases and ask intelligent questions about files and architecture
• Spin up prototypes without waiting for engineering bandwidth
• Add basic tests and AI evaluations alongside engineering partners
• Draft technical documentation that previously required deep technical expertise

This isn’t PMs becoming engineers. It’s the work that used to be fragmented across specialists now flowing through fewer people.

The New PM Skill Stack

Here’s what’s changed in what we’re expected to know:

1. Technical fluency matters more than ever - PMs don’t need to code, but must understand APIs, data infrastructure, and AI architecture deeply
2. We must speak the language of AI systems - how models are trained, deployed, and evaluated
3. Business ownership is the new baseline - PMs are now expected to think like founders, shaping GTM strategy, competitive positioning, and revenue models

The definition of product leadership now includes context engineering and orchestrating agentic workflows. If you’re not thinking about these things, you’re already behind.

The Hiring Signal

Perhaps the most telling data point: 71% of hiring managers would choose a less-experienced candidate with strong AI skills over an experienced one without them.

That’s not a subtle shift - that’s a complete inversion of traditional hiring priorities.

My Questions for This Community

1. Are you seeing this convergence in your organizations? Are PM/Eng/Design boundaries getting blurrier?

2. How are you thinking about the “AI-first PM” skill set? What should we be learning?

3. Is this convergence healthy? Or are we losing something by having generalists replace specialists?

4. For engineering leaders - how do you feel about PMs who can now peek under the hood more effectively?

I’m genuinely curious whether this is a temporary moment of experimentation or a permanent restructuring of how product teams operate.

[alex_infrastructure]

This resonates deeply from the infrastructure side. I’m seeing PMs at my company who can now actually have meaningful conversations about our LLM deployment architecture - they understand tokens per second, inference costs, context windows, and how these affect product decisions.

The interesting shift I’ve noticed: PMs who get AI infrastructure basics are making dramatically better product decisions.

Example: Last month, a PM asked intelligent questions about our model serving latency before proposing a feature. She understood that streaming responses would change the UX timeline expectations. That conversation would have been impossible two years ago - we would have built something, discovered it was too slow, and then had to re-architect.

But I want to push back slightly on the “convergence” framing.

What I’m actually seeing is complementary depth, not replacement. The PMs who are most effective aren’t becoming junior engineers - they’re developing enough technical vocabulary to:

• Ask the right questions at the right time
• Understand trade-offs without needing deep implementation knowledge
• Prototype concepts that communicate intent to engineers

The ones who try to actually engineer solutions themselves often create more work for my team, not less. There’s a difference between “I can explore this codebase with AI assistance” and “I should make changes to this codebase.”

To your question about how engineering feels about PMs peeking under the hood: I love it when they do it thoughtfully. The worst PMs are the ones who make demands without understanding constraints. The best now show up with context.

What concerns me is the 71% hiring stat. Are we selecting for AI tool proficiency over product intuition? Those are different skills.

[eng_director_luis]

David, Alex - this thread hits on something we’ve been actively navigating at my org.

From an engineering leadership perspective, I’m seeing both the opportunity and the risk in this convergence.

The opportunity: My best product partners now have enough technical context to write clearer acceptance criteria. When they understand the data model, when they can articulate why a sync approach might be simpler than real-time streaming, the requirements we get are dramatically more implementable on first pass.

That 4 hours saved per task? I bet some of that is reduced rework because PMs are catching feasibility issues earlier.

The risk: We’re also seeing PMs who now skip the engineering conversation entirely because they’ve “already prototyped it with AI.” They show up with a working demo and ask “can you just make this production-ready?”

That’s not collaboration. That’s handoff with extra steps.

The healthiest pattern I’ve found is what we call “exploration with permission.” A PM might say: “I used Claude to prototype this flow and explore the codebase. Here’s what I learned. Now I want your perspective on whether my assumptions hold.”

That’s radically different from: “Here’s the solution, now build it.”

On the skill stack question: I’m actively updating our PM-Eng working agreements to acknowledge these new capabilities. We’re trying to define:

• What PMs should explore independently (user flows, data queries, prototype concepts)
• What requires engineering partnership (architecture decisions, performance implications, security considerations)
• What remains engineering-owned (production code, system design, scaling decisions)

The blurry boundaries require clearer operating agreements, not fewer.

@alex_infrastructure - I agree on the hiring concern. Tool proficiency is table stakes, but it doesn’t replace the judgment that comes from years of shipping and learning from failure.

[cto_michelle]

I want to zoom out and address the “is this healthy?” question, because I think there’s a larger organizational design implication here.

The convergence David describes is real, but it’s not new.

Twenty years ago, product managers didn’t need to understand SQL. Then data became central to product decisions and suddenly “product analytics” became a core PM competency. The role absorbed what used to be analyst work.

Fifteen years ago, PMs didn’t do design work. Then prototyping tools got accessible and suddenly understanding UX patterns became essential. The role absorbed some of what used to be design work.

Now AI tools are making technical exploration accessible. The pattern is consistent: when tools lower the barrier to entry for adjacent skills, role boundaries shift.

What concerns me is the speed of this shift.

Previous role expansions happened over years. This one is happening in months. That compression creates risks:

• People overestimate their competence in new domains (Dunning-Kruger at scale)
• Organizations reduce specialist headcount before generalist skills mature
• Quality control mechanisms haven’t adapted to new workflows

At the executive level, I’m watching how we structure teams for this. The old model of clear handoffs between functions is breaking down. But we haven’t yet built the new model of how these expanded roles collaborate.

My current hypothesis: The PM role is becoming the “integration layer” of the product organization - someone who has working knowledge across engineering, design, data, and go-to-market, but deep expertise in none. That’s valuable if properly positioned. It’s dangerous if it becomes an excuse to cut specialists.

Luis’s point about operating agreements is critical. The clearer we are about what collaboration looks like in this new world, the less likely we are to lose what made specialization valuable in the first place.

What I’d add: We need to be explicit that AI augmentation doesn’t equal AI expertise. A PM who can query a codebase with Claude is not a PM who should make architecture decisions. The tool extends reach, not judgment.