There’s a pattern I’ve been watching play out across product teams in the last year or so, and it’s uncomfortable to talk about because most PMs don’t want to admit it’s happening to them.
Engineers are walking into roadmap conversations with AI-generated competitive analyses, user research summaries, and draft PRDs and they’re doing it in two hours. Meanwhile, the PM is still waiting on a synthesis doc from three stakeholder interviews done two weeks ago.
Nobody says anything. But the room notices.
The job hasn’t changed. The speed expectation has.
Product management was never really about writing documents. It was always about clarity, helping teams understand what to build, why, and for whom. The documents were just the artifact of that thinking.
What’s shifted is that the thinking now needs to happen faster, and it needs to be more continuously updated. A PRD that takes four days to write is already partially stale by the time it circulates for review. A competitive landscape doc that required three days of research is now something a PM with the right setup can refresh in forty minutes.
That’s not a small operational change. It’s a fundamental shift in what “doing PM work well” looks like.
I spent a while trying to keep up by just working faster: more tabs open, more notes, more time. It didn’t work. The problem wasn’t effort. It was that I was still doing the same cognitive steps, just faster, while others had removed steps entirely.
What actually changed when I started using AI properly
The first place I noticed a real difference was user research synthesis. I’d come out of five user interviews with pages of notes, recordings I hadn’t fully reviewed, and a vague sense of the themes. Turning that into something a design team could actually use took me most of a day, sometimes more.
Once I started using AI to help structure the synthesis, feeding in cleaned-up transcripts, asking it to pull themes, contradictions, unresolved questions, the output wasn’t perfect. But it gave me a skeleton in twenty minutes that I could actually critique and reshape. The PM thinking still happened. The manual assembly work didn’t.
The second area was PRD drafting. Not writing the PRD with AI, that produces something generic and unconvincing, but using it to stress-test assumptions. I’d write a section on the problem statement and then ask: what edge cases am I not accounting for? What would an engineer push back on here? What’s the weakest assumption in this logic? The responses pointed me at things I’d glossed over.
A few months into be10x’s AI Career Accelerator, there was a module specifically on building AI workflows for knowledge work, the kind of stuff that doesn’t fit neatly into “automate this task” but is more about changing how you think through problems. That reframe was more useful than any specific tool tip.
The roadmap problem
Here’s where it gets more complicated.
Roadmap prioritization is still genuinely hard, and I’m not sure AI helps with the actual decision. It helps with the inputs. Getting a quick summary of what competitors shipped last quarter, synthesizing support ticket themes into feature signals, drafting the one-pager for a new initiative, all of that moves faster.
But the judgment call about what to build next? That’s still you. And actually, I think the PMs who over-rely on AI for prioritization end up producing roadmaps that feel correct on paper but don’t reflect the weird, political, context-specific reality of their company. AI doesn’t know that your VP of Sales promised a customer a feature last Tuesday. It doesn’t know that the engineering team is exhausted from the last quarter and a technically complex initiative right now would break morale.
That context lives in your head. The AI accelerates the work around it, not through it.
What the influence shift actually looks like
I want to come back to what I said at the start, because I think it’s easy to read it as competitive anxiety and dismiss it.
It’s not really about engineers vs PMs. It’s about the fact that in 2026, the people who can quickly produce high-quality, well-reasoned artifacts, briefs, analyses, specs, proposals, are pulling more decision-making weight. That used to be a PM’s natural territory, because PMs had the time and process to produce those things.
Now anyone on the team can produce a reasonable first draft of almost anything in an hour. The differentiation is no longer “who can write the doc.” It’s “who has the sharpest thinking, the most context, and the judgment to make the AI output actually useful.”
That’s still a PM skill. But you have to actually develop the AI layer underneath it, not as a novelty, but as a real part of how you work.
One thing I’d tell a PM who hasn’t started yet
Don’t start with prompting tips. Start with one painful recurring task, the one you dread every week, and figure out how to do it differently with AI assistance.
For me that was meeting prep. I was spending forty minutes before every stakeholder sync reviewing context, re-reading old docs, trying to remember where things stood. I built a simple workflow using Fireflies for transcription and AI for summary and open questions, and now I walk into those meetings having spent ten minutes instead of forty.
It didn’t transform my entire job. But it freed up enough mental energy that I could spend more time on the things that actually require a PM to be present and thinking.
That’s the real shift. Not automation. Reallocation.
