Feature Request Intake Template

The same way you handle every other request: through the intake process. Executives get the same form, the same triage, and the same prioritization. The difference is in communication, not process. Acknowledge the request faster (within hours, not days). Provide the decision rationale directly in a 1:1, not via an automated email. If you bypass the process for executive requests, the process loses credibility.

Reclassify it. If the product is not working as designed, it is a bug and goes into the bug tracking workflow. If the product is working as designed but the design is wrong, it is a feature request. The distinction matters because bugs have different SLAs and prioritization criteria than feature requests.

It depends on your product size and customer base. A B2B SaaS product with 200+ customers typically generates 20-50 requests per month. If you are getting fewer than 10, your intake channel is too hidden or too high-friction. If you are getting more than 100, you need better categorization and possibly automated triage for common requests.

Voting can be a useful signal, but it should not drive priority. Votes are biased toward power users who engage with your feedback portal. They under-represent new users, churned users, and prospect needs. Use vote counts as one input alongside ARR impact, strategic alignment, and effort estimates. Never promise to build the top-voted feature.

Decline when the request does not align with your [product strategy](/glossary/product-strategy), when the user problem is real but affects too few users to justify the investment, or when a better solution exists. Provide specific reasoning. "We are declining because this serves fewer than 1% of users and requires 3 weeks of engineering time" is honest and defensible.