How PM Work Is Changing with AI

Recently, we interviewed a bunch of product managers across startups all the way to public companies to understand how their workflows have changed with AI. Below I present some findings, some insights, and some genuine questions about where things go next.

This article was reviewed by the following SuperMe profiles: Julie Zhou, Ami Vora, Shishir Mehrotra, Sachin Rekhi, Aparna Chennapragada

AI is becoming the context layer for PM work

Every PM we talked to has an AI-centric workflow. PMs used to bounce around between many different applications and browser tabs to do their work: a document editor, multiple analytics tools, Slack, a ticketing system, a wiki, deck creator.

Don’t get me wrong; they still use these tools. But they tend to use them within an AI tool. The degree to which MCP has been adopted to concentrate workflows in one place instead of switching between apps and tabs cannot be overstated. The interfaces of many of these tools may as well not matter anymore, because that is not where they are being consumed.

Calling it a workspace also feels inaccurate. What seems to be happening is PMs are building a personalized context layer around all of their work. Some use a lot of local files. Some use a lot of MCP integrations. Some use a lot of custom skills. The formula looks like: favored model + company context + personal context + company tools.

Some have built this personally to leverage across companies and new roles in the future. Why does this seem necessary? Your AI working environment becomes more valuable the longer you use it, but most of that accumulated context belongs to your employer and disappears when you change jobs. New roles feel like starting from scratch much more dramatically than they did before.

PMs bring context into their favorite AI environment, do all of their analysis and crafting of strategy and messaging there, then export out when complete to the appropriate messaging channel, whether that be deck, doc, email, or Slack message. Making sure that one interface has context matters a lot more than being good at SQL / Jira / [insert tool here]. Skills allow for company-specific standards on how certain parts of their workflow should work, like analytics or deck / doc formats.

PMs are more productive. Their teams are not necessarily more impactful

Everyone from the PM to the engineer to the designer seems to be working harder and shipping more. Every team is producing more code, more specs, more prototypes, fixing more bugs, writing more evals, and managing more dashboards. What was striking was how few PMs felt that the dramatic increase in output had produced a similar increase in business results.

AI seems to be making previously uneconomic work cheap enough to do. The unprioritized work. The work that doesn’t create leverage. The work that used to stay in the backlog. Keeping up with all of this work is actively giving PMs less time to plan the most impactful work.

But that also doesn’t make it easy to stop doing those tasks. If every company now attacks bugs and low-feature feature requests faster with AI, have customer expectations risen so much that if we don’t do them, we would fall behind? That answer is largely unknowable today.

AI moves the bottlenecks of traditional product development

PMs spent a lot of time waiting on engineering development to complete. It was slow and expensive even when working with the best engineers. With code now being easy to generate, it’s shifted the bottleneck in the product development process to other places:

• Design
• Integration of more features with the broader product
• Managing edge cases
• Organizational alignment
• Shared product principles.

AI removed one constraint and exposed several others. Organizations have not yet redesigned their product development processes around those new constraints, and the underlying technology keeps changing faster than those processes can stabilize.

AI productivity is now table stakes. Product judgment re-emerging as the differentiator

There's an emerging expectation that PMs should be able to:

• query data themselves
• prototype
• change prompts
• write code
• build internal tools
• create agents
• define evals

There’s a growing sense the standard of PM has over-rotated from understanding technology well enough to ensure good decisions are made with follow-through to demonstrating good technical ability yourself. This creates weird incentives where PMs work harder to demonstrate that they're technical and AI-native, while having less time to determine whether the things their teams are producing should even exist.

Before AI, engineering scarcity forced prioritization. AI removed some of the scarcity without replacing the prioritization mechanism. There is a sense that prioritization skills need to be re-discovered and valued again inside organizations large and small. Part of the importance of the prioritization skill of a PM historically was the understanding:

• Code was leverage
• But code was expensive
• So you saved it for the best ideas

