AI in PM work and where it gets stuck

In mid-September, I spoke with two friends about product management and where AI might fit into the work. The conversations moved from requirements documents, data analysis, and prototypes to agents, shared memory, and how these tools could become part of everyday work inside a company.

As I went through the notes, one question stood out: between having an idea and running an experiment that tells you something useful, where does the time actually go?

These two conversations didn't give me a complete answer. They did leave me with a few specific threads to follow.

In the first conversation, a fairly clear bottleneck came up during a discussion of prototyping and the requirements process: work can get held up at the engineering stage. The surrounding topics included user journeys, scope, research feedback, and interactive prototypes.

That needs unpacking. A PM might already know what to test but need someone to build the prototype. Or the requirements might still be unclear, with engineers needed to help define them. There could also be constraints around data, interfaces, or existing systems. Each explanation calls for different help. The notes don't tell us which one applies here.

The same part of the conversation touched on copying and pasting, and on research feedback. That's a concrete operation worth following. What happens to a piece of feedback between receiving it and using it to shape a feature or an experiment? Does someone extract a passage, add background, or compare it with other feedback? Which steps are simply moving information, and which require a PM's judgment? The record doesn't contain enough detail to estimate how much time could be saved.

The discussion of data analysis offered another starting point. One example involved explaining what column C in a table represented, then asking AI to use it to answer a question about user counts. It's easy to overlook the step that came first: someone explained what the data meant.

My reading is that any assessment of AI's efficiency needs to include that preparation. Finding the right table, explaining the fields, and specifying what should be counted can all affect whether an analysis is usable. If those steps have to happen every time someone uses a tool, the preparation itself deserves attention. This conversation didn't establish that they were happening repeatedly; it gave me something specific to investigate.

The first conversation also covered multiple engineering teams, operations, design, and user research, along with strategy reviews, presentations, and OKR documents. Taken together, these topics raise another question for me: what does a document need to contain before someone else can act on it? A piece of user feedback might justify investigating a problem without being enough to set the scope of an investment. A data result might belong in a review, but someone still needs to explain which question it answers. That's my interpretation of the discussion, and I'd want to check it against an actual project.

We also talked about experiment speed, test cases, and success criteria. That made me want to look more closely at the work that follows a finished prototype. Someone still has to decide who should try it, which cases to test, and what results would justify further investment.

To find out whether an AI tool helps a PM, I would follow one experiment from preparation through a usable prototype to a decision about what happens next. I would record hands-on work and waiting time separately. That would help show which part the tool shortened, and whether later checking and revisions used up the time it saved.

The second conversation brought the working environment into focus. We discussed SharePoint, Office, Copilot, and shared workspaces, as well as personal subscriptions, approved agent tools, and security risks.

Those topics reminded me that using AI at work involves questions about which information a tool can access and how its output fits back into the existing workflow. For a pilot, I would first establish which part of the actual work it could handle: whether the necessary documents could be used, whether colleagues could continue editing the output, and what information a person would still need to supply. The notes don't establish that approvals had caused delays, but these conditions would affect whether a pilot could get started.

The second conversation also touched on engineering specifications, design context, prompts, and development artifacts. There's a connection to the earlier discussion of prototypes that I want to explore: when a PM hands an idea to an engineer or an AI tool, what else needs to go with it? Beyond the feature description, that might include constraints, design principles, and acceptance criteria. The transcript is incomplete here, so I'm keeping this as a question for a follow-up conversation. It doesn't establish that the participant was repeatedly rewriting this information.

Memory came up in both conversations: shared memory, retaining context, and maintaining a reliable record of the current situation. I find the possibility appealing. If a tool could retain a project's goals, agreed scope, and important changes, it might make the next piece of work easier to start.

That value still needs testing. One hypothesis is that keeping a project's background up to date could reduce the work a PM spends preparing inputs again. A test would need to measure both the preparation avoided and the effort required to maintain that context, including any mistakes caused by outdated information. The savings would have to outweigh those costs for the memory to be worth keeping.

The conversations also reached further, into proactive agents and AI taking on more business functions. I'm keeping those ideas on the list. The notes don't yet tell me which tasks happen most often, take the most time, or have already prompted someone to invest significant effort in a workaround.

Reviewing the conversations made me a little more cautious about my own product ideas. Put context, memory, and collaboration together, and it's easy to start designing an entire system. Before deciding what to build first, I want to see one actual piece of work unfold.

In the next conversation, I would ask the person to pick something they recently worked on and start with the materials they received. What were they trying to accomplish? What did they do first? Where did they stop, who were they waiting for, and what changed after they got a response? If they used AI, I'd want to look at the inputs, outputs, and subsequent edits together. Then we could have a much more specific conversation about which step a tool could help with.

This article draws on automatically generated meeting notes and transcripts from two private conversations, paraphrased without identifying the participants. The transcripts contain gaps; incomplete passages have not been reconstructed as direct quotations. The product interpretations and proposed tests are the author's and have not been validated through use. These two conversations are not representative of product managers as a group.