The PM Role, Rewritten by AI
Product Management - You will understand why teams optimized for execution speed are now structurally obsolete, and how to redesign your team around judgment instead.
Dear readers,
Thank you for being part of our growing community. Here’s what’s new this today,
AI Didn’t Make Your PM Role Faster. It Inverted What the Role Is For
Note: This post is for our Paid Subscribers, If you haven’t subscribed yet,
Your team is 30% faster thanks to AI. Your competitor’s team is 70% smaller and just as fast. You don’t have a productivity problem; you have a team design problem.
The speed gains are real, and they’re beside the point. When AI can draft a PRD in four minutes, synthesise 800 customer interviews overnight, and generate a stakeholder update that your VP will read without a single edit, you haven’t made your team more productive. You’ve exposed the fact that a significant portion of what your team does every day is execution work- procedural, templatable, and now automatable. The question is not whether your PMs are using AI. The question is whether your organization is still paying for work that AI does for free.
This is not a warning about job loss. It’s a warning about team design. The PMs who will thrive are not the ones who got faster; they’re the ones whose organisations redesigned around what AI cannot replace: judgment.
Deciding what problem is worth solving. Reading the customer who says ‘I want a dashboard’ but actually needs to stop losing accounts. Making the call on a 60-40 data split when both paths are defensible and the window is closing. That work is not faster with AI. It is simply more exposed because everything around it has been stripped away.
What follows is a design framework, not a philosophical observation. By the end, you should be able to audit your current team, identify execution bloat, and make concrete org chart decisions that reposition your PMs as judgment workers rather than execution processors.
“You haven’t made your team more productive you’ve exposed the fact that a significant portion of what your team does every day is automatable.”
The Execution-to-Judgment Ratio:
Why AI Eliminates the Wrong Half of the PM Job Description
Most PM job descriptions are secretly engineering specs for a human document processor. Write specs. Groom backlogs. Align stakeholders. Synthesise research. Draft roadmap decks. These are coordination and synthesis tasks, cognitively demanding in a world without AI, but structurally execution work nonetheless. They are the wrong half of the job description to optimize, because they are the half AI renders obsolete first.
Lewis Lin, whose work on the judgment-to-execution ratio inversion has become a useful frame for product leaders restructuring teams, argues that the core organizational question is no longer how many PMs you need to cover your surface area, but how much judgment capacity your team can actually deploy per product decision. Those two questions produce completely different headcount models.
Consider what happens when a PM at a mid-size SaaS company uses AI to collapse a two-day discovery synthesis into forty minutes. The output is arguably better, more patterns surfaced, fewer confirmation biases embedded in the manual read. What the PM does next with that synthesis is the entire job.
Does she recognize that the pattern pointing toward ‘better filtering’ is actually a retention signal disguised as a feature request? Does she push back on the roadmap item the synthesis superficially supports, because she knows from three customer calls that the stated problem is not the real problem? That decision, the one that happens in the forty minutes after AI did its work, is judgment. No model replicates it, because it requires integrating context that lives in her head, not in the dataset.
The implication for team design: if your org structure is still built around coverage ratios, one PM per two engineers, or per product area, you are paying for execution capacity in a world that no longer prices execution. Restructure around judgment per decision, not headcount per surface.
“The question is no longer how many PMs you need to cover your surface area, but how much judgment capacity your team can deploy per product decision.”
What ‘Judgment Work’ Actually Means in Practice
Judgment is not a vibe. It has observable, measurable components, and if you cannot identify them in your team’s weekly output, you cannot redesign around them.
Judgment work has three defining characteristics. First, it is non-reproducible from the available inputs: a different PM with the same data and the same AI tools would reach a different conclusion, and the difference matters. Second, it involves irreducible ambiguity, the call must be made before the data is complete, because waiting for complete data is itself a decision with a cost. Third, it has asymmetric stakes: getting it right produces outsized value; getting it wrong cannot be easily reversed.
A PM deciding whether to delay a launch by two weeks because a qualitative signal from three enterprise customers suggests a positioning problem is doing judgment work. A PM writing the launch brief that documents that decision is not. One requires the integration of weak signals, business context, and political timing. The other requires a template and thirty minutes.
The practitioners feeling this tension most acutely are the ones watching their execution work disappear in real time. One PM on Reddit described the experience precisely: leadership had pushed AI into sprint planning, and she found herself asking what her role actually was anymore, not because she feared replacement, but because the tasks she’d spent years mastering had simply become automated table-stakes. That disorientation is diagnostic. It means the execution layer is dissolving and the judgment layer is not yet visible in the org structure.
To measure judgment density, track one metric for thirty days: of every work output your PMs produce, what percentage required a non-obvious call that a well-prompted AI could not have made alone? If that number is below 40%, your team has an execution bloat problem.
“Judgment work is non-reproducible from available inputs, a different PM with the same data and the same AI tools would reach a different conclusion, and the difference matters.”
How to Audit Your Current Team Structure
Execution bloat is not inefficiency, it’s misalignment between what your team is structured to produce and what the organization actually needs from them now. Most teams that have adopted AI tools have execution bloat, because they added AI to their existing workflow rather than redesigning the workflow around AI’s capabilities.
The audit has three steps. Start with a two-week time log, not a self-reported estimate, but a structured diary in which every PM codes their daily work as either judgment or execution. Be strict about the boundary. Writing a PRD is execution. Deciding what the PRD should argue for, knowing it will likely kill a roadmap item three people above you care about, is judgment. Reviewing an AI-generated synthesis is execution. Deciding that the synthesis is asking the wrong question because the data collection was framed around the wrong user segment, that’s judgment.
After two weeks, aggregate the ratios. Most teams find that 60 to 75% of documented PM time is execution-category work. At companies where AI adoption has been aggressive but org design hasn’t changed, this number often increases, because PMs fill the time freed by AI with more execution tasks rather than deeper judgment work.
The second step is to map which execution tasks AI can fully absorb, spec drafting, backlog notation, release notes, stakeholder summaries, versus which ones still have a judgment core embedded in them. Backlog prioritization, for instance, sits on the boundary. One PM described their VP’s push to let AI handle prioritization entirely, and the genuine confusion about where PM judgment ended and algorithmic ranking began. That confusion is not a communication failure. It’s an org design failure.
The third step: for every execution task AI can fully own, remove it from PM job descriptions and performance reviews immediately. Retaining it as a PM accountability keeps your team anchored to a value proposition that AI has already voided.
“Most teams find that 60 to 75% of documented PM time is execution-category work, and at companies where AI adoption has been aggressive, this number often increases.”
Redesigning PM Roles Around Judgment: Concrete Org Chart Changes for 2026
The org chart change that most CPOs are avoiding is the one that matters: reducing PM headcount in execution-heavy areas and concentrating the remaining PMs in positions where judgment is the primary deliverable. This is not downsizing dressed up as strategy. It is a genuine redistribution of where PM energy sits in the organization.
Three structural changes produce the highest returns.
First, collapse the execution layer entirely. If you have PMs whose primary function is feature-area ownership, writing the specs, managing the backlog, running the sprint ceremonies, those roles are now hybrid execution-automation roles that should be restructured. One senior PM supported by strong AI tooling can cover the execution surface that previously required two or three. Redeploy the headcount to judgment-intensive positions or eliminate it.
Second, create explicit judgment roles. Product Strategy PM, Customer Intelligence Lead, Ambiguity Arbiter, the titles matter less than the mandate. These roles exist to make the calls that are non-obvious, to hold context across domains that AI cannot integrate, and to sit in the room where the organization’s direction gets set. They should have small scopes and high decision authority, the inverse of traditional feature PMs.
Third, push PMs closer to the edges of the organization, into sales, into customer success, into the markets where signals are weak and interpretation is everything. The PM whose job is to sit in ten enterprise renewal calls a quarter and extract the product insight that no survey will surface is doing work that compounds over time and cannot be automated. That work should be a formal role, not an informal habit.
Lewis Lin’s framing is useful here: when the ratio of judgment to execution flips, the org chart should flip with it, fewer PMs covering more execution surface with AI, more PMs concentrated at high-uncertainty decision points.
“One senior PM supported by strong AI tooling can cover the execution surface that previously required two or three, but only if the org structure is redesigned to let them.”
