What I Learned Studying How Product Managers Use AI
What five product managers actually do with AI, and what they will not hand over.
When I signed up for HCDE 519, a qualitative research methods course, I figured I would walk away knowing how to run a decent interview and code a transcript without losing my mind. I did learn that. But the part that stuck with me was the topic my team picked: what happens to product managers when generative AI starts showing up as a coworker.
It is a strange moment to be a PM. Something like 78 percent of tech companies are already poking around with AI internally, and a majority say they plan to bake it into how their people work. PMs sit right in the middle of that shift. Their whole job is to translate between design, engineering, and the customer, and suddenly there is a tool that can draft, summarize, and reformat all of that in seconds. So my group asked a simple sounding question that turned out to be anything but:
How does adopting generative AI in a PM’s day to day actually redefine their role and reshape how they work with their teams?
Here is what we found.
How we did it
We kept the method honest and small. Five product managers, all based in the US, spread across different sectors and different stages of their careers, from early career to senior. We ran semi-structured interviews over Zoom, each one running about 45 to 60 minutes. We started with a pilot interview to shake out the bad questions, then did our main round.
That pilot humbled me more than I expected. I went in with a protocol I was a little proud of, and within ten minutes I watched my carefully worded questions produce pretty uninteresting answers. The ones that actually opened people up were the plain sounding follow ups: “can you walk me through the last time you did that?” I came out of it having rewritten half my questions, and with a new respect for how much of good interviewing is just active listening.
The fun and slightly painful part came after. We coded everything collaboratively using Taguette. To cut down on bias, each of us analyzed a transcript from an interview we did not personally run, so I spent my first real coding pass inside a conversation a teammate had led, which forced me to read closely instead of leaning on what I remembered hearing. Then we sat together, argued politely about what each code meant, and slowly merged our messy individual codebooks into one shared codebook. This part was harder than the interviews. I learned that two people can read the same sentence and tag it completely differently, and that the disagreement is the point, not a problem to rush past. Talking through why we each saw it differently usually produced a sharper code than either of us started with. We sorted everything into five buckets: role, changes, challenges, feelings and opinions, and tool usage. Out of that came the themes I am about to walk through.
The tools our participants reached for most often will not surprise anyone: ChatGPT, Claude, Gemini, Copilot, and a handful of internal company tools.
Finding 1: AI is a first draft machine
The clearest pattern was that PMs use AI to start, not to finish.
Almost everyone we talked to works inside strict document templates. Funding docs, one pagers, product requirement documents, each with its own required format and tone. AI turned out to be great at getting them off a blank page. One participant described uploading a transcript and notes and getting a structured one pager from their template back in about a minute, then editing from there. As they put it, starting from scratch was not their strong suit, and a tool that hands you a solid launch point changes the whole rhythm of the work.
The more sophisticated users were not just typing requests. They were engineering reusable prompts with formatting rules, tone guidance, and personas baked in, so the AI would mimic their company’s house style without being told every single time. One PM built a persona with a standing list of instructions so they did not have to repeat “follow the style guide” on every prompt.
The second half of this finding was about communication, not documents. PMs used AI to tailor a message for a specific audience and to pressure test it before sending. One person described stressing over the wording of an email to a vice president, then asking AI to rewrite it through a persona to make it land better. Another used it almost like a sparring partner, asking what questions a particular type of leader might raise and what resistance to expect.
Finding 2: Faster, yes. Hands off, absolutely not.
Everyone agreed AI sped up the boring parts. The repetitive, low brainpower work of formatting to spec and filling out routine docs got dramatically faster. One PM said it well: same responsibilities, same tasks, just done more quickly, which freed them up to focus on the actual substance of what they were trying to communicate.
But speed came with a tax, and the tax was judgment.
Generative AI does not know the context that lives in a PM’s head. It does not know the hallway conversation from last week or the decision the team already made and moved past. So our participants spent real time correcting tone, clarifying context, and reining the model back in when it started optimizing for the wrong thing. One person described how a single unclear detail in a prompt could send the whole output sideways, with the AI trying to solve problems that were already solved or were never in scope.
And then there is the trust problem. A few participants brought up hallucination directly. The fear was not that the AI is wrong, it is that it is confidently wrong. As one PM put it, the model fills gaps in its knowledge with whatever it thinks is a good answer, and if you are not deeply familiar with the content, it is genuinely hard to catch when it has made something up. That is the part that keeps a human firmly in the loop.
Finding 3: Ownership
PMs are not handing their work over to AI, and they are very deliberate about it. They have landed on a hybrid model: use AI for efficiency, not for automation. The traditional manual process was slow, but it gave them a deep sense of authorship and a real command of the material. They are not willing to trade that away.
Get Savannah’s stories in your inbox
Join Medium for free to get updates from this writer.
One participant gave us the cleanest definition of ownership I have heard. For them, owning a piece of work meant being able to answer roughly 90 percent of any question someone might ask about it. That is the bar. And they noticed something: the more you lean on AI to create something, the less ownership you tend to feel over it. So they stay on top of that tension on purpose instead of pretending it is not there.
PMs see their value in knowing their work well enough to stand behind every decision in it, and they are protecting that on purpose.
Finding 4: The role is getting bigger
The last theme was about how the job description is shifting.
Several participants described brand new responsibilities layered on top of their existing workload. The standout example was the “AI ambassador,” a real role one participant held. It was a top down initiative where leadership tapped one ambassador per team to run lunch and learns, share prompts and policies, demo what good usage looks like, and help everyone else get comfortable. New expectations were showing up too, like accounting for accuracy, testing, and baseline metrics, partly to secure funding and partly to measure whether the AI is actually helping.
Underneath the formal stuff was something more grassroots. Without any real training, PMs are learning AI socially. Nobody emailed them a manual. As one participant described it, the message from leadership was basically “we found this thing, go experiment, figure it out, and share what you learn.” So people swap tips in team meetings, in one on ones, in Slack channels, and on LinkedIn. They are writing the best practices together.
So what should AI tools actually do about this?
Because this was a design course at heart, we did not stop at observations. We turned the findings into recommendations for anyone building AI tools for knowledge workers. Four of them stood out.
Offer a “learning mode.” Tools should recognize recurring task patterns and proactively suggest context aware prompts. Think fill in the blank prompt builders that nudge users to include audience, tone, objective, and constraints. This lowers the barrier for less experienced users and makes the output better on the first try.
Show your work. Source transparency and explainability matter a lot when trust is the bottleneck. If a tool can surface its reasoning and where its information came from, PMs can validate accuracy before they stake their name on it.
Protect human ownership. Tools should augment, not replace. A small move like occasionally asking “do you understand why this was suggested?” keeps the person engaged and reinforces their sense of authorship instead of chipping away at it.
Make space for the conversation. Since so much learning happens informally, organizations benefit from a central place for it. A simple internal hub covering why to use AI, the guidelines and data policies around it, and a library of prompts and FAQs can turn scattered experimentation into shared knowledge.
What I would do differently
If I had more time, I would push this further. The obvious next step is longitudinal work, tracking the same PMs over two or three years to see how the role really settles, because right now we are catching a snapshot of a fast moving target. I would also love to shadow people and watch how they actually use AI in the moment, rather than relying only on how they describe it. And I would widen the net to include more industries, more company sizes, and especially veteran PMs with 15 plus years in the role, along with people in slow moving, heavily regulated fields who are probably adapting in completely different ways than the agile tech crowd.
I also want to be honest about what five interviews can and cannot tell you. With a sample this size, what we found are patterns, not proof. The themes showed up consistently enough that I trust them as signals, but I would be careful about turning any of them into a confident claim about all PMs everywhere. The “AI ambassador” role, for example, was real and striking, but it came from one person at one company. I treat it as a thread to pull on, not a trend I have established. Knowing where that line sits, between what the data suggests and what it actually supports, felt like one of the more useful things I took away from the whole project.
The piece I am most curious about, though, is whether my recommendations actually hold up in practice. Right now they are educated guesses built from interviews. I would want to put them in front of the same PMs, have them try out things like a guided prompting mode or a source transparency feature in their real workflows, and then come back and tell me what helped and what got in the way. Testing the ideas with the very people who inspired them would turn this from a set of observations into something I could actually stand behind.
The thing I keep coming back to
The headline fear about AI is replacement. What our small study actually found was something messier. AI is not erasing the product manager. It is taking the tedious parts of the job off their plate and, in the process, putting more weight on the parts only a person can really do: judgment, context, ownership, and the slow work of getting a team to understand each other.
The PMs who seemed happiest were not the ones who automated the most. They were the ones who figured out exactly where to let the tool drive and where to keep their hands firmly on the wheel.
If you are a PM reading this, that is the move I would steal. Let AI own the blank page and the formatting tax, the stuff that drains your time without using your judgment. Then guard the parts that are actually yours: the context, the strategic call, the ability to answer 90 percent of the questions about your own work. Speed is easy to get now. Ownership is the thing worth protecting.
That feels like a pretty good lesson for the rest of us too.
This was a team project for HCDE 519, Qualitative Research Methods. Huge thanks to my groupmates and to the five product managers who gave us their time and their honest opinions.
