How Product Teams Are Actually Using AI to Make Decisions

Ask AI which feature to prioritize next and hand it a list, and you'll get a ranking, usually built from how each feature is described in your prompt rather than from any real evidence about user impact. Better-written feature descriptions read as more compelling, and the ranking quietly tracks writing quality more than actual outcome, which is a documented failure mode of prioritization frameworks generally, AI-assisted or not.

The better question isn't "rank these features." It's "which of these actually serves a validated outcome, and which is just a feature we've talked ourselves into," a distinction most roadmap reviews never explicitly make, which is exactly why a well-argued but unvalidated feature so often survives a prioritization meeting intact.

What does asking AI to rank a feature list actually produce?

Hand an AI a list of candidate features and ask which to build first, and you'll get a ranking that reads as reasoned: this one addresses a bigger pain point, that one is lower effort. Look closer and the ranking is often driven by how persuasively each feature was described in your prompt, not by evidence you actually supplied about user impact.

This isn't a flaw unique to AI. It's the same failure mode unstructured roadmap prioritization has always had: whoever writes the most compelling pitch for their feature tends to win the argument, regardless of whether the underlying evidence supports it, and an AI asked to rank a list simply inherits that bias faster and with more apparent confidence than a room full of people arguing it out would.

Is AI actually useful for a roadmap call, or just persuasive?

Unaided, it's genuinely strong at structuring a comparison once you supply real inputs, evidence for each option, estimated effort, the specific outcome each is meant to serve, and at catching internal inconsistency, two features justified by contradictory assumptions about the same user segment, for instance.

It's weak at anything requiring actual knowledge of your users: real usage patterns, support ticket themes, what a sales team is actually hearing in the field, none of which it has any way to access on its own. Feed it only vague impressions and it will produce a confident-sounding ranking built on those same vague impressions, dressed up in the language of rigor.

What's worth running through AI before this roadmap call?

These four work in Claude, ChatGPT, or Gemini as written.

1. The outcome check. "For each of these roadmap items: [list], state the specific user or business outcome it's meant to serve. If you can't state one clearly from what I've given you, flag it rather than guessing." Why it works: this surfaces roadmap items that were never actually tied to a real outcome in the first place, dressed up as obviously worth doing.

2. The assumption audit. "For [specific feature], list the assumptions we're making that haven't been validated yet, and rank them by how damaging it would be if each turned out false." Why it works: most risky roadmap bets fail on one specific unvalidated assumption, not on execution, and naming them explicitly turns a vague worry into a specific, checkable risk.

3. The kill-criteria test. "Before we build this, what evidence, if we saw it in the first two weeks after shipping, would tell us this was the wrong call? Be specific, not just 'low engagement.'" Why it works: defining failure in advance, concretely, makes it far easier to actually kill a bad bet later, instead of quietly redefining success after the fact to match whatever happened, which is the usual, quieter way a bad bet survives past the point it should have been cut.

4. The stakeholder-lens read. "Read this roadmap decision as a skeptical [engineering lead / sales lead / support lead]. What's the strongest objection they'd raise, and is it about the decision itself or about how it was communicated?" Why it works: separating a substantive objection from a communication problem prevents good decisions from getting killed by bad rollout, and bad decisions from surviving because they were pitched well.

What's left once these four are done?

This exercise will make today's roadmap decision noticeably more rigorous than an unaided ranking. It won't give your team a standing bar that holds for every prioritization call ahead, regardless of a new PM joining, a founder's strong opinion in the room, or the pressure of a quarter already behind schedule and looking for anything that ships fast. One well-argued decision isn't the same as an operating discipline that holds regardless of who's making the case.

How does Cagan's framework actually change the roadmap conversation?

Marty Cagan, documented across Inspired and years of published writing on product organizations, argues for empowered teams: give a team a problem to solve and an outcome to hit, not a pre-built feature to ship, because teams closest to the user and the technology consistently make better calls than a roadmap handed down as a features list from above.

Before, generic prompting: asked to help prioritize a features list including "add SSO login," a generic AI response treats it as a self-evidently important feature (enterprise buyers expect it) and ranks it accordingly, without ever asking what specific deal or outcome it unlocks.

After, Cagan's framework applied: the framework refuses to treat any list item as self-justifying. It asks first what outcome SSO is actually meant to serve, is there a specific, named enterprise deal blocked on it right now, or is it a generically assumed "enterprise requirement" nobody has actually validated against a real deal. If the team can point to a specific blocked deal, the framework treats it as a real, outcome-backed priority; if it's a vague, unvalidated assumption about what enterprise buyers want, the framework's documented position is that it doesn't belong on the roadmap yet, regardless of how standard the feature looks from the outside.

A generic prioritization prompt has no built-in reason to demand a stated, checkable outcome before a feature earns its place on the roadmap. The framework does, as a hard requirement rather than a smarter-sounding ranking of the same unexamined list.

How do you actually get this framework running in Claude, ChatGPT, or Gemini?

Claude takes it as a Skill: Settings → Skills → Add skill, upload the .zip. It auto-invokes once your question matches the skill's description, or gets forced with /marty-cagan-framework at the start of a message. In Claude Code, the package installs into ~/.claude/skills for every project, or a project's own .claude/skills folder for just that one.

ChatGPT has no Skills equivalent, so the .md file becomes a Custom GPT's Instructions: Create a GPT → Configure → Instructions, pasted in directly. Skip the default Custom Instructions fields, they max out at 1,500 characters; a Custom GPT's Instructions field holds roughly 8,000, enough for the full framework.

Gemini has no dedicated upload path, so the content goes into the system prompt if your interface exposes one, or opens the first message instead: "Here is a thinking framework to apply throughout this conversation. Read it carefully, then answer using this framework's approach," with the framework text pasted below.

Where does this point next?

If there's a specific meeting where this roadmap call needs to actually land, Meeting Pre-Read is a $39 tool built to prep for exactly that kind of conversation, attendee intent and likely pushback included. Cagan's documented method is one of several in the Product Leader category, alongside Teresa Torres and Don Norman, each an .md file readable by Claude, ChatGPT, or Gemini.