Prompts / Product Management & UX

ChatGPT prompt for a feature prioritization tool

This prompt turns a feature backlog into a reasoned priority decision rather than a list ordered by opinion. Use it when you can provide customer evidence, product goals, constraints, and rough delivery estimates.

PromptOpen ChatGPTOpen Claude
Act as a product manager facilitating an evidence-based feature prioritization review. Prioritize the candidate features below against [PRODUCT GOAL] for [TARGET USERS] during [PLANNING HORIZON].

Inputs
- Candidate features: [FEATURE BACKLOG]
- User evidence: [USER EVIDENCE]
- Business and technical constraints: [CONSTRAINTS]
- Delivery estimates and dependencies: [ESTIMATES AND DEPENDENCIES]
- Current metrics and baseline: [CURRENT METRICS]

First, normalize each feature into a problem statement, intended user, desired behavior change, and measurable outcome. Do not treat a requested solution as proof of a problem. Score each item from 1–5 for: evidence strength, affected-user reach, expected impact on the stated goal, confidence in the impact estimate, effort, strategic fit, and risk. Define each score briefly using only my inputs. If data is insufficient, mark the score “unknown” rather than guessing.

Produce:
1. A ranked table with feature, user problem, scores, dependencies, key assumption, and recommendation: now, next, later, discover, or do not pursue.
2. A short explanation of the top three recommendations, including the tradeoff made against lower-ranked work.
3. A 90-day sequence that identifies discovery, design, build, launch, and measurement milestones; include a named role for each owner, not invented people.
4. For every “now” item, write a testable outcome statement, success metric, guardrail metric, and smallest experiment or release that could reduce uncertainty.
5. A decision log listing the material assumptions and evidence gaps.

Do not add estimated revenue, user counts, effort, legal requirements, or technical capabilities that I did not provide. Before answering, verify that no high-effort item ranks ahead of a lower-effort alternative without a stated reason, and flag features with dependencies that make the proposed timing unrealistic. Ask up to three clarifying questions only if a required input is missing.

Fill in

PlaceholderWhat to enterExample
[PRODUCT GOAL]State one measurable product outcome and the period it applies to.Increase weekly activation of new team accounts from 42% to 55% by the end of Q1
[TARGET USERS]Describe the user segment whose needs should drive the decision.Workspace admins at 20–200 person professional-services firms
[PLANNING HORIZON]State the planning period, such as Q1 or the next 90 days.The next 90 days
[FEATURE BACKLOG]List each candidate feature with a brief description and the problem it is meant to address.CSV contact import with field mapping; admin onboarding checklist; Slack notifications; duplicate-record merge; custom reporting dashboard
[USER EVIDENCE]Provide research findings, support patterns, usage data, or customer requests with their source and scope.18 of 31 onboarding interviews cited manual contact setup; event data shows accounts importing 50+ contacts activate at 61%; 12 support tickets mention duplicates; Slack appeared in 4 interviews.
[CONSTRAINTS]List budget, team capacity, compliance, platform, or strategic constraints.One product squad, one backend engineer available 60% of time; SOC 2 scope cannot expand this quarter; no new data warehouse work.
[ESTIMATES AND DEPENDENCIES]Provide rough effort estimates, teams involved, and known prerequisites for each feature.Import: medium, needs validation service; checklist: small, no dependencies; Slack: medium, OAuth review required; merge: medium, needs audit trail; reporting: large, needs warehouse work.
[CURRENT METRICS]Provide current baselines for the product goal and relevant guardrail metrics.Activation 42%; median time to first project 4.6 days; support contacts per new account 1.8; data correction requests 7% of imported accounts.

How to use

  1. Replace the placeholders with a single product goal and a backlog that describes problems, not only feature names.
  2. Paste customer evidence with its sample size or source so the model can distinguish repeated evidence from a loud single request.
  3. Challenge any score marked high confidence if the source is only a sales request or anecdote.
  4. Then send: “Show the ranking again if engineering capacity falls by 25%, and explain only the decisions that change.”

Variations

RICE scoring

Use when your team already works with RICE and has estimates.

Variation
Build a RICE prioritization table for [FEATURES] against [GOAL]. Use the supplied reach, impact, confidence, and effort data in [INPUT DATA]; do not invent missing values. Calculate each score, show the formula inputs, and rank the items. Add a column explaining whether the metric evidence in [EVIDENCE] supports the impact score. Flag false precision, shared dependencies, and any feature whose score hides a material risk. End with the two assumptions most worth validating before committing.

Opportunity solution tree

Use when research points to a problem but the solution is still open.

Variation
Using [RESEARCH NOTES], create an opportunity solution tree for the outcome [OUTCOME] and users [USERS]. Separate observations, opportunity statements, solution ideas, and experiments. Include only opportunities grounded in the notes, group duplicates, and write each as an unmet need rather than a feature request. For the three strongest opportunities, suggest one low-cost experiment with a success signal and a disconfirming signal. Do not imply demand sizes or causation not present in the research.

Roadmap decision memo

Use when leaders need a short decision record.

Variation
Write a product-prioritization decision memo for [AUDIENCE] using [BACKLOG], [EVIDENCE], [CAPACITY], and [GOAL]. Limit it to 600 words. Include the decision, the selected work, explicitly deferred work, the tradeoffs, dependencies, risks, and success and guardrail metrics. Use a neutral tone and distinguish facts from assumptions. Flag any missing evidence that could reverse the decision instead of inventing a justification.

Tips

  • Use one outcome per prioritization pass; a feature cannot be honestly optimized for activation, retention, enterprise expansion, and platform reliability at the same time.
  • Treat feature requests as clues to investigate, not as a vote count; combine them with behavioral data and interviews about the underlying job.
  • Keep effort estimates coarse but comparable, and expose dependencies separately because a small feature blocked by a platform change is not a small commitment.
  • Set a guardrail alongside the main outcome, such as support volume, error rate, latency, or churn, to avoid improving one metric by damaging another.

FAQ

Which prioritization framework should I use with AI?

Use the framework your team can supply with credible inputs. RICE is useful for comparable bets, while a simple evidence-impact-effort view is better when data is incomplete.

Can AI estimate feature impact?

It can structure assumptions and point out gaps, but it should not create impact estimates. Use experiments, comparable launches, and observed behavior to supply the estimate.

How many features should be prioritized at once?

Use a manageable set, often 10–25 items. If the backlog is larger, first group duplicates and split platform maintenance from customer-facing bets.

Related prompts

All Product Management & UX prompts →

Get a few prompts like this every week

Something Big is a free AI newsletter read by 50,000+ professionals. One email a week with prompts and tools that work, plus what changed in AI and what to do about it.