Feature Request Scoring Template

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.

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.

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.

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. ---