There Are Now 3 Types of PMs in AI Companies: Which One Should You Hire?

When you hired a PM for your AI product, which of these three people did you think you were hiring?

Someone who decides how AI shows up inside the product your customers touch. Someone who builds the infrastructure other teams use to ship AI features at all. Or someone who's just a good PM, full stop, who happens to use AI tools to move faster than everyone else.

Most founders can't answer that question cleanly. That's fair. The job title hasn't caught up to the job yet. "Product Manager, AI experience required" is currently doing the work of three different postings, and almost nobody has noticed. I've operated across all three modes over the past two years, and the confusion isn't academic. It shows up in job posts, in interviews, and six months later, in roadmaps that don't make sense for the team that's actually staffed.

The Taxonomy

AI Product PM. This person owns how AI shows up inside the thing your customer uses. Their week is spent on output quality: is the model's answer good enough to ship, and what happens when it isn't. They're deciding how much confidence to show the user, when the product should defer to a human, and what the failure mode looks like when the AI is wrong in front of a paying customer. If your product has a chat interface, a recommendation engine, or anything generating content a user reads, this is the PM shape you need.

AI Platform PM. This person doesn't touch the customer-facing product much at all. They build what the other teams build on top of: eval pipelines, the internal tooling that tells engineering whether a model change made things better or worse, the API contracts between the AI layer and everything else. Their week looks like latency budgets, cost-per-inference tradeoffs, and arguing with an infra team about where the vector database lives. If you're building the muscle that lets five product teams ship AI features without each of them reinventing evaluation from scratch, this is who you need.

AI Powered PM. This is the one people forget to name, because it's the least visible. This is a traditional PM, writing specs, running discovery, prioritizing a backlog, who's just faster and sharper because they're using AI tools well. Their product might have nothing to do with AI at all. Their week looks like any PM's week, except they're drafting specs in Claude, running synthetic user interviews before real ones, and shipping in half the cycle time. Hire this person if what you actually need is a good PM, not an AI specialist.

There's a fourth zone worth naming: the overlap. A PM who sits at the intersection of two circles, say, someone who can define AI Product decisions and understands the platform constraints well enough to not propose something infeasible, is rare, and worth paying for. Most companies don't need that person on day one. Most companies think they're hiring that person and get one circle instead.

Where Hiring Breaks

Here's the scenario I've watched play out more than once. A founder posts "Senior PM, AI experience required." Three candidates apply. All three have shipped AI features. All three interview well. All three are wrong for two of the three roles the founder actually has open.

Hire an AI Product PM into what's really a Platform role, and six months in they're frustrated they're not touching the customer experience. They're stuck writing internal documentation for eval criteria nobody outside engineering reads. Hire an AI Platform PM into a Product role, and you get beautifully engineered infrastructure with no customer-facing story: technically excellent, commercially invisible. Hire an AI Powered PM expecting AI-native product instincts, and you get a very good, very fast PM who ships a perfectly reasonable non-AI feature roadmap, because that's genuinely what they're good at. It's just not what the AI product needed.

The candidate didn't lie on their resume. The founder didn't ask the wrong questions on purpose. The job post collapsed three roles into one line, and nobody caught it until the team was three months into building the wrong thing.

How to Actually Interview for the Difference

If you're hiring, ask questions that separate the archetypes instead of confirming "AI experience" in general.

For the Product PM candidate, ask them to walk you through a time they decided not to show the AI's output to the user. This surfaces whether they think about failure modes and trust, or just about capability. For the Platform PM candidate, ask how they decided when a model change was ready to ship to other teams. This surfaces whether they've actually built evaluation infrastructure, or just consumed someone else's. For the Powered PM candidate, ask what task they used to do manually that they've now handed to an AI tool, and where that went wrong the first time. This surfaces whether they've genuinely integrated AI into their own workflow, or just added a line to their resume.

A candidate who answers all three well is the overlap hire. Rare, and you'll know it when you hear it. A candidate who only answers one well just told you which circle they actually belong to.

The Cost of Getting This Wrong

The wrong hire here doesn't just slow the team down. It misaligns product strategy at the architecture level, because the PM you hired is making decisions about what gets built, and if their instincts live in the wrong circle, so does your roadmap. A Platform PM making Product-shaped decisions will under-invest in the failure-mode UX your customers actually notice. A Product PM making Platform-shaped decisions will under-invest in the evaluation infrastructure that keeps the whole thing from quietly degrading.

Before you write the next job post, decide which circle you're actually hiring for. The title won't tell you. The interview questions above will.

Scaling your product team? We help founders figure out exactly this: what kind of PM ownership their product actually needs. Let's talk.