For everything else, we either don’t do it, or do it manually with people.

Prioritization also played two other important roles:

• It controlled the rate of change to the customer
• It rejected bad ideas

When teams started shipping so much faster, more additions started reaching customers faster, causing confusion, and a lot of those concepts should have been rejected from being built in the first place because they were not good ideas. The product is now harder to understand, as is the code base.

For the more mature organizations, leveraging AI to be more efficient is table stakes. Using AI to create value for the customer and the business that couldn’t have been done before AI is what is valued. This is really a combination of a skill and a process. Taste, or knowing what good looks like, is the skill PM’s need to re-develop with such a new technology that changes what types of products can be built. Principles, where we define the ground truth humans and agents execute against, is the new process where a PM’s ability to align a team around shared understanding becomes so important. AI raises the value of judgment only when PMs make their judgment understandable to others and reusable.

Centralizing around AI does not mean fully trusting AI

PMs utilize AI for everything, but it doesn’t mean they trust it. What they do is develop elaborate techniques for what AI is allowed to be trusted with. What it can know and what it can decide for you are key decision points for all PMs we talked with. Some trust it with data and querying. Some will never give it raw data. Some will give it raw data, but want the raw data back instead of smoothed conclusions.

Every PM has seen AI over-index on the context it was given, flattening the nuance where the most useful product insights often live. In a way, the more sophisticated the AI workflow from a PM, the less that PM blindly trusts AI. A new skill is emerging over how to figure out what to give AI to best augment your own performance:

• the context it has
• the synthesis it’s allowed to do
• what it can execute for you
• where human judgment is still required
• what needs to be verified by a human

Three operating modes with AI

From our research, we saw three common responses to using AI. Every organization starts in roughly the same way:

Use AI -> experience magic -> start build faster -> experience mistakes

What happens after that point defines the person, team, or organization that experienced it. These aren't three types of companies. Different teams inside the same company can operate differently, and even one team may move between modes at different stages of development.

Response 1: Protect the downside

“What if it’s wrong?”

Some teams, after experiencing AI hallucinations or mistakes, tightened their processes. They approve very specific AI tools for specific use cases. There is such an organizational rejection of slop that these organizations focus more on correct data and presentation than perhaps they did before AI. Strong gates, strong deck cultures, big repercussions for getting caught using AI incorrectly.

These teams are not anti-AI, but they are very loss sensitive both for their company and their internal individual reputation. The role becomes figuring out who needs to approve this, what evidence will they need, and how do I make it safe enough to proceed? Innovation with AI tends to happen off hours with personal projects. They don’t want to be left behind on the skills they’ll need in the future due to organizational caution.

While Claude was the most common interface our research participants used, we found what they centralized around was somewhat random based on what their IT departments told them they could use. While startups tended to have access to whatever they wanted, larger companies either had to use very specific company tools, or had access to a random subset of the landscape. Claude and one of, but not all of Cursor, Codex, or Gemini was the most common setup. Or for Microsoft shops, Copilot and maybe one other tool was allowed. What MCP plugins they had access to in those tools also wasn’t consistent.

Different teams have different levels of clarity to those questions. Some have very defined gated processes, but many are more tacit discovery of who holds the soft power in the org. PMs find themselves spinning until they find the decision maker. Knowing how the organization works is becoming more valuable. Not that it was ever unimportant for a PM, but in a time of shifting priorities and processes, knowing who to talk to and having default trust with them is a currency that can’t be over-valued right now. PMs that don’t have it are stressed, and PMs that do have a whole lot less to worry about.

The advantage to this response is quality control. The issue is that the company may spend so much effort protecting its existing position while competitors discover something fundamentally new that erodes the value of that position.

The defining characteristic of this type of response is that the team has a very defined idea of appropriate and inappropriate uses of AI, and strong enforcement around these boundaries.

Response 2: Maximize the upside

“Why not try it?”

