"AI PM" is not one job

Recently I did a serious round of research on the AI PM job market.

The reason is simple: “AI PM” has become far too broad a term.

All labeled AI Product Manager, some roles work with research teams to decide model capabilities, some build agent platforms, some are dedicated to evals, and for others the core job is bringing AI into specific industries like finance, healthcare and law.

If you just ask, in general terms:

what skills does an AI PM need?

you easily get an endless study list: Python, RAG, agents, MCP, evals, ML, system design…

But in real hiring, not every role needs these equally.

So this time I didn’t start from “what should an AI PM know,” but the other way round: who are companies actually hiring right now?

As of August 20, 2026, I put together 43 publicly open AI product roles.

They include AI-native companies like OpenAI, Anthropic and Scale AI, as well as roles at Box, Binance, Apple, Ford, n8n and companies in finance, insurance and healthcare, across North America, Europe, the GCC and Asia.

This isn’t a strict whole-market statistic. The 43 roles are a stratified sample meant to cover different companies and kinds of roles, so I won’t use it to infer “what percentage of the market falls into a given category.”

What I want to answer more is:

when a company writes the job title AI Product Manager today, what kind of person is it actually looking for?

Beyond the specific JDs, I also used reports like the Stanford AI Index 2026 and PwC’s 2026 AI Jobs Barometer to look at broader hiring trends; TrueUp was only used to help look at aggregate data on PM job volume, seniority and region, and played no part in the classification below.

This round of research ended up as four posts:

• this one: what different jobs “AI PM” actually covers
• the second: how technical an AI PM really needs to be
• the third: what new specializations like evals, harness and forward-deployed actually do
• the fourth: how a traditional PM can find their place in AI

Let’s start with the first map.

I didn’t sort by job title, but by “what this PM is actually responsible for”

This was an important shift while organizing the JDs.

Sort by title, and you see lots of:

AI Product Manager, Senior AI PM, Product Manager — AI…

and can hardly conclude anything.

But switch to a different question:

what product object is this PM really responsible for?

and the differences jump out at once.

In the end I roughly grouped them into seven kinds:

model capability → AI runtime platform → quality and risk → user applications → industry workflows → enterprise AI transformation → deployment at the customer

This isn’t an official industry taxonomy, just a practical map drawn from this batch of real roles.

Layer one: closest to the model

1. Model / research PM: working directly on model capabilities

This is the kind of PM closest to the model.

What they discuss isn’t only:

“what features do users want?”

But also:

what capability the model should strengthen next; what data training and post-training need; whether a certain model behavior is one we want; when a new capability is stable enough to release.

OpenAI has a Core Models PM.

In Anthropic’s hiring you can see finer-grained ones:

Research Product Manager, Model Behaviors, Claude Code Model Performance.

These roles usually also have the highest technical bar.

Search and recommendation, ML products, data platforms, AI infrastructure, even a research or engineering background, all become clear advantages.

So when a traditional internet PM looks at a JD like this and thinks:

how did AI PM become so much like ML?

it isn’t necessarily that the whole AI PM market has turned into this.

More likely you’re just looking at the kind of AI PM closest to the model.

2. AI platform / harness PM: responsible for the systems around the model

The model itself is really just one component.

To actually get an agent running, lots of other things need solving:

APIs, SDKs, tool calling, context, memory, permissions, sandboxes, retries, fallbacks, observability…

Things that used to be easily seen as “engineering implementation details” are now forming a product layer of their own.

OpenAI has PMs for API Agents and API Infrastructure.

Binance even has, outright:

Product Manager, AI Agent & Harness

Its responsibilities include agent task flow, capability boundaries, failure fallback, harness evaluation, as well as tool calling, RAG, MCP, multi-agent setups and more.

The natural backgrounds for these roles are usually:

developer tools, APIs, platforms, infrastructure, or PMs who have long worked on complex systems.

Their product object isn’t some chat interface.

It’s:

how to let other people build and run AI reliably.

3. Evals / safety PM: responsible for defining “is it actually good”

This was one of the kinds I found most interesting in this research.

Ordinary software is fairly easy to accept:

can the button be clicked; is the amount calculated correctly; did the endpoint return.

AI is much more trouble.

The same question can get a different result each time.

After a model version upgrade, one capability may improve while another regresses.

Average performance can be very good while still making serious mistakes in a few critical scenarios.

So:

“how to evaluate AI” has itself become product work.

Box now has a role literally called Product Manager, AI Evaluations.

This PM owns evaluation datasets, graders, offline / online evaluation, model selection, regressions, and which models can go into production.

OpenAI has a Safety Measurement PM, responsible for measuring harm in real usage, and whether safeguards are actually working.

A big difference from traditional QA is:

before testing starts, someone has to answer:

what counts as good? What errors are acceptable? What must absolutely never happen?

These are themselves product judgments.

Layer two: turning AI into a product people really use

4. Applied AI PM: responsible for whether users can actually get the task done

This is closest to most people’s intuitive picture of an AI PM:

copilots, assistants, agents, AI search, recommendations…

