Feature prioritization (RICE) prompt

When to use it

Use this when planning quarterly roadmap priorities across competing feature requests and you need an objective, standardized scoring method. Replace the candidate initiatives and baseline metrics with your team's real backlog data before finalizing roadmaps.

The prompt

## Role
Act as a principal product manager. Apply professional judgment while keeping your scoring logic transparent to engineers, designers, and business stakeholders.

## Context
KiteDesk is a B2B customer support platform serving 1,400 mid-market help desks. The team must prioritize four Q3 roadmap candidates: (1) AI response auto-complete, (2) native WhatsApp messaging channel, (3) customizable SLA breach alerts, and (4) bulk ticket export to CSV/Snowflake. Engineering capacity is limited to 12 person-weeks for the quarter.

## Objective
Evaluate and rank all four candidate features using the RICE framework (Reach, Impact, Confidence, Effort) to determine the Q3 engineering commitment.

## Audience
The primary readers are product managers, engineering leads, and executive stakeholders. Make the output decision-ready, with clear numerical rationale and no theoretical lectures on product frameworks.

## Requirements
Score each feature across Reach (events or users/quarter), Impact (0.25 minimal to 3 massive), Confidence (50% low, 80% medium, 100% high), and Effort (person-weeks). Calculate the RICE score: (Reach × Impact × Confidence) / Effort. Provide a ranked comparison table, a 2-sentence rationale per feature, and an audit of sensitivity to key estimates.

## Constraints
Do not invent unlisted features, external user interview quotes, or unsupplied platform metrics. Use only the provided capacity cap (12 person-weeks). Clearly flag any confidence score below 80% with the specific uncertainty driving it.

## Tone & style
Be analytical, concise, and decisive. Prefer structured tables and crisp bullet points over narrative prose. Avoid corporate buzzwords and unquantified modifiers like "game-changing" or "frictionless."

## Output format
Present the ranked RICE scorecard table first, sorted by score descending. Follow with the rationale and trade-off notes for each candidate. Conclude with a recommendation for what fits within the 12-week budget and a checklist of assumptions to validate with engineering.

## What to avoid
Avoid arbitrary round numbers without supporting units, tied scores without tie-breaking justification, and ignoring effort overruns that breach the capacity constraint.

## Success criteria
The product team can clearly defend why the top-ranked features were chosen over the excluded ones based on quantifiable Reach, Impact, and Effort within the 12-week limit.

## Clarifying questions
Ask up to three focused questions only if missing technical scope would invalidate the effort estimates. Otherwise, proceed using standard B2B SaaS benchmarks, state your assumptions, and highlight what requires engineer sign-off.

Why it works

• The scenario sets explicit capacity limits (12 person-weeks) and distinct candidate features rather than abstract ideas.
• The requirements enforce a standardized RICE formula and explicit scoring scales to eliminate arbitrary rankings.
• The constraints prevent overpromising team velocity and highlight low-confidence assumptions before roadmaps get locked.
• The success criteria ensure the final recommendation is immediately defensible in front of engineering leads and leadership.

Make it yours

Build a tailored version with PromptDeck by replacing the fictional scenario with your own backlog items, user counts, and team velocity. Keep the validation steps to ensure your engineering partners agree with the effort estimates before development starts.