What to do with user feedback that is basically just suggesting features I don't have time to build?

Hey @jcuk, best from my experience is to be honest. You absolutely need to thank them as they're taking the time to provide feedback, but if it's clear that you won't be tackling a feature then you should rip the band-aid off right away.

Saying no will help you manage your customers expectations. If you leave a feature request open then someone will start to build hope on it. It will become something you're waiting forward to have especially if it's an obscure integration. As time passes on the frustration will increase "when is this coming out?". Just let people know asap when you know you can't do something.

There's another thing: sometimes you want to do something, but it might take a bit of time to get there. In this case say "I'd love to do this, but we can't tackle it before quarter XXXX". It doesn't say you will tackle it then, but that you will reconsider it at that time.

Once quarter XXXX comes you should absolutely look back at your open ticket. Don't push things back over and over again. Just close it if it happens too often.

Hope this helps.

Keep in mind, a lot of people are making these suggestions to be helpful, not because it would critically affect if/how much they would pay you. Thank them, mark the suggestion down somewhere, and ask them if they would like to join your product updates list. =)

Usually, as things come in from our webchat or email/conversations I will add them to our user feedback roadmap widget (we use Acute / https://getacute.io/). This puts the idea out there, and other people can vote on it, and the user sees that we take it seriously, but they can also see how popular the idea is and how much we have on our roadmap. We also make sure they know we are a small team and have to ruthlessly prioritize, and usually they understand that.

Use https://www.producthunt.com/posts/prioritize made by @songthamtung. Pretty useful to prioritise tasks/features

I definitely think it's important to acknowledge the idea and thank them for the time they put into suggesting the idea - doesn't mean that you have to actually implement it. I think it's also essential that you try and understand why the user asked for that feature as that might be where you really uncover a problem and might find it actually similar to something else someone has suggested.

E.g. Let's say someone says they want a mobile app and someone else says they want to get alerted by email when an employee finish's a survey.

On the surface those two sound like completely different suggestions but under the hood, if you dig into why they want these features you might find out that the mobile app guy wants the feature because he assumed that mobile app = mobile notifications, the email guy might have also wanted to have some sort of notification that gets sent out when a survey is done. So whilst these initially sounded completely different, after digging deeper you realise both want the same problem solved - realtime notifications (you could now dig even deeper - why do they want realtime notifications?). Obivously you don't have to build this feature now, but doing this helps you uncover what problems they want solving, which with enough people suggesting the same thing IS a good indicator that it should be built. Another good question to follow up with is "How much more would you pay for XYZ if you had this feature?" (although be careful for lies) or "Is this feature blocking you from using XYZ" (good to know between nice to haves and hair on fire issues).

Basically, don't just accept the what, always ask for the why.

Paraphrasing from the book "Rework"

Don’t write it down: ”Listen, but then forget […] requests that really matter are the ones you’ll hear over and over.”

I'd write it down in a spreadsheet and take a look in it, from time to time, to see if it's worth building it or not

If I don't think their idea is valuable/important I do ask them for more information to understand why that specific feature would be useful for them. Maybe the product already has a similar feature they could use to achieve the same results.

Hey @jcuk,

I believe in the power of being transparent. As a customer, especially if I paid for your service, I would want a reply and know what the status is, eg "planned" or "not prioritized". I many cases, just feeling heard makes the customers happy and they will understand whatever you decide to do.

We built Convas.io, a service that provides a feedback page for companies to handle customer feedback. Customers can go there and upvote existing feedback and it will also help to reduce duplicates.

However, you own the roadmap and set your priorities. It's not wrong to make product decisions based on your analytics data. But why not do both?

Thank them for their input. Don't ignore them. We all know that you won't jump and build it just some random user thought it would be good for them.

however, keep note of every feedback, make some scoring, check periodically if the feature is valid, maybe some day it will be (more users demands it, you see it as logical next step etc)