The AI Product Manager
"AI PM" gets used three different ways, and that ambiguity causes real confusion in hiring and in career planning. Let me untangle it, because which AI PM you mean changes everything about the skills, the role, and the comp.
#The three-way taxonomy
| Type | Who | What they build |
|---|---|---|
| AI-Powered PM | Every PM | Anything at all; they just use AI as a force multiplier across the job |
| AI Product Manager (specialist) | A growing minority | Core AI products and model-facing experiences (think OpenAI, Anthropic) |
| AI Feature PM | A fast-growing middle | AI capabilities bolted onto an existing product |
The framing I find clearest, echoed by Product School and Aakash Gupta, is that every PM is becoming an AI-powered PM, but not every PM becomes a specialist. The first row is the baseline, and it's really the whole rest of this domain. This note is mostly about the other two: the people whose product is the AI itself.
#AI product sense ≠ product sense
The core idea here is Aakash Gupta's, and it's worth sitting with: AI product sense is not the same as product sense. Regular product sense asks what we should build for the user. AI product sense keeps that question and adds two more that a SaaS PM never had to ask.
- Need. The classic question: what does the user actually want? (Product Sense and Judgment)
- Model behavior. What can the model reliably do, given that it's probabilistic and lives on a jagged frontier?
- Economics. At what inference cost and latency does that capability make business sense? (The Unit Economics of AI)
The whole thing collapses into a single question: what can AI reliably do, at a cost that makes sense? A SaaS PM gets to ignore the middle and right terms. An AI PM doesn't, because that's exactly where the product lives or dies.
#What an AI PM actually owns
Beyond the normal PM scope, an AI PM is on the hook for a few things that never show up on a traditional job description.
- Model behavior. The product is non-deterministic, and managing that is the job (Designing for Trust and Probabilistic Systems).
- Evals and quality. Defining what "good" means and then defending it (Writing Evals for AI Products).
- Economics. Token spend, latency, concurrency, margins (The Unit Economics of AI).
- The build-decision ladder. Prompt vs context vs RAG vs fine-tune, and the trade-offs of each.
- Data flywheels. Designing the loop where usage produces the feedback that improves the model.
None of this replaces the twelve competencies. It sits on top of them. An AI PM who can't run discovery or influence stakeholders is just a PM who's bad at the job, now with extra steps.
#The job market, directional only
Directionally: AI PM roles are estimated at roughly 20% of PM openings, and they tend to pay 20 to 40% more than the equivalent non-AI role. OpenAI PM comp on Levels.fyi spans a very wide band, with figures in the $300K to $950K+ range getting cited. All of this is directional. The market shifts monthly, definitions vary, and a Levels.fyi datapoint is one self-reported snapshot, not a salary you're owed. There's also a real force pulling the other way: 2026 headcount pressure from the sheer cost of compute. Read these as evidence the specialization is valued, and nothing more precise than that.
#My take on the career question
You don't have to become a specialist. You do have to become AI-powered, because that part isn't optional anymore. Whether to go deeper into the specialist track is really a shape question. Do model behavior, evals, and economics energize you, or are they a tax you'd rather not pay? Both answers are legitimate. Pretending you can skip AI literacy altogether is the one that isn't.
#Continue Reading
- Building AI Products for what the specialist does day to day.
- Writing Evals for AI Products for the skill most central to the role.
- The Unit Economics of AI for the economics half of AI product sense.
- Product Sense and Judgment for the foundation AI product sense builds on.
- The PM Competency Model for the twelve competencies the role still rests on.
- Designing for Trust and Probabilistic Systems for managing model behavior in production.