We're often asked the question: "How do you say no to feature requests?"
The process we use to quickly triage any incoming requests essentially consists of moving them all to "Awaiting Feedback" and then letting users vote and comment on those requests.
We then have roadmapping meetings as needed to discuss the top requests.
You can learn about our recommended process in full here.
If you're in a roadmapping meeting and you've decided that you don't want to build a certain request, here are some example responses to help you say no.
Don't forget that Receptive gives you the data you need to back up your decisions.
You just need to explain the why.
Examples of ways to say no to feature requests
1. Low demand
You can't please everyone, and you have to work on features that move your business forward. If there's just no demand, we explain:
"We don't think there's enough demand from our customers, and we've got to focus on where we can help the most customers."
Sometimes, the request is more subjective and we can easily offer a more detailed explanation. Your customers understand you're balancing other requirements and will appreciate hearing your perspective. Examples:
"The edit UI is on the left as the roadmap can be very wide, and so it overflows the screen on the right, which I think is the expected side. But I'm left-handed, so I could be biased."
"I don't like to force new tabs on people too often, I see it as a necessary evil on marketing sites etc but the back button works pretty good for this use case"
2. Edge case scenarios
"It's quite an occasional activity, in my book"
"Sounds like [alternative solution], so there doesn't seem to be a good case for building this now."
"Too much of an edge case"
3. Future releases will eliminate the need
In this case, you're declining a feature but you're saying yes to the requester:
"Going to decline this, as we've got a bunch of reporting improvements coming and they are going to give you much more detail about "why" a feature is getting ranked high/low in the reports."
4. Low value / high effort
Some features are much more complicated to build than they seem, with low value and demand. If this is the case, don't be vague, just explain so the customer can see your point of view:
"I think this is a tricky one, for example what if the users haven't been created at the time that the features are imported? We'd then have to later merge the user records together. Declining this."
5. Too vague
Sometimes a request is too vague and so half of it ends up complete and the other half left in limbo with nobody entirely sure what it means. Make it clear that it's too vague:
"Declining. This request has been around for a while now, and its a bit too vague, I think its become slightly "all things to all people."
1. Offer a workaround
"The best way to do this is..."
2. Encourage engagement
It sounds obvious, but be sure to use Receptive to learn more about what your customers want. If you're building a new product, you can let a lot more features make it to the "awaiting feedback" stage to gather more feedback.
And when moving a feature to that status, encourage your teams and customers to add their use cases by asking specific questions in the status message and/or comments section.
Have you discovered a great way to respond to feature requests? Share them below!