Using AI as a Product Manager
Where AI actually earns its keep in a product manager's real week, three prompts built for prioritization and stakeholder conflict, and which documented product frameworks are worth loading alongside it.
A product manager's week is a running argument between what stakeholders want built and what evidence actually supports building it, held together by a roadmap that has to look coherent to everyone even when the underlying priorities genuinely conflict. Generic AI use treats each roadmap question as a one-off ranking exercise. The more useful use treats prioritization, stakeholder conflict, and validation as the same few recurring problems, checked the same structured way every time regardless of who's arguing for what this week.
What does a product manager's actual week look like?
The recurring calls repeat under different feature names each sprint: whether a roadmap item is actually tied to a validated outcome or just sounds important, whether a disagreement between engineering, sales, and design is really about priority or about which outcome each side is optimizing for, whether an assumption the whole plan depends on has actually been tested or just feels true because everyone in the room agrees with it, and whether a stalled feature should be killed, revised, or given more time before the data is in either way. None of these get easier with experience so much as they get faster to recognize once you've seen the pattern a few times across different sprints and different teams.
The underlying tension is structural, not personal: engineering, sales, design, and leadership are each optimizing for a genuinely different outcome, and the roadmap is the document that has to reconcile all of them into one coherent plan without pretending the conflict doesn't exist. A product manager who treats every disagreement as a personality clash misses the actual, resolvable tradeoff sitting underneath it.
Where does generic AI actually help here, and where does it quietly fail a product manager?
Unaided, it's genuinely strong at structuring a comparison once you supply real evidence, the outcome each item serves, the data behind it, the cost to build, and at catching internal inconsistency between two roadmap items that quietly assume contradictory things about the same user segment.
It's weak at anything requiring real knowledge of your users: actual usage patterns, what support tickets are really saying beneath the surface, what a specific stakeholder's objection is actually about underneath the stated reason. Feed it only vague impressions and it will produce a confident-sounding ranking built on those same vague impressions, dressed up in language that sounds far more rigorous than the input actually was.
What's worth running through AI before this sprint's roadmap call?
These run in Claude, ChatGPT, or Gemini as written.
"For each of these roadmap items: [list them]. State the specific user or business outcome each is meant to serve. If you can't state one clearly from what I've given you, flag it rather than assuming one."
Why it works: this surfaces roadmap items that were never actually tied to a validated outcome, dressed up as obviously worth doing because a stakeholder wants it.
"Here's what each stakeholder is asking for, and roughly why: [describe the positions]. For each, what outcome are they actually optimizing for underneath the stated request, and where do those outcomes genuinely conflict versus just sound like they do?"
Why it works: most stakeholder conflict is actually a conflict between outcomes, not personalities, and naming the underlying outcome each side is chasing turns a personality clash into a tradeoff you can actually discuss.
"This roadmap bet depends on the assumption that [state it]. Has this actually been validated, or are we assuming it because it feels true? If unvalidated, what's the cheapest test that would tell us if we're wrong?"
Why it works: naming the specific unvalidated assumption, rather than a general sense of risk, turns an abstract worry into a concrete, checkable test you can actually run before committing further.
What's still missing once these three are run?
Run all three and this sprint's prioritization and stakeholder conversations will be noticeably sharper. What you won't have is a system that knows your actual users, your support team's real read on what's breaking, or what a stakeholder's objection is really about beneath the stated reason. The gap isn't this sprint's roadmap; it's that no prompt substitutes for the product sense a manager builds by actually talking to users and watching the product get used.
Which documented frameworks actually fit a product manager, and why?
Marty Cagan's documented empowered-teams framework, developed across Inspired and years of writing on product organizations, argues for giving a team a problem to solve and an outcome to hit rather than a pre-built feature handed down from above. Teresa Torres's continuous discovery habits make the case for weekly, lightweight contact with real users rather than periodic, formal research that goes stale between rounds. Don Norman's human-centered design principles, from The Design of Everyday Things onward, ground product decisions in how people actually perceive and use an interface rather than how a spec describes it.
Each targets a different recurring failure: Cagan for roadmaps built from features instead of outcomes, Torres for product decisions made without recent, real contact with users, Norman for designs that are technically correct but genuinely unusable in practice.
How does one of these frameworks actually reach Claude, ChatGPT, or Gemini?
In Claude, each installs as a Skill: go to Settings → Skills → Add skill and upload the .zip. Claude reads the skill's description and auto-invokes it when your question matches, or you can force it with /marty-cagan-framework at the start of a message. Claude Code users get the same thing via ~/.claude/skills (every project) or a project's .claude/skills folder (that project only).
In ChatGPT, the plain .md file goes into a Custom GPT: Create a GPT → Configure → Instructions, paste the framework's content in. Standard Custom Instructions (the "About me" fields) cap out at 1,500 characters, too short for a full framework, so use a Custom GPT specifically, not Custom Instructions.
In Gemini, paste the .md content directly into the system prompt if the interface you're using supports one, or lead your first message with it: "Here is a thinking framework to apply throughout this conversation. Read it carefully, then answer using this framework's approach," followed by the file's contents.
Where should a product manager actually start?
None of the existing 10-persona bundles draw meaningfully from Cagan, Torres, or Norman, the Decision-Maker's Stack leans toward cross-domain strategic thinking rather than product-specific method, so the Product Leader category itself is the better starting point here. For the meeting where a roadmap decision actually has to land, Meeting Pre-Read is a $39 tool built to prep exactly that conversation, attendee intent and likely pushback included.
All the copy-paste prompts from this guide, and the rest of the AI Practice series, live at /prompts too, free to copy without reading the guide first.
Frequently asked questions
Can AI actually help me decide what to prioritize on the roadmap?
It can help you structure the comparison once you supply real evidence, which outcome each item serves, what data backs it, what it costs to build. It can't tell you which outcome actually matters most for your specific business this quarter, since that depends on strategy and market context it doesn't have unless you supply it directly and honestly, and even then only as well as you understand it yourself.
What's the biggest mistake product managers make asking AI for roadmap help?
Asking it to rank a feature list instead of asking whether each item is tied to a real, validated outcome at all. A ranking exercise rewards whichever feature is best-described in the prompt; checking for a validated outcome first catches items that were never actually justified beyond someone's strong opinion voiced confidently in a planning meeting, and were never really tested against anything harder than agreement in the room.
Can these prompts help with stakeholder disagreement, or just with the roadmap itself?
Both, and the two are usually connected more than they first appear. A disagreement about priority is often really a disagreement about which outcome matters most, engineering wants technical debt addressed, sales wants a specific feature, and structuring the actual tradeoff, rather than just the personalities in the room, tends to make the real disagreement visible and genuinely easier to resolve.
Is it okay to use AI to write the actual product requirements document?
For structuring one from decisions you've already made, yes, that's a reasonable use. For generating the underlying judgment about what to build and why, no, since that's the part of the job an outcome-focused product manager is actually accountable for to the rest of the team. Use it to make the PRD clearer and more specific, not to skip the thinking that should precede writing it.
How is this different from the earlier product-decisions guide already on the site?
That guide covers a single roadmap decision in depth, the outcome check, the assumption audit, the kill-criteria test, run against one specific bet you're already weighing. This one is broader, covering the recurring shape of a product manager's whole week, prioritization, stakeholder conflict, and validation, alongside the specific documented frameworks, Cagan, Torres, Norman, worth loading for each of those situations as they come up.
Do I need actual usage data for these prompts to work?
Real data sharpens the output, but an honest, stated assumption works fine too. Saying "we believe X based on early conversations, not confirmed data" produces a genuinely useful response; presenting a guess as confirmed data produces a confident-sounding answer built on a false premise, which is worse for the roadmap in the long run than being upfront about the actual gap in evidence.
What's the honest limit of using AI for product decisions?
It has no access to your actual users, no way to run the experiment that would really validate an assumption, and no stake in the outcome if the roadmap bet turns out wrong. Use it to sharpen the comparison and catch assumptions dressed up as certainty; the actual bet, and the responsibility for it, is still the team's to make and own.
Written by Gareth Hoyle. Last updated 26 September 2026. Part of the authority.md guides library.
More guides.
Bringing AI Into a Creative Project Without Ruining It
What generic AI brainstorming actually gives a creative project and what it quietly flattens, four prompts that help today without taking over, and what changes when the AI applies Rick Rubin's documented listening practice instead of generic idea generation.
AI for Hiring Decisions: Where Claude and ChatGPT Actually Help
A grounded look at what generic AI use gets right and wrong when you're deciding on a hire, four prompts that genuinely sharpen the decision, and what changes when the AI applies a documented evidence-based hiring framework instead of generic interview advice.
Using AI to Prep for a Negotiation: What Actually Works
Generic AI negotiation advice is genuinely useful and genuinely limited. Here's what Claude and ChatGPT get right before a negotiation, four prompts that work today, and what changes once the AI has a documented framework instead of a generic one.