TemplateFREE⏱️ 30 minutes setup, 5 minutes per request scored
Feature Request Scoring Template
A template for scoring and prioritizing feature requests using weighted criteria. Includes request intake, scoring rubrics, a stack-rank output, and a...
Updated 2026-03-05
Feature Request Scoring
| # | Item | Value (1-10) | Effort (1-10) | Score | Priority | Owner | |
|---|---|---|---|---|---|---|---|
| 1 | 3.0 | ||||||
| 2 | 2.5 | ||||||
| 3 | 1.8 | ||||||
| 4 | 1.2 | ||||||
| 5 | 1.1 |
#1
3.0
#2
2.5
#3
1.8
#4
1.2
#5
1.1
Edit the values above to try it with your own data. Your changes are saved locally.
Get this template
Choose your preferred format. Google Sheets and Notion are free, no account needed.
Frequently Asked Questions
How often should I score feature requests?+
Bi-weekly works for most teams. Weekly scoring is too frequent (you end up scoring requests individually instead of in context). Monthly is too slow (requesters wait too long for a response). Score in batches of 5-15 requests. Comparing them side by side produces better calibrated scores than evaluating one at a time.
What if a high-value customer demands a feature that scores low?+
The score is an input, not a verdict. If a $200K account threatens to churn over a low-scoring feature, escalate it as a business decision, not a product decision. Document the exception and the reasoning. But do this rarely. If you override the scoring framework for every large account, you are building a custom product for 5 customers instead of a scalable product for 500.
Should internal stakeholder requests go through the same process?+
Yes. Internal requests (from sales, marketing, CS, engineering) should be scored using the same rubric. This prevents HiPPO-driven prioritization where the loudest internal voice wins. Internal stakeholders who see their requests scored objectively tend to submit better-evidenced requests over time.
How do I handle requests that are actually bugs?+
Separate bugs from feature requests. A bug is "something is broken." A feature request is "something is missing." Bugs go to the engineering triage process with severity ratings (P0-P3). Feature requests go through this scoring process. If the line is blurry (a "missing" feature that users expect to exist), classify it based on user perception: if users say "this is broken," treat it as a bug. ---
Related Tools
RICE Score Calculator
Score features using Reach, Impact, Confidence, and Effort.
ICE Score Calculator
Prioritize with Impact, Confidence, and Ease — fast and lightweight.
WSJF Calculator
Weighted Shortest Job First scoring for SAFe and Lean teams.
MoSCoW Prioritizer
Categorize features into Must, Should, Could, and Won't have.
Explore More Templates
Browse our full library of PM templates, or generate a custom version with AI.