Working Product Managers need feature prioritization decisions out the door fast. These 25 prompts generate stakeholder-ready frameworks, scoring models, and communication materials you can use immediately.
These prompts pair well with Jasper AI for Product Managers-specific tone control, or Copy.ai for fast iteration.
RICE Framework Implementation
You are a Senior Product Manager creating a RICE scoring analysis for quarterly planning.
Product: {product_name} Quarter: {quarter_year} Features under consideration: {feature_1_name_and_brief_description} {feature_2_name_and_brief_description} {feature_3_name_and_brief_description} {feature_4_name_and_brief_description} {feature_5_name_and_brief_description} Current user base: {monthly_active_users} Engineering capacity: {developer_weeks_available} Business priority: {revenue_growth / user_retention / market_expansion}
Create a RICE scoring table with numerical scores for each feature. Include your reasoning for Reach estimates (% of users affected), Impact ratings (3=massive, 2=high, 1=medium, 0.5=low), Confidence percentages, and Effort estimates in developer weeks. Format as a clean table with final RICE scores ranked highest to lowest. Add a 150-word recommendation paragraph explaining the top 2 features to build and why.
When to use it: Tuesday morning before your weekly roadmap review when stakeholders are asking “what’s the data behind these priorities?”
Pro tip: Always include your confidence reasoning—stakeholders trust scores more when you explain why you’re 70% vs 90% confident on impact estimates.
You are a Product Manager defending feature prioritization to skeptical engineering leadership.
Controversial feature: {feature_name} RICE score: {numerical_score} Engineering concern: {technical_debt / complexity / resource_drain} Competing priority: {alternative_feature_name} Supporting data: {user_research_summary_or_metrics} Timeline pressure: {launch_deadline_or_constraint} Stakeholder pushing back: {engineering_manager / CTO / lead_developer}
Write a 400-word email defending this feature using RICE methodology. Lead with respect for their concerns. Present the scoring breakdown with specific numbers. Address their technical worry directly with mitigation strategies. Close with a compromise proposal that acknowledges constraints while protecting the business case.
When to use it: When engineering pushes back on your roadmap decisions and you need a data-driven response that doesn’t sound defensive.
Pro tip: Always propose a technical compromise—reduce scope, phase the rollout, or adjust timeline rather than just defending your original plan.
You are a Product Manager simplifying RICE scoring for non-technical executives.
Executive audience: {CEO / CMO / Head_of_Sales / Board_member} Their background: {technical / business / financial} Features being compared: {feature_A_name} vs {feature_B_name} Feature A RICE score: {score_A} Feature B RICE score: {score_B} Business context: {competitive_threat / revenue_opportunity / user_churn_issue} Their main concern: {timeline / budget / market_timing} Meeting format: {email_update / presentation_slide / verbal_brief}
Create a 200-word executive summary explaining why Feature A scored higher using RICE. Avoid PM jargon. Focus on business impact and user numbers they care about. Include one specific metric that proves the scoring. End with the resource requirement and timeline implication.
When to use it: Friday afternoon when your CEO asks “why are we building X instead of Y?” and you have 5 minutes to explain.
Pro tip: Lead with the business metric they mentioned in the last all-hands—revenue, users, market share—then tie your RICE score back to that number.
You are a Product Manager running a live RICE scoring workshop with cross-functional stakeholders.
Workshop participants: {sales_rep / designer / engineer / customer_success / marketing} Feature being scored: {feature_name_and_description} User base size: {total_addressable_users} Sales input: {customer_demand_level} Engineering input: {complexity_estimate} Design input: {user_experience_concern_or_opportunity} Customer Success input: {support_ticket_volume_or_user_feedback} Time limit: {30_minutes / 45_minutes / 1_hour}
Create a facilitation script for scoring this feature live. Include specific questions to ask each stakeholder for Reach, Impact, Confidence, and Effort. Provide pushback questions when estimates seem too optimistic or pessimistic. End with a clear final score and next steps. Keep it conversational and time-boxed with specific minute markers.
When to use it: When you need buy-in on prioritization decisions and want stakeholders to own the scoring process, not just receive your conclusions.
Pro tip: Ask for effort estimates in ranges (2-4 weeks) then negotiate to a single number—people are more honest with ranges but you need specifics for RICE.
You are a Product Manager documenting RICE scoring decisions for future reference.
Quarter: {Q1_Q2_Q3_Q4} {year} Team: {team_name} Features scored: {feature_1}, {feature_2}, {feature_3} Winning feature: {selected_feature_name} Final RICE score: {numerical_score} Key assumptions made: {user_adoption_rate / technical_complexity / market_timing} Dissenting opinions: {who_disagreed_and_why} Success metrics planned: {how_you_will_measure_if_RICE_was_right}
Write a 300-word decision log entry capturing this RICE prioritization. Include the final scores, key debates, and assumptions that could prove wrong. Format as a structured doc entry that future you can reference in 6 months. Focus on the “why” behind controversial scoring decisions and what evidence would change your mind.
When to use it: Right after a heated prioritization meeting when you need to document decisions before context gets lost.
Pro tip: Record who disagreed and their specific concerns—when features underperform, this context helps you improve future RICE scoring accuracy.
Value vs Effort Matrix Creation
You are a Product Manager creating a value-effort matrix for a feature backlog review.
Product area: {core_product / new_initiative / technical_debt} Stakeholder audience: {engineering_team / executive_leadership / design_team} Features to plot: {feature_1_with_brief_description} {feature_2_with_brief_description} {feature_3_with_brief_description} {feature_4_with_brief_description} {feature_5_with_brief_description} Business goal: {increase_revenue / improve_retention / reduce_churn / gain_market_share} Engineering capacity: {team_size_and_sprint_length} Timeline constraint: {launch_deadline_or_business_driver}
Create a value-effort matrix placing each feature in the appropriate quadrant (Quick Wins, Major Projects, Fill-ins, Thankless Tasks). For each feature, provide a 2-sentence justification for its placement including specific value and effort reasoning. End with a prioritized implementation order and timeline for the next 3 months.
When to use it: When your backlog has grown to 20+ items and stakeholders need a visual way to understand why you’re choosing certain features first.
Pro tip: Put at least one feature in each quadrant even if it’s a stretch—stakeholders trust matrices more when they see balanced distribution rather than everything clustered as “high value, high effort.”
You are a Product Manager defending a “low value, low effort” feature that stakeholders want to skip.
Feature in question: {feature_name} Why it seems low value: {limited_user_base / small_revenue_impact / edge_case_solution} Why it’s actually strategic: {competitive_parity / user_retention / technical_foundation} Effort required: {hours_or_days_estimate} Stakeholder pushing to skip: {engineering_lead / product_director / CEO} Upcoming business event: {product_launch / sales_demo / customer_meeting} User segment affected: {power_users / enterprise_customers / free_tier}
Write a 250-word Slack message or email explaining why this “fill-in” feature deserves a spot in the next sprint. Lead with the strategic reason, not the effort argument. Include one specific user story or business scenario where this feature prevents a bigger problem. Suggest a minimal implementation that delivers the core value.
When to use it: When you’re getting pushback on small features that seem insignificant but solve important edge cases or unblock larger initiatives.
Pro tip: Frame low-effort features as “insurance” against bigger problems rather than standalone value—stakeholders understand risk mitigation better than incremental improvements.
You are a Product Manager presenting a value-effort matrix to executives who want everything in the “high value” quadrant.
Executive audience: {CEO_and_VPs / Board_of_Directors / Investor_update} Their expectation: {aggressive_growth / quick_revenue_wins / market_leadership} Reality check needed: {limited_engineering_resources / technical_constraints / market_timing} High-value, high-effort features: {feature_A}, {feature_B} Quick wins available: {feature_C}, {feature_D} Resource constraint: {team_size / budget_limit / timeline_pressure} Competitive pressure: {rival_product_feature / market_window / customer_demands}
Create a 350-word presentation narrative that walks through the matrix while managing expectations. Start by acknowledging their growth goals. Explain why high-value features require significant effort using specific examples. Propose a portfolio approach mixing quick wins with major investments. Include a timeline showing how quick wins fund and support bigger bets.
When to use it: In quarterly planning meetings when leadership wants to prioritize everything and you need to communicate resource reality without killing ambition.
Pro tip: Always show how quick wins create the foundation or user base needed for major projects to succeed—it’s not just about resource management, it’s about strategic sequencing.
You are a Product Manager facilitating a value-effort calibration session with your development team.
Team composition: {frontend_devs / backend_devs / fullstack_devs / designer / QA} Features being calibrated: {feature_1_name} {feature_2_name} {feature_3_name} Previous effort estimates that were wrong: {underestimated_feature / overestimated_feature} Team’s current velocity: {story_points_or_features_per_sprint} Technical debt concerns: {legacy_code / infrastructure / testing_gaps} External dependencies: {third_party_integrations / API_changes / design_assets}
Write a meeting agenda and facilitation script for a 45-minute session to recalibrate effort estimates. Include specific questions to uncover hidden complexity. Provide a framework for distinguishing between “development effort” and “total effort including testing, deployment, and monitoring.” End with agreed-upon effort scales and definitions the team will use going forward.
When to use it: After a sprint where your effort estimates were significantly wrong and you need to recalibrate the whole team’s understanding of complexity.
Pro tip: Ask developers to estimate in t-shirt sizes first, then convert to hours—it prevents anchoring bias and reveals where people have genuinely different complexity assumptions.
You are a Product Manager communicating value-effort decisions to a stakeholder whose pet feature was deprioritized.
Stakeholder: {sales_director / customer_success_manager / marketing_head / key_customer} Their deprioritized feature: {feature_name} Why they care: {customer_request / competitive_gap / revenue_opportunity / internal_efficiency} Where it landed on matrix: {high_effort_medium_value / low_value_low_effort / high_effort_low_value} What got prioritized instead: {winning_feature_name} Their likely objection: {customer_promised_it / revenue_impact / competitive_threat} Timeline when it might happen: {next_quarter / next_half / next_year}
Draft a 300-word email explaining the prioritization decision. Acknowledge the value of their feature specifically. Explain the effort reality and what got prioritized instead using business terms they care about. Offer a compromise: a smaller version, a workaround, or a clear timeline for reconsideration. End with how they can help strengthen the case for future prioritization.
When to use it: When you have to tell someone their feature didn’t make the cut and you need to preserve the relationship while standing by your decision.
Pro tip: Always offer them a role in strengthening the business case—more user research, customer interviews, or success metrics—rather than just saying “maybe next time.”
Kano Model Application
You are a Product Manager conducting Kano analysis for a major product decision.
Product: {product_name} User segment: {target_user_type} Features being analyzed: {feature_1_name_and_description} {feature_2_name_and_description} {feature_3_name_and_description} {feature_4_name_and_description} User research data: {survey_results / interview_insights / usage_analytics} Competitive context: {what_competitors_offer / market_expectations} Resource constraints: {development_timeline / budget_limits} Business goal: {user_satisfaction / competitive_differentiation / market_expansion}
Classify each feature as Must-Have, Performance, or Delighter using Kano methodology. For each classification, provide specific user evidence and explain the satisfaction curve implications. Create a 200-word implementation recommendation prioritizing Must-Haves, optimizing key Performance features, and selecting one Delighter that offers competitive advantage.
When to use it: When you’re planning a major release and need to balance user satisfaction with development effort across different types of features.
Pro tip: Look for features that are Delighters today but will become Must-Haves in 12-18 months—that’s your competitive moat window.
You are a Product Manager explaining why a requested feature is actually a Must-Have, not a nice-to-have.
Feature: {feature_name} Stakeholder who sees it as optional: {engineering_manager / CEO / design_lead} User evidence: {support_tickets / user_interviews / churn_analysis} Competitive reality: {industry_standard / regulatory_requirement / user_expectation} What happens without it: {user_frustration / competitive_disadvantage / operational_cost} Implementation complexity: {technical_challenges / resource_requirements} Timeline pressure: {launch_deadline / competitive_window}
Write a 300-word case study using Kano methodology to prove this is a Must-Have feature. Include specific user quotes or data points showing dissatisfaction when absent. Reference competitor offerings as market proof points. Calculate the cost of not building it versus the cost of building it. End with a clear recommendation and timeline.
When to use it: When stakeholders want to cut a feature you know will hurt user satisfaction, and you need framework-backed evidence to defend it.
Pro tip: Find one direct competitor who lacks this feature and show their user complaints or reviews mentioning it—external validation strengthens your Must-Have argument.
You are a Product Manager identifying Delighter opportunities from user feedback.
Recent user feedback sources: {customer_interviews / support_tickets / app_store_reviews / user_surveys} Unexpected positive mentions: {feature_or_interaction_users_loved} User pain points mentioned: {frustration