These PMs aren’t necessarily responsible for training models.

They care more about:

whether users can really get the task done; when the model can be trusted; when a person should take over; what happens after a failure; why users would keep using it.

So beyond DAU, conversion and retention, they increasingly look at:

task success, grounding, quality, latency, cost, fallback rate.

This is also the layer where traditional PMs most easily find a path across.

But it may also be the most crowded.

Because:

“has built internet products + can prompt” is no longer a particularly scarce combination.

What really sets people apart is whether they’ve taken an unstable model capability and made it into a product that:

can be measured, can fail, can recover, and can keep iterating.

5. Vertical AI PM: responsible for how AI works once it enters a specific industry

Once AI really enters an industry, domain knowledge becomes valuable again.

• A healthcare agent can’t just “sound like a doctor”;
• a finance agent can’t casually execute irreversible operations;
• legal products have to consider evidence, citations and responsibility;
• a cyber agent has to know which tools it may call and which actions a person must confirm.

So you can already see:

Healthcare AI PM, Legal AI PM, Cyber AI PM, Insurance AI Product Owner.

These roles don’t necessarily need “the person who knows the most about models” most.

Sometimes what the company needs more is:

someone who really knows where things most easily go wrong in this industry.

And then turns that industry knowledge into:

permissions, approvals, HITL, eval cases, audit trails, risk metrics.

At this point, industry experience isn’t just a line on a résumé:

“familiar with finance / healthcare / law.”

It directly changes how the system is designed.

Layer three: really putting AI inside a company

6. AI transformation PM: responsible for how a company should actually use AI

There’s another kind of role that isn’t responsible for any single AI feature.

What they’re responsible for is:

which of the company’s dozens of AI ideas are actually worth doing;

which to buy and which to build;

which to pilot first;

how to connect them to existing systems;

how to govern data and permissions;

whether employees actually adopt them;

and whether there’s real ROI in the end.

These roles might be called:

AI Transformation PM, AI Product Owner, Internal AI PM.

Their depth in model technology may not be as high as a core model PM’s.

But they depend heavily on:

breaking down processes, enterprise systems, governance, cross-functional collaboration and change management.

So the core question for these roles isn’t:

how smart is the model?

It’s:

has this company really changed how it works because of it?

7. Forward-deployed PM: going straight to the customer to build the AI there

This is a role I hadn’t paid particular attention to before, but after this research I think it’s well worth a look.

Scale AI is currently hiring a Forward Deployed Product Manager.

The job isn’t:

write the PRD → hand it to engineering → wait for launch.

It’s going deep with the customer:

understanding the problem; connecting data and APIs; building, testing and deploying together; then gradually abstracting one-off solutions into reusable software products.

So the role is a bit like:

PM + solutions architect + consultant + builder.

Both technical ability and customer skills are needed.

It also fits AI’s current stage as an industry:

demos aren’t that hard anymore.

What’s really troublesome is often:

how to connect AI into real business.

So the same “AI PM” can mean completely different profiles of talent

Put the seven kinds together, and you find:

• Model / research — how strong should the model get, and in what direction?
• Platform / harness — how can AI be built and run reliably?
• Evals / safety — what counts as good? When can it go live?
• Applied AI — can users actually get tasks done with AI?
• Vertical AI — how can AI be trustworthy and usable in this industry?
• AI transformation — where and how should a company use AI?
• Forward-deployed — how do you really deploy AI into a customer’s workflow?

These roles overlap, of course.

A healthcare agent PM might do applied AI, vertical AI and evals at once.

An agent platform PM might also be heavily involved in harness and evaluation.

But this map at least explains one thing:

why opening ten AI PM JDs makes it feel like they need completely different skills.

Because they’re hiring different people to begin with.

So when I look at AI PM JDs now, I first look at four things

rather than the job title.

1. What product object is this PM actually responsible for?

The model? A platform? Evals? An agent? An industry workflow? Enterprise deployment?

2. How close are they to the model and the system?

Is understanding the capability boundaries enough, or do they need to run experiments, write Python and build pipelines themselves?

3. Why does the company need this PM?

To improve model quality? To ship AI? To lower risk? To drive enterprise adoption?

4. What counts as success?

Model quality? Task success? Customer adoption? Cost? Safety? ROI?

Once these four questions are answered, two roles both called AI Product Manager may hardly be the same job anymore.

So from the first post of this research, the one simple judgment I most want to leave is:

don’t rush to ask “what does an AI PM need to know.”

First ask: which kind of AI PM am I talking about?

The next post will dig into a more practical question:

how much do these seven kinds of AI PM differ in what they require technically?

Part 1/4 of the series “Who is hiring AI PMs right now.” The research is based on 43 public AI product roles collected as of August 20, 2026, with reference to the Stanford AI Index 2026, PwC’s 2026 AI Jobs Barometer and other sources; TrueUp was used only to add aggregate information on PM job volume, seniority and region. The seven kinds are a qualitative grouping of responsibilities and don’t represent the proportion of roles across the market.