The product manager skills we use to hire were built for a version of the job that no longer exists.
Not outdated in the way that job descriptions lag reality by a year or two. Structurally wrong: built on assumptions about what product work involves that agentic AI has already invalidated. Hiring committees know something is off, so they do the obvious thing: add new skills to the existing profile. AI literacy. Data storytelling. Strategic thinking. Ant Murphy writes: “As AI takes away the grunt work and administrative tasks, the emphasis on skills like product strategy increases.” The observation is fair. Piling more requirements on top of the same foundation misses the actual problem. The foundation selects for the wrong things.
What the old criteria were actually measuring
Stakeholder management. Delivery track record. Roadmap fluency. Cross-functional communication. These were never arbitrary. They emerged from a specific context: the PM’s primary leverage was getting other people to agree, prioritise, and execute. The job was coordination. The artefacts: PRDs, roadmaps, release notes. Coordination tools. Writing a clear spec meant you could align an engineering team. A strong delivery record meant you could move an organisation through uncertainty and out the other side.
Those criteria predicted performance because performance was coordination under those conditions. The PM who could hold a room, translate ambiguity into structure, and keep a backlog coherent was genuinely valuable. The artefacts were evidence of judgment, not a substitute for it.
Now what was once a differentiating skill is now infrastructure. Any PM with a capable AI assistant can produce a polished PRD. Research, synthesis, documentation: commoditised. The floor has risen so far that the old criteria no longer separate strong candidates from weak ones. They test something that is available for free.
What changes when half the job is system design
The shift to agentic AI is not primarily about tooling. It is about where the judgment sits in the work.
In the old model, a PM made decisions and then coordinated others to execute them. Judgment and execution were separated: the PM owned the former, the team handled the latter. In the agentic model, the orchestration layer becomes the product. The PM is not just deciding what to build. They are designing which decisions the system makes autonomously, which require human review, and what the handoff between them looks like. That is not a harder version of the old job. It is a different job.
McKinsey puts it this way: “The central question is no longer how to scale engineering capacity but how to allocate human talent where judgment and decision-making still matter.” That allocation question is now a first-order PM skill. Not a concern for engineers or architects. A product decision, made repeatedly, with real consequences when it goes wrong.
Most hiring processes do not test for this at all. They are still testing coordination, communication, and delivery track record. Excellent predictors of performance at a job that is rapidly ceasing to be the job.
Delegation judgment
The specific skill the old criteria miss is what I call delegation judgment: the ability to distinguish which decisions require human reasoning and which should be handled by an autonomous agent, and to design the handoff correctly.
Get it wrong in one direction and you hand accountability to something that cannot hold it: the agent acts, consequences land, and nobody in the loop understood the tradeoff. Get it wrong in the other and you have an expensive automation idling at human review speed. Delegation judgment is knowing which is which, and designing the boundary precisely enough that the system holds.
Isaac Avazquez frames the practical scope: “PMs who understand planning, tool use, memory, and interface design need enough depth to ask whether the workflow needs autonomy, whether tool definitions are robust, whether review points are in the right places.” That last phrase is the test. Review points in the right places. Not the wrong places. Not missing. Right.
That question does not appear in any interview loop I have seen. The interviews still cover how you handle a stakeholder who disagrees with the roadmap.
What to actually test for
Most senior PM roles now involve agentic systems. The standard interview process ignores three things.
First: can this person describe a decision they should not automate, and why? The answer reveals whether they think structurally about where human judgment belongs, or whether they default to automating whatever is technically automatable. Candidates who cannot answer this are not ready for agentic product work regardless of their AI literacy score.
Second: have they ever designed a review point in a system, and where did they put it? Not a theoretical answer. An actual decision they made, with a reason that goes beyond “because compliance said so.” The difference between managing artefacts and making the hard calls is visible in this answer. Artefact managers describe process. Judgment-holders describe tradeoffs.
Third: what failed because the handoff was wrong? A PM who has done this work has made mistakes at the boundary. If a candidate has never experienced a failure there, they have either never worked close enough to it or they are not telling you the truth.
The cost of not updating
Organisations that keep hiring to the old profile will find their PMs competent at coordination and lost when half the job is system design. The gap between what the role demands and what they were selected for will show up in the work. It will show up in the handoffs.
The industry keeps adding requirements to the PM job description without asking whether the description itself is selecting for the right things. The criteria were built for the last decade. The job is already somewhere else.
Leave a Reply