We're often asked the question: "How do you say no to feature requests?"
Using Receptive makes a huge impact on our ability to understand why our customers want specific features, be transparent in explaining our position behind turning down requests, and do that with an open, appreciative tone.
Without Receptive, this process would look very different!
So how do we do it?
Some requests are turned down right away for several reasons. For example, if they're in direct conflict with our strategy or they're a bug or a duplicate. The rest are moved to "Awaiting feedback" where we gauge demand from our customers, internal teams, and prospects.
After a period of time under this status, any requests that haven't bubbled to the top of our SmartLists will be turned down. See examples below. (Feel free to save these as your own custom saved responses.)
In this article:
- Initial review
- Move to "Awaiting Feedback"
- Examples of ways to say no to feature requests
- Other tips
Before any decisions are made on any requests, we do an initial review for:
1. Requests that aren't clear
Because of how Receptive works, customers and team members are usually very clear when submitting requests. But for anything that could be misunderstood or we don't know what the actual pain point is behind the request, we ask for clarification.
If the customer doesn't respond with a clear explanation, here's an example response to use when declining the request:
"We have to decline this request as we didn't get a specific enough use case or reasoning behind the request. If you would like this feature at any point in the future, please provide more feedback on what you're trying to accomplish and why this is important to you so our product team can re-review."
2. Requests that are in conflict with our vision & strategy
Another thing we look out for when requests initially come in is whether they're in direct conflict with our vision & strategy. For example, we get a lot of requests from new users about adding complexity to the flow of managing feature requests in Receptive. We tread very carefully here, as one of our core beliefs is that product managers shouldn't spend their time on manual processes.
If a feature is in direct conflict, we'll decline it and explain why. Sometimes we're specific with our reasoning, and sometimes we use a saved response. Here is a real example of each:
"I think we're pretty committed to the want / don't want binary choice. It's not that "don't want" is actually hindering a feature's likelihood of being developed, it just tells Receptive not to asks the feature to the person that clicks."
"Out of scope, we just don't think that this is somewhere that we're taking our product."
Bugs are occasionally submitted to Receptive. We decline them with an explanation and add to Github:
"This is a bug, rather than a feature that we can build"
"This is either a bug or a specific browser weirdness, we'll investigate as a bug."
"This is a bug we're investigating now."
4. Features that already exist
Sometimes features are submitted that have already been released, but the customer approached the feature from a new angle so it slipped through the "similar features" filter.
"This has been released for a while now, in the browse view you can filter by tag"
"This feature exists, it might not be super-obvious how to do it though. Go to..."
"We've already implemented this functionality. Instructions on how to do this here: __"
"This feature already exists, you have to select the status again. Perhaps could submit a more specific request, but I'm going to decline this"
Duplicates are rarely submitted, but we can easily merge any that slip through. Learn how to merge features here.
"Duplicate, I'm declining this as we've got this covered in another feature request: #123xxx"
Move to "Awaiting Feedback"
After the initial review, we tend to move most of the remaining features to "Awaiting feedback". This status means the features are under consideration but will gather further customer / team feedback until a decision is made.
See how Beatroot quickly discovered that many of their “backburner” features were actually some of the most important.
Examples of ways to say no to feature requests
With Receptive, you have the data to back up your decisions so it's easier to explain why a feature won't make it onto the roadmap. Here are some common reasons for declining features, with example responses:
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."
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!