Unlike teams in the first category, teams in the second category default to trying stuff. They lean in, accepting that some of their work might be slop, but that they will overall get more done and they will learn faster from this new iteration speed. The idea that if you can build faster, you can learn faster is a sound one, but the learning doesn’t come without some process around it.

These teams are working harder than ever, and they are getting a lot more done, but they aren’t growing that much faster. Some teams have their blinders on and are in go mode. Some are calling out that with 10x more shipped, they didn’t grow much faster. They are in various phases of awareness of the productivity / impact mismatch. But all believe they are AI native, and that brings some job security at their current company or somewhere else in the future.

Part of what seems broken is the thesis of shipping faster -> more experiments -> faster learning -> faster growth is breaking down when things are happening so fast that your capacity to ship exceeds your capacity to learn.

PMs are building AI chiefs of staff or central tooling to keep tabs on a bunch of updates to projects which never should have been greenlit in the first place. Slop experiments lead to slop internal tools lead to organizational confusion internally and product confusion externally by their customers. AI written updates internally lead to AI tools to aggregate and read all the updates. All of this stuff is being used internally, but for what gain?

Skills were the first form of AI-native currency. Several PMs described a performative element to AI adoption. Visible AI activity can become a way to demonstrate that you're keeping up. Hackathons became about publishing new skills rather than building new things. There’s a picks and shovels meme in there somewhere. Some of these skills have good sources, and some feel so impactful people try to re-create them at new companies, but many are no better than “pretend you are…” prompts.

Organizational slop is what happens when an organization can generate work faster than it can evaluate, coordinate, or absorb it. This seems to be the defining characteristic for companies in response 2.

Response 3: Optimize AI for impact

“Did it matter?”

The teams we saw in this category mainly care about whether what they build impacts user or business metrics positively. They perceive AI allowing them to build things they could not build before as a lever to impacting those metrics. Yes, they care about productivity, but if it isn’t eventually channeled into more growth or more profit, they do not get any credit for it. If you build faster and learn faster as a result, great. If you built faster and didn’t learn, you wasted a lot of people’s time.

They see any alpha from AI coming through the lens of product sense and good prioritization. They don’t equate token consumption with progress. They either need to impress the customer or the CEO/CFO with what they ship. They have fewer tools than the companies in response 2, but they are more confident in them. Their work lives in docs and spreadsheets, not decks like the companies in response 1.

And that work is for their internal agents just as much as it is for co-workers to consume. Every artifact is written for both humans and agents as first class citizens. Many PMs have even changed their default style or format for this shift with markdown or HTML replacing docs and slides.

They build lots of internal agents and wow features. And PMs face a real tension when those internal agents affect other functions’ jobs. That might impress the CFO, but not your friends in other parts of the company. Their job security is good, but the company itself has usually gone through layoffs with some major forms of organizational transformation.

It seems like the teams we observed in the third bucket started in bucket two first. Perhaps teams have to get overwhelmed by AI before they learn how to constrain it intelligently.

So what is the PM’s job now?

PMs are dealing with massive organizational change at the moment. Their entire careers until now dealt with a fundamental truth around scarcity: we can’t build everything our customers want, so we have to prioritize. AI promised abundance. We can suddenly build everything, so we do. That has not led to the promised land. So PMs and their organizations are gradually realizing that the abundance makes some of that old job description even more important. The ability to build everything makes deciding what not to build even more valuable.

After a brief period where PMs were expected to become engineers themselves, the engineering team is moving back to owning most implementation mechanics. PM increasingly owns what should happen, why, the principles governing a product’s behavior, and how success should be evaluated. There are debates around communicating that vision between PRD’s vs. prototypes, but that debate hides the fact that the eval is becoming the core product artifact. The initial strategy doc or PRD is re-emerging as an artifact for agents as well as humans to understand what we intended to build. The eval defines whether we did or not.

AI made it easier for PMs to build. It did not make it easier to know what was worth building. PMs who get that part right will be the ones who actually turn AI into better products.