The AI landscape for PMs - what you actually need to know

There's a version of AI adoption that looks like this: you use ChatGPT to write your PRDs faster, summarise your meeting notes, and clean up your emails. Everything gets done quicker. The job stays the same.

That version is fine. It's also not what this site is about.

What's actually happening in product right now is more significant than a productivity upgrade. The way products get built is changing structurally, and the PM role is changing with it. Understanding why requires stepping back from the tools for a moment and looking at what's actually shifted.

The old model

The PM job has always had a core function: translation.

You talked to customers, synthesised what you heard, turned it into specifications, and handed those specs to engineers who built the thing. You were the bridge between the problem and the solution. The value you added lived in that translation layer.

This worked because implementation was hard and slow. Writing code took time. Getting things built required careful coordination between people with different skills. The spec existed because there was a meaningful gap between "knowing what to build" and "having it built", and someone needed to manage that gap.

What's changed

That gap is collapsing.

AI agents can now take a well-formed problem and produce working software, functional prototypes, or production-ready code in minutes. The time between "I know what we should build" and "here it is" has compressed from weeks to hours in many cases, and it's still shrinking.

This is not just a speed improvement. It's a structural change to where the bottleneck actually sits.

When implementation was slow, the bottleneck was engineering capacity. Getting things built was the hard part. PMs existed partly to queue and prioritise that capacity, to make sure the right things got built in the right order.

When implementation is fast, the bottleneck moves upstream. The scarce resource stops being engineering time and becomes something harder to automate: knowing what's actually worth building, and being able to articulate it precisely enough that agents can act on it.

That's the shift. And it changes the PM job in ways that go well beyond using better tools.

Why doing the same things faster isn't enough

Here's the trap most PMs fall into with AI: they use it to accelerate the existing workflow. Faster PRDs, quicker research summaries, cleaner documentation. The process stays the same, just with less friction at certain points.

This is understandable. It's the obvious first use of any new tool. But it misses what's actually available.

The PMs who are getting the most out of this shift aren't using AI to write their specs faster. They're using it to collapse the distance between having an idea and having something real to evaluate. They're building working prototypes in an afternoon. They're running three different approaches to a problem in parallel, just to see which one feels right when they use it. They're getting real feedback on working software instead of presenting slide decks.

That changes your relationship to the product entirely. You're not describing what you want and hoping it comes back right. You're shaping it directly, in real time, and iterating on something concrete rather than something imagined.

The skill this demands is different from the skill the old model demanded. Writing a detailed spec for an engineering team is a different cognitive task from knowing how to direct an agent effectively. The first requires careful documentation of requirements. The second requires clarity of thought about the problem itself.

The three things you'll actually encounter

With that context in place, here's the practical landscape. Most of what PMs interact with falls into three categories, and understanding the difference between them changes how you use each one.

Chatbots

Tools like Claude, ChatGPT, and Gemini in their standard form. Conversational, single-turn or multi-turn, designed to respond to what you ask. Useful for thinking through problems, drafting and editing, synthesising information, and getting a second perspective on a decision.

The key thing to understand about chatbots is that the quality of what you get back is almost entirely determined by the quality of what you put in. A vague question gets a generic answer. A well-formed problem with real context gets something genuinely useful. This is why learning to give good context is the highest-leverage skill in working with these tools, and why it's the subject of the next article in this series.

Chatbots are where most PMs start, and they're genuinely valuable at this level. But they're only one layer of what's available.

Copilots

AI that's embedded directly into the tools you already use. GitHub Copilot inside your code editor. AI features inside Notion, Linear, or Figma. Writing assistance built into your email client.

Copilots are assistive by design. They work alongside what you're already doing rather than operating independently. They're lower friction than chatbots because you don't have to switch context, but they're also more constrained. They operate within the boundaries of the tool they're embedded in.

For PMs, the most relevant copilots right now are the ones embedded in AI-native editors like Cursor and Windsurf, which give you AI assistance across the entire process of building something, not just writing code.

Agents

This is where the structural shift lives.

Agents don't just respond to your questions. They take a goal and pursue it across multiple steps, making decisions along the way, using tools, and producing outputs that would have previously required significant human effort and coordination.

Give an agent a well-formed problem and it will research, prototype, iterate, and produce something concrete. It doesn't need you to break the task down into steps. It doesn't need you to manage the handoffs between different parts of the work. It needs you to be clear about what you want, what the constraints are, and what good looks like.

That last sentence is the whole game. Agents are powerful in direct proportion to how clearly you can direct them. The PM who can give an agent rich context, a well-formed problem, and precise success criteria will get dramatically better output than one who gives vague instructions and hopes for the best.

This is why the core skills of the AI-native PM aren't technical. They're the skills that have always mattered in product: deep understanding of the problem, clear thinking about what good looks like, and good judgment when evaluating what comes back.

The mental model worth having

Think of it as three levels of AI integration, each unlocking something the previous one doesn't:

Most PMs are at level one. The toolkit on this site is built to help you move to levels two and three, not by learning new technology, but by developing the PM skills that make agents genuinely useful.

What this means practically

You don't need to learn to code. You don't need to understand how large language models work. You don't need to become a technical PM if you weren't one before.

What you need is clarity. Clarity about the problem you're solving, the person you're solving it for, what you've already tried, what the constraints are, and what good looks like. Give an agent that information and it can do a significant amount of the work. Withhold it and you'll get generic output that misses the point.

The rest of this series is about building exactly that capability: the mental models, the habits, and the practical workflows that let you direct agents well and evaluate what they produce.

Next up: how to pick the right tools without getting distracted by the wrong decisions.