The “AI PM” Gold Rush and the Skills Inflation Problem

Everyone is an “AI PM” now. The title commands a significant salary premium, and cutting-edge startups are falling over themselves to hire people who can claim it. But there’s a gnawing question underneath the hype: how many of these PMs have actually built and shipped production-level agentic products, complete with harnesses, evals, and full observability?

The honest answer is: very few. What we’re seeing instead is a credentialing arms race where the interview process has become the proxy for competence that doesn’t yet exist in the market.

Here’s the uncomfortable dynamic playing out in hiring loops across the industry: because there are no established criteria for what makes a great AI PM, interviewers have defaulted to engineering skills as the measurable signal. System design questions, LLM prototyping exercises, and architecture deep-dives have become the new screening mechanisms, not because they predict PM success, but because they’re easier to evaluate than product judgment.

This is how you end up with PM candidates being asked to design distributed systems that would challenge senior engineers.

Why the Interview Bar Got Absurdly High

The market is trying to collapse roles to pay for token fees. That’s the cynical read, and there’s evidence to support it. AI-native startups burn through cash at alarming rates, and hiring a PM who can also prototype with LLMs means one headcount doing the work of two. The economics are compelling, even if the role design is questionable.

But there’s a more charitable interpretation: AI products are genuinely different. When you’re building agentic systems, the product decisions and the technical decisions are inseparable. The eval strategy is a product decision. The choice of model, the context window management, the tool-use architecture, these aren’t implementation details a PM can hand off to engineering and forget about. They’re core to the user experience.

A PM who’s never built anything with LLMs is essentially flying blind when it comes to understanding what’s actually possible.

The System Design “Requirement” Is a Distraction

Here’s where I part ways with the hiring managers demanding PMs crush system design interviews. The systems design framework that dominates technical interviews in 2026 has drifted far from what PMs actually need.

System design interviews now expect candidates to understand the major architectural paradigms shaping modern systems, microservices, event-driven architecture, serverless, distributed systems. The interview framework has evolved to test four dimensions: problem scoping and requirements, high-level design, deep dive and technical depth, and trade-off reasoning.

That’s a meaningful shift from the old days of drawing boxes and arrows. Modern system design interviews are less about memorizing components and more about reasoning through constraints. But there’s a critical mismatch: these interviews are designed to evaluate engineers for engineering roles, testing skills like sharding strategies, CAP theorem trade-offs, and fan-out problem solutions.

Is this what a PM needs to know? Let’s think about what a PM actually does with technical knowledge.

The Eval Problem: Where the Technical Bar Is Legitimate

One area where the technical bar is completely legitimate: AI evals. This is the skill that separates real AI PMs from people who just say “AI PM” on LinkedIn.

You cannot build a credible AI product without running evaluations. The problem is that a lot of people are generating 100-200 test outputs, doing a quick eyeball scan, declaring “looks good to me”, and calling it rigorous analysis. That’s not an eval, that’s a vibe check with extra steps.

A real eval strategy requires understanding sampling, statistical significance, edge cases, and failure modes. It requires knowing what metrics matter for your specific use case and how to measure them reliably. This isn’t system design, but it is deeply technical, and it’s directly relevant to the PM role.

The pushback from some quarters is that PMs shouldn’t be responsible for evals at all, that should be owned by data scientists, with the PM being consulted and informed. And for larger organizations, that’s probably right. But in an AI-first startup, where the PM needs to iterate quickly on prompts, context design, and tool choices, having hands-on eval experience is non-negotiable.

The weird shift has been when PMs build the models themselves, blurring the lines between product and data science. That’s not engineering creep, that’s role confusion, and it’s problematic.

The Feature Factory PM Is Going Extinct

The uncomfortable truth underneath all this debate: if your entire PM value proposition is reading epics and writing PRDs, you should be worried. Not because system design interviews are coming for you, but because that work is becoming automatable.

If your job is finding out how to change a system to add a feature, you’ll probably still have a job. If you’re actually adding value above process management, making sure things are on time and devs know what leadership asked for, you’ll still be needed. But if you’re just following a checklist, the epic says x, y, z so you add those features, make sure they have tracking, and relay UX’s requirements to the dev team, that can be automated.

The emphasis on process over product has been a problem for fifteen years. Interviews that focus on product frameworks, terminology, cycles vs sprints, JIRA management, and “what makes a good epic” are testing things that have nothing to do with making products people want to use and monetizing them. The PMs who thrive in the next decade are the ones who can decide what to build, in what order, and why, not the ones who are superbly organized.

What the Right Technical Bar Actually Looks Like

So where should the line be? The market has clearly decided that a PM who can’t engage with technical details is a liability in an AI-first world. But the market has also created an interview gauntlet that excludes candidates who would be excellent PMs but aren’t engineers.

Here’s my take on the right technical bar for AI PMs:

The distinction matters because the skills that make someone a great PM, user empathy, product judgment, prioritization, are not the same skills that make someone a great system designer. Asking a PM to master both is asking them to do two full-time jobs, and you’ll get mediocre results at both.

The Way Forward: Specialized Technical PMs

Andrew Ng recently pointed out that product managers and designers are gaining AI engineering skills and participating in building software. This role blurring isn’t inherently bad, it’s how software development accelerates when people who understand product can also shape the build.

But there’s a difference between being able to shape the build and being expected to build the whole thing. The companies that figure this out will create specialized technical PM roles that sit at the intersection of product and engineering. These are the people who can translate between the two worlds, who deeply understand both the user problem and the technical solution space.

These aren’t generic PMs with some technical awareness. They’re hybrid roles with a clear mandate: the product decisions for AI systems are too technically entangled to be made in isolation from the implementation.

The companies that don’t figure this out will keep running interview loops that conflate engineering ability with product competence. They’ll hire people who can pass technical screens but lack product judgment, or they’ll exclude great product thinkers who haven’t spent six months memorizing system design frameworks.

The Real Question Behind the Interview Debates

The system design interview requirement for PMs isn’t really about system design. It’s about the market struggling to evaluate a new kind of role that doesn’t fit existing categories.

We’re all groping toward the same insight: AI products require a PM who can think technically. The gap between “understands technology” and “can pass a technical interview” is where the confusion lives.

The companies that win will be the ones that define the technical PM role deliberately, building interview processes that test prototype thinking, eval judgment, and technical fluency without demanding SWE-level system design skills. The companies that lose will be the ones that outsource their hiring standards to a generic system design framework that was never designed to evaluate product thinking.

If you’re a PM preparing for interviews, don’t spend six months grinding system design frameworks. Spend that time building AI prototypes, running actual evals, and learning to reason about what’s technically possible. Those skills compound. The system design interview framework is a snapshot that becomes obsolete quickly, and if you’re interviewing at a company that demands it, that tells you something about how they’ll treat the PM role once you’re inside.

The best preparation is producing the work that the AI PM role actually requires. Everything else is just credential theater.