How to Say No to Feature Requests (Without Losing Customers)

You can't build everything, and trying to will wreck your product. Saying no is a core product skill — but how you say it decides whether a user feels dismissed or respected. Here's a framework that declines requests while keeping goodwill.

1. Acknowledge the problem, not just the request

People rarely want the exact feature they asked for — they want the underlying problem solved. Start by restating the problem so they feel heard: "You're trying to get your data into a monthly report faster — makes sense."

2. Be honest about why not

Give a real reason: it's off-strategy, low-demand, or too costly relative to impact. Users respect candor far more than vague "we'll consider it" replies that never go anywhere.

3. Offer an alternative or a workaround

A "no" lands softly when paired with a path forward — an existing workaround, an integration, or "here's what we're doing instead that should help."

4. Make the decision transparent

Do it in the open on your feedback board. Marking a request "Not planned" with a short note means everyone who wanted it sees the reasoning — and you never have to answer it again. Transparency turns a rejection into a demonstration that you're thoughtful about the roadmap.

Example wording

"Thanks for this — the goal of faster reporting is a real one. We're not planning a built-in export right now because it affects a small share of users and our focus this quarter is X. In the meantime, [workaround] should cover most cases. We'll revisit if demand grows, so upvotes here genuinely help us track it."

A public voting board makes this easy: FeatureFest lets you decline requests transparently and lets demand (via votes) inform what you revisit — free to start.