What I actually look for in an AI PM

I’ve read a lot of AI PM job descriptions this year, and most of them are a list of nouns. LLMs, RAG, vector databases, agents, evals, a framework or two. Then somewhere near the bottom, in smaller type, the actual job.

The nouns are the easy part to write — and the least useful part to screen on. They also date fast enough that a description written eighteen months ago reads like a museum piece.

Here’s what I think the role actually is, and what I’d test for.

The market is hiring for ownership, not support

Some context first, because it changes who you should be writing the description for.

Axial Search analysed 12,397 AI product roles posted in the US since January 2026. 47% are Manager-level and roughly another quarter are Director-level, with junior and mid-level individual contributor roles rare. 41% come from companies with 10,000 or more employees. Technology posts about a third, Financial Services another 13%.

Three caveats before anyone builds a plan on that. It’s US-only, and I work in Europe, so I treat the shape as indicative and the geography as irrelevant to me. The requirement figures are mention rates — the share of postings that state something — so a skill not appearing means it wasn’t written down, not that nobody wanted it. And Axial Search is a recruiting firm publishing research about hiring, which doesn’t make the postings data wrong, since job ads are job ads, but useful to know who is counting.

With those caveats, the shape is clear. You’re hiring into a market that wants owners, mostly inside large organisations that already have engineers. So the scarce thing isn’t the ability to build. It’s the ability to decide.

The data agrees, which surprised me

I expected the postings to over-index on technical nouns, because that’s what the descriptions feel like when you read them one at a time.

Axial’s framework analysis lands somewhere else: judgment rather than delivery is what separates the leaders employers compete for, with use case selection and AI literacy topping thirteen capabilities, well ahead of hands-on execution.

The tool mentions support this. Agile appears in 12% of AI product postings, foundation models in 8%, observability in 8%, cloud platforms in 6%. Those are low numbers for things that dominate the discourse. Fluency across the stack matters more than depth in any single tool.

So the nouns are in the job descriptions, but they’re not what the market is actually competing over.

The structural thing that makes this role different

There’s a real difference between this job and product management generally, and it isn’t the tooling. It’s that you’re managing probabilistic systems whose behaviour drifts over time rather than fixed features.

That one sentence reorganises the job. A feature you shipped in March behaves the same in September. A model you shipped in March may not. So your success metrics have to survive drift. Your expectations have to be ranges rather than promises. And somebody has to own the question of how you find out when it degrades.

Who finds out when it degrades, and how? Most candidates have never thought about it. It’s the single most revealing thing to ask about.

What I screen for

Can they say no to a use case? This one predicts everything else. I want to hear about something they decided not to build with AI, and why they decided it. A project cancelled by someone above them doesn’t count; it has to be a call they made. Anyone who has shipped AI in a real organisation has killed something. If they haven’t, they have either not shipped or they aren’t the one deciding.

Do they know what a wrong answer costs? I ask what happens when the system is confidently wrong. The weak answer describes what the model does. The strong answer describes what the person on the other end does, and whether they would notice. I’ve written before about how human oversight becomes a fig leaf when nobody has thought this through.

Can they define a good answer on your data? Not a benchmark. What does correct look like for this specific task, who decides, and how would you know six months from now if it stopped. Candidates who have genuinely done this get specific fast. Candidates who haven’t reach for a framework.

Do they understand the regulatory position? Not in detail, and I don’t expect a lawyer. I want them to know whether their company is the provider or the deployer of a given system and why that changes what they owe. It takes one question and it separates people who have shipped in a regulated environment from people who have read about it.

Can they size the thing? What is this worth if it works, and what happens if we do nothing? This is ordinary product work and it remains the most commonly skipped step, and that’s why I gave it its own article.

Are they honest about what they didn’t do? AI projects have a lot of contributors and it’s easy to narrate a team outcome in the first person singular. I ask what the data scientists changed their mind about. People who were actually in the room can answer immediately.

What I don’t screen for

Whether they can fine-tune anything. If you need that, you’re hiring an ML engineer and calling it a PM job. That’s one of the ways this role gets miscalibrated.

Certifications. Hands-on ML product experience beats credentials, and I’ve never seen a certificate predict anything.

Prompt craft. It’s real, it’s learnable in a fortnight, and it isn’t a hiring signal.

Which frameworks they can name. A framework explains a decision after you have the judgment to make it. It won’t give you the judgment.

If you’re writing the job description

Cut your noun list to three genuinely non-negotiable things. Then describe a decision this person will face in their first quarter, and ask candidates how they’d approach it. You’ll learn more from that than from your entire skills section. You’ll also attract people who want to own something, rather than people who pattern-match to keywords.

The role is miscalibrated often enough to justify the extra hour. Founders already confuse technical, growth and strategy PM profiles, and adding AI compounds the problem.

If you’re the candidate

Have the no ready. The use case you killed, why you killed it, and what you did instead. In my experience it’s the answer that changes the temperature of the conversation, because almost nobody arrives with one.

Common questions

What skills matter most for an AI product manager?

Judgment rather than delivery. In Axial Search's analysis of US AI product postings, use case selection and AI literacy rank at the top of thirteen leadership capabilities, well ahead of hands-on execution. Tool mentions are comparatively rare: Agile appears in 12% of postings, foundation models in 8%, observability in 8%, cloud platforms in 6%.

Do AI product managers need a certification?

No. Hiring managers consistently value hands-on ML product experience over credentials, and no certification is required for the role.

How is an AI PM different from a regular product manager?

The systems are probabilistic and their behaviour drifts over time rather than staying fixed. That changes how success metrics are defined, how expectations are set with stakeholders, and it adds an ownership question most product roles don't have: who finds out when performance degrades, and how.

What seniority are AI product roles hiring at?

Predominantly senior. Across 12,397 US AI product postings since January 2026, 47% were Manager-level and roughly another quarter Director-level, with junior and mid-level individual contributor roles rare. 41% came from companies with 10,000 or more employees.

What is the best interview question for an AI PM?

Ask about a use case they decided not to build with AI, and why. Anyone who has shipped AI inside a real organisation has killed something. If they can't name one, they either haven't shipped or were not the person deciding.

Should an AI PM be able to build models?

No. If the role genuinely requires model development you're hiring an ML engineer with a product title, which is one of the common ways this role gets miscalibrated during hiring.

How do you write an AI product manager job description?

Cut the technology list to the three items that are genuinely non-negotiable, then describe a real decision the person will face in their first quarter and ask candidates how they would approach it. The skills section attracts keyword matches; the decision attracts people who want to own the problem.

What should an AI PM candidate prepare for an interview?

A use case you decided not to build with AI, why you decided it, and what you did instead. Very few candidates arrive with one, and it demonstrates ownership more directly than any project description.

Is prompt engineering an important AI PM skill?

It's real and it is learnable in about two weeks, which makes it a poor hiring filter. The same applies to naming frameworks. A framework explains a decision after the judgment exists; it doesn't substitute for it.