How the PM role is changing in the AI era: centralized context, more output and judgment as the differentiator

Casey Winters of SuperMe presents the findings of a series of interviews with product managers at startups and public companies about how AI has changed the way they work. The piece mixes results, the author's interpretations and open questions. According to the article, it was reviewed by several SuperMe profiles (Julie Zhou, Ami Vora, Shishir Mehrotra, Sachin Rekhi and Aparna Chennapragada).

AI as the context layer for product work. Every PM interviewed has an AI-centered workflow. They used to jump between a document editor, analytics tools, Slack, the ticketing system, the wiki and the presentation builder. Those tools still exist, but they are now used from inside an AI tool. The author credits the adoption of MCP heavily for bringing workflows into a single place, to the point that the interface of many tools no longer matters. Rather than a “workspace,” what he describes is each PM building a personalized context layer, with the formula: favorite model + company context + personal context + company tools. Some rely on lots of local files, others on MCP integrations and others on custom skills. Some PMs build it in a personal capacity so they can take it to future jobs. The reason is that the AI environment becomes more valuable the more it is used, but much of the accumulated context belongs to the employer and is lost when changing jobs, so starting a new role feels much more like starting from scratch. PMs do their analysis, strategy and messaging in that environment and then export the result to the appropriate channel (presentation, document, email or Slack). According to the author, having context in that interface matters more than mastering SQL, Jira or any other specific tool, and skills make it possible to set company-specific standards, for example for analytics or document formats.

More productivity, but not necessarily more impact. PMs, engineers and designers are working more and shipping more: more code, specs, prototypes, bug fixes, evals and dashboards. Yet few PMs feel that this increase in output has translated into a similar increase in business results. AI makes work profitable that previously wasn't: work that wasn't prioritized, that generated no leverage, that sat in the backlog. Keeping up that pace leaves PMs less time to plan what would have the most impact, and it isn't easy to stop either: if every company resolves bugs and minor requests faster with AI, customer expectations may have risen so much that not doing so would mean falling behind. The author admits that, for now, the answer is largely unknowable.

Bottlenecks are shifting. PMs used to wait a long time for engineering development. With code easy to generate, the bottleneck moves to design, to integrating new features with the rest of the product, to handling edge cases, to organizational alignment and to shared product principles. AI removed one constraint and exposed others, and organizations have not yet redesigned their processes around them, while the technology changes faster than those processes can stabilize.

Product judgment re-emerges as a differentiator. There is a growing expectation that PMs query data themselves, build prototypes, tweak prompts, write code, build internal tools, create agents and define evals. The author senses that the bar has shifted too far from understanding the technology well enough to make good decisions toward personally demonstrating technical skill. That creates odd incentives: PMs strive to look technical and “AI-native” and have less time to decide whether what their teams produce should exist at all. Engineering scarcity used to force prioritization; AI has removed some of that scarcity without replacing the prioritization mechanism. Prioritization also served two other functions: controlling the pace of change customers perceive and rejecting bad ideas. By shipping much faster, more additions reach customers, cause confusion, and many should never have been built; the product and the codebase are now harder to understand. In mature organizations, being more efficient with AI is table stakes; what is valued is creating value that wasn't possible before. That combines a skill, taste (knowing what is good), and a process, principles, which define the ground truth against which humans and agents execute. AI only raises the value of judgment if PMs make it understandable to others and reusable.

Centralizing on AI doesn't mean trusting it fully. PMs use AI for everything, but they develop elaborate techniques around what it can be trusted with: what it can know and what it can decide. Some trust it with data and queries, others never give it raw data, and others give it data but want it back raw rather than as smoothed-over conclusions. All of them have seen AI overfit to the context it receives and flatten the nuances where the best product ideas usually lie. The more sophisticated the workflow, the less the PM blindly trusts AI. A new skill thus emerges: deciding what context to give it, what synthesis it can do, what it can execute, where human judgment is still needed and what a person must verify.

Three modes of operating with AI. According to the study, every organization starts the same way: it uses AI, experiences magic, starts building faster and experiences errors. What happens next defines three responses. They are not company types: different teams within the same company can operate differently, and a team can even switch modes.

Response 1, protecting the downside (“what if it's wrong?”). After suffering hallucinations or errors, some teams tighten their processes: they approve specific AI tools for specific uses, reject “slop” and take more care than before over the correctness of data and presentation. There are strict approval gates, strong presentation cultures and serious consequences for misusing AI. They are not anti-AI, but they are highly sensitive to losses, both to the company and to individual reputation. The PM's role becomes figuring out who must approve something, what evidence they need and how to make it safe enough. Innovation happens after hours through side projects. Claude was the interface most used by participants, but what they centralized on depended largely on what the IT department allowed: startups had access to whatever they wanted, while large companies used specific corporate tools or an almost random subset (most commonly Claude plus one of Cursor, Codex or Gemini; at Microsoft shops, Copilot and perhaps another tool). The available MCP plugins weren't uniform either. Many approval processes are tacit, and PMs “spin” until they find the decision-maker; knowing the organization and having prior trust with key people becomes a valuable currency. The advantage is quality control; the risk is spending so much effort protecting the current position that a competitor discovers something new that erodes it.

Response 2, maximizing the upside (“why not try it?”). These teams try things by default, accept that some of the work will be “slop” and expect to learn faster thanks to iteration speed. They work harder than ever and accomplish much more, but don't grow much faster; some acknowledge that shipping 10 times more didn't make them grow much faster. The chain “ship faster → more experiments → learn faster → grow faster” breaks when the capacity to ship outstrips the capacity to learn. AI chiefs of staff or central tools are built to track projects that perhaps should never have been approved; mediocre experiments produce mediocre internal tools and organizational and product confusion. AI-written internal summaries spawn AI tools to aggregate and read them. Skills were the first “AI-native” currency, with a performative component: hackathons focused on publishing skills rather than building new things, and many are no better than “pretend you are…” prompts. “Organizational slop” is what happens when an organization generates work faster than it can evaluate, coordinate or absorb it.

Response 3, optimizing AI for impact (“did it matter?”). These teams focus on whether what they build improves user or business metrics; productivity only counts if it turns into growth or profit. They don't equate token consumption with progress, have fewer tools but more trust in them, and work in documents and spreadsheets more than presentations. Every artifact is written for both humans and agents, and many PMs replace documents and slides with markdown or HTML. They build many internal agents and eye-catching features, with the tension that those agents affect the work of other functions. Their job security is good, but the companies have usually gone through layoffs and major organizational transformations. The author notes that these teams appear to have started in Response 2: perhaps you have to be overwhelmed by AI to learn to constrain it intelligently.

So what is the PM's job? The entire PM career was built on scarcity: you can't build everything, so you have to prioritize. AI promised abundance, and building everything didn't lead to the promised land. For the author, abundance makes deciding what not to build even more important. After a brief period in which PMs were also expected to be engineers, implementation is mostly returning to engineering, and the PM takes on what should happen, why, the principles governing product behavior and how success is evaluated. The PRD-versus-prototype debate, according to the author, obscures the fact that the eval becomes the central artifact: the PRD or strategy serves as a document for agents and humans about what was meant to be built, and the eval defines whether it was achieved. The conclusion is that AI made building easier, but not knowing what is worth building.

Notable comments. One reader asks how “slop” is defined and argues that, from their perspective as a PM, what stays hidden behind the interface has no intrinsic value, and that flawless code in a product with no user value is worse than sloppy code in one with product-market fit. Another reader questions the backlog finding: that work was there because nobody could name the customer it served, and asks whether the PMs interviewed identified who asked for it once it shipped.