Practical guide
AI fluency for product managers: compare feature requests
Turn a fictional feature-request pack into a bounded prioritization decision with evidence, alternatives and a revision trigger.
A product manager can demonstrate AI-enabled judgment by separating user problems from requested solutions and comparing options against an explicit decision. This original exercise uses fictional feature requests and capacity notes. The goal is a decision brief for what to investigate or build next, not an AI-generated roadmap that pretends uncertain demand and delivery estimates are settled facts.
Frame the prioritization decision
State what can be committed now and what still requires discovery.
The fictional team has capacity for one small investigation before planning its next release. The pack contains requests for an export, a dashboard and a notification change. The immediate decision is which problem to investigate first, not which feature will definitely ship.
Write the decision owner, available capacity and time horizon. Keep an investigation choice distinct from a delivery commitment. This prevents the assistant from turning a ranked list into a roadmap promise and gives the reviewer a clear standard for whether the recommendation fits the assignment.
Translate requests into supported problem statements
A requested solution is evidence of what someone asked for, not proof of the underlying need.
One fictional customer asks for an export because they prepare a weekly review. Another asks for a dashboard but describes a different reporting cadence. Ask the participant to preserve those contexts instead of merging both into a generic reporting demand. Identify what is known about the workflow and what remains an assumption.
AI can group requests and propose questions. Inspect the grouping against the source notes. Do not count repeated mentions from the same conversation as independent evidence or infer an audience-wide priority from the small supplied pack.
Compare options with explicit criteria
Use criteria that match the current decision rather than importing an unexplained scoring formula.
For this investigation choice, consider the importance of the unresolved question, access to useful evidence and the effort needed to learn something actionable. Those criteria differ from a full build prioritization. Keep unknown effort or impact estimates visible rather than assigning arbitrary numbers to complete a table.
Include an option to defer when the available evidence does not justify commitment. Explain the tradeoffs in plain language. A weighted score may organize a discussion, but it should not conceal unsupported inputs or imply mathematical certainty about customer value.
Challenge the leading option with a new constraint
Test whether the recommendation responds to changed evidence.
Introduce a fictional note that the main customer contact is unavailable during the investigation window. Ask whether the proposed investigation still makes sense, whether another evidence route exists or whether a different problem should take priority. The worker should update the reasoning rather than defend the first ranking automatically.
Keep alternatives connected to the same objective. Do not compensate for missing discovery access by inventing user preferences. The useful response identifies the constraint, its consequence and the smallest next action that could resolve it.
Deliver a decision brief with a learning plan
The handoff should explain both the choice and what the team expects to learn.
Include the recommended investigation, supporting observations, important assumptions, alternatives and a review trigger. Specify the question to answer and the evidence that would change the next decision. Make clear that selecting an investigation does not authorize a feature launch.
Evaluate source interpretation, option comparison and responsiveness to the changed constraint. Keep the result bounded by the fictional pack and available time. The product function guide covers programme dependencies and technology decision records; this role exercise specifically examines problem-led prioritization and the transition from request to learning commitment.
Sources and scope
NIST addresses AI risk management. Skills England describes workplace AI foundations.
These sources provide background, not endorsement of this exercise. The worked example and suggested review method are original illustrative guidance. They are not customer results, validated benchmarks or evidence of a particular product capability. Adapt the exercise to the task and use qualified review where consequences require it.
Sources: [1] [2]
Sources
- 1.AI RMF Core · NIST
- 2.AI foundation skills for work benchmark · Skills England