The Skills Are Not the Job

Every PM team I know is busy automating the wrong things.

There is a pattern in PM communities right now, and it is accelerating. PMs are sharing their AI skills: reusable prompts that pull roadmap status from Jira, Claude integrations that summarize customer tickets from Intercom, MCP servers wired into Aha, Outlook, and Slack so the AI can draft release notes, PRDs, and GTM briefs before you have written a sentence. There are newsletters, bloggers, GitHub repositories, and links you probably should not download from.

I understand the appeal. The work is real, the demos are impressive, and the people building them are smart and motivated.

But I keep asking the same question, and almost nobody has a good answer.

The question nobody seems eager to answer is simple: what did you do with the time you got back?

If the answer is more of the same, faster, you are not becoming a better product manager. You are becoming a more efficient one. Those are not the same thing.

The point of AI in product management is not to empty your calendar. It is to buy back time for judgment work that only you can do.

What the shortcuts are actually automating

Look carefully at what is actually being automated. Pulling the status of features in flight. Comparing capabilities across products. Researching what is on the roadmap and why. Summarizing what customers have been asking for.

The mental model underneath is that the PM's job is information retrieval, and AI makes retrieval faster.

That is not wrong. It is just not the job.

When I transitioned from medicine to product management, one of the first things I noticed was how similar the conversations felt. A patient describing symptoms and a customer describing a problem are doing the same thing: trying to articulate something they experience but cannot fully name. In both cases, your job is to listen past what they say to what they mean, identify the real source of the pain, evaluate its severity against everything else competing for attention, and decide on a path forward. A transcript of an office visit does not contain a diagnosis. A summary of a customer meeting does not contain a product decision. Those are judgment calls, and they sit on top of the information, not inside it.

These are information retrieval tasks. They are not judgment tasks. A skill that tells you what customers asked for last quarter does not tell you which customers to believe, which signals to act on, or what tradeoff you are accepting when you choose one over another. A prototype built in an afternoon does not tell you whether you are solving the right problem.

The information retrieval problem in product management was always real. It was slow, tedious, and error-prone. AI is genuinely solving it. That is a good thing.

The judgment problem in product management was also always real. AI is not solving it. And the PMs spending their reclaimed time building more skills are not solving it either.

To see why this matters, you have to look at what agentic AI actually demands from a PM.

What agentic AI actually requires from a PM

I have spent the last two years writing about agentic AI product management, and the honest version of that work does not look like the LinkedIn feed.

The first question in agentic AI is not how to build the agent. It is whether to build it at all. Most problems do not benefit from an agentic solution. Agents introduce probabilistic behavior, compounding error, and less explainability. A PM who cannot distinguish a problem that benefits from autonomy from one that requires determinism is not ready to ship an agentic product, regardless of how many MCP integrations they have configured.

If the problem does warrant an agent, the next question is where on the autonomy ladder it belongs. Full autonomy, supervised autonomy, human approval at each step: these are not implementation details. They are product decisions with legal, liability, and user trust implications. Getting them wrong is not a technical failure. It is a product failure. A PM who cannot tell the difference between approving a suggestion and delegating a decision is building something they should not be shipping.

Then there is the approval moment, the specific design of the interaction where a human reviews what the agent proposes and decides to accept, modify, or reject it. This is the hardest UX problem in agentic AI, because the cognitive load, the framing, the information density, and the time available all determine whether the human is actually in the loop or merely rubber-stamping outputs they cannot evaluate. Most teams skip this design problem entirely. They ship an approval button and call it human oversight.

Beyond that, there are at least three more problems most teams never fully define:

• The eval set: what does good output look like, what does failure look like, how do you measure the difference at scale, and who defines it.
• The cost analysis: AI inference is not free, the unit economics of an agentic workflow are not obvious, and a PM who has not modeled them does not know whether the product is profitable at the segments they are targeting.
• The boundary specification: what the agent is allowed to do, what it must refuse, and what happens when it encounters a case the designers did not anticipate.

None of this work is in the skill. None of it comes from vibing in Claude Code. All of it requires a PM who has thought carefully about what agentic systems actually do and what it means to be responsible for one.

The Excel argument

Skills and MCP integrations are tools. They belong in a PM's toolkit the same way Excel and Confluence belong there.

Excel made financial modeling faster. It did not make PMs better at deciding what to model, what assumptions to make, or what the model actually told them about the business. The PMs who got better at financial modeling were the ones who understood the business deeply enough to know what questions to ask. Excel just made the arithmetic faster.

Confluence made documentation easier to organize. It did not improve the quality of the thinking documented. The PMs who wrote better specs were the ones who understood the problem deeply enough to write clearly about it. Confluence just made it easier to share.

A skill that generates your weekly status update faster is Excel for status updates: useful, but it does not make you a better PM.

The question worth asking is not "what can I automate?" The question is "what should I be doing with the hours I just recovered?"

What good PMs are doing with those hours

The PMs I respect most in the agentic AI space are not the ones with the most impressive skill libraries. They are the ones who have gotten better at the judgment work that automation cannot touch. They can:

• Walk into a conversation with engineering and explain why the proposed agent architecture will degrade gracefully in some failure modes and catastrophically in others, and what the product implications of each are.
• Sit across from legal and explain what "human in the loop" actually means for this product, why the approval moment they designed satisfies that requirement, and what the liability exposure looks like if users learn to rubber-stamp outputs.
• Tell you, from the cost analysis they ran, what the margin looks like at ten thousand users versus a hundred thousand, and where the unit economics break.
• Define the eval set, explain the failure modes it catches and the ones it does not, and describe what degraded performance looks like in production before it becomes a customer complaint.

They can also answer the question I started with: what did you do with the time you got back?

The provocation, plainly stated

There is a version of AI-augmented product management that makes PMs faster at shallow work and leaves the deep work untouched. That version is appealing because the demos are good and the efficiency gains are real and measurable and easy to celebrate.

There is another version that uses the recovered time to go deeper on the hard problems, the ones that cannot be automated because they require judgment, tradeoffs, and accountability. That version is less visible on LinkedIn. The output is not a demo. It is a better product, a more defensible architecture, a team that understands what they are building.

A PM who has automated their roadmap research and now uses the time to build more automations is optimizing a metric that was never the goal.

The goal was always a better product. The free time is an invitation to get closer to that. Most teams are using it to stay in the same place, just faster.

This piece is part of an ongoing series on what agentic AI actually changes about the PM job.