Pressure Testing Your Priorities

A critic you can call at nine at night

Prioritisation is the part of product management where you are most alone. You have more good ideas than capacity, incomplete evidence, stakeholders who each want their item first, and a decision that has to be made anyway. The people best placed to challenge your thinking are usually the ones with a stake in the outcome.

A language model has no stake. It will not lobby for its own feature, it does not mind being asked the same question five ways, and it has read an enormous amount of writing about why product bets fail. That makes it a genuinely useful sparring partner for a ranked list, a quarterly plan or a single contentious call.

It also makes it dangerous, for one reason this whole lesson is built around: it would much rather agree with you than argue with you.

It agrees with whoever is asking

These systems are tuned to be helpful and agreeable, and that tuning shows up as sycophancy. Ask "we should prioritise the enterprise permissions work over the self-serve onboarding improvements, right?" and you will get a thoughtful yes, with three reasons. Ask the reverse question in a fresh conversation and you will get an equally thoughtful yes for the other option.

Neither answer evaluated anything. Both completed your sentence. And because the reasoning is fluent and specific, it feels like validation, which is the worst possible outcome for someone trying to make a hard call honestly.

It gets worse under pressure. Push back on a critique and the model will often concede, apologise and adopt your view. So its persistence tells you nothing either, because it does not really have any.

Three habits that make critique worth having

Hide your preference. Describe the options as though a colleague proposed them. Same level of detail, same tone, no hint of which one is yours. Uneven description is a tell, and the model reads tells very well.

Ask it to argue against you, not to assess you. "What is the strongest case that this ranking is wrong?" produces objections. "Is this a good ranking?" produces reassurance. Once it has praised something it will tend to defend the praise, so never ask for the verdict first.

Steelman the option you are about to drop. The item you rank fourth deserves its best advocate before you cut it. Ask for the most persuasive case for it, written as its strongest supporter would make it to your leadership team. If that case is better than you expected, you have learned something.

Below are options our team is choosing between for next quarter. They
were proposed by different people. Do not tell me which you prefer.
[Option A: one paragraph, same structure for every option: the problem,
who has it, what evidence we have, rough effort, main risk]
[Option B: ...]
[Option C: ...]
Our situation, which you must use rather than general assumptions:
[stage of company, main goal this year, team size, known constraints]

For each option, give the strongest case FOR doing it first and the
strongest case AGAINST, written as its fiercest advocate and fiercest
critic would.
For each option, list what would have to be true for it to be the
right choice, and how I could check each item.
Assume we pick each option and it fails badly. Give the most likely
reason for each failure.
List every claim you made that depends on facts about our market,
customers or data that I did not give you.
Do not rank the options. Do not end with a balanced summary.

The "what would have to be true" step is the most useful part. It turns a vague argument into a list of checkable beliefs, and you will often find that one option rests on a belief nobody has tested.

It knows nothing about your market or your data

The second limit is permanent. The model has not seen your analytics, your revenue by segment, your churn reasons, your sales pipeline or your competitors' recent moves. When it says "enterprise buyers typically value permissions highly", it is describing what such sentences usually say, not your buyers.

This is why step four in the prompt above matters. Forcing it to list the claims that depend on facts it does not have shows you exactly where the critique is grounded and where it is general knowledge wearing your product's clothes.

Watch especially for scoring. If you ask a model to score options on reach, impact, confidence and effort, it will produce tidy numbers. Those numbers have no source. A scoring framework is only as good as the estimates that go into it, and estimates generated from nothing are laundering a guess into something that looks like analysis. Use the model to challenge your own estimates, never to supply them.

The call is still yours

A model can surface every objection, including many that do not matter. Deciding which ones matter, weighing them against evidence it cannot see, and standing behind the decision in front of your team: that is the job, and it stays with you. For the design side of critique, such as flows and accessibility, AI for UX and Product Design has its own lesson on pressure testing.