{"id":1316,"date":"2019-05-14T08:40:36","date_gmt":"2019-05-14T12:40:36","guid":{"rendered":"http:\/\/blog3.canny.io\/wordpress\/?p=1316"},"modified":"2022-10-04T16:49:50","modified_gmt":"2022-10-04T20:49:50","slug":"responding-to-feedback","status":"publish","type":"post","link":"https:\/\/canny.io\/blog\/responding-to-feedback\/","title":{"rendered":"Canny best practices: responding to feedback"},"content":{"rendered":"
\n

Canny is a customer feedback tool<\/h4>\n

We help your team make better product decisions powered by customer feedback. With these best practices, you can use Canny to its fullest.<\/p>\n

Register<\/a> for your free account today!<\/p>\n<\/div>\n\n

Should we respond to all requests?<\/p><\/blockquote>\n

One of our goals with Canny is to reduce the work required for your team to get insights from feedback.<\/p>\n

For those getting feedback from a lot of people, this isn’t easy. You can show that you’re listening without spending all your time crafting responses. You can find a balance.<\/p>\n

We follow this general rule:<\/p>\n

Respond when it’s helpful for both you and your user.<\/strong><\/div>\n

Responses like “thanks for the feedback” are nice, but don’t add value to you or the person who gave feedback. It’s also time consuming to respond to every request.<\/p>\n

Here are some examples of when a response is called for:<\/p>\n

When you need more context<\/h2>\n

Oftentimes, people can be vague about their requests or problems. Usually, you need to dig deeper to understand a request.<\/p>\n

Many customers will phrase their request as a solution:<\/p>\n

I want to be able to add and customize my labels.<\/div>\n

You need to distill their request into an actual problem. Just ask them straight up:<\/p>\n

What problem are you trying to solve?<\/div>\n

Without asking and just building exactly what they ask for, you are wasting your team’s time. Is there a simpler way to solve their problem? Can a different feature solve their problem?<\/p>\n

The worst thing would be to build out the feature only to find out it’s not solving the original problem.<\/p>\n

The work you put upfront will come in handy. When your team is ready to build out that feature, you’ll have all the additional context you need.<\/p>\n

Be timely with these follow-ups if you can. It’s best to ask for extra context when it’s fresh in the mind of your user.<\/p>\n

When you need to set expectations<\/h2>\n

In general, your users should know that just because something has the most votes, does not mean it will be built. Most customers will understand this, some will not.<\/p>\n

In those cases, we respond with something like this:<\/p>\n

We appreciate your feedback. However, having the most votes does not mean we will build it for sure. Feedback is just one of the several signals that we use to prioritize what we work on.<\/div>\n

A nice thing about Canny is that it helps sets expectations for less popular posts. Your customers can see that a post with 10 votes is probably less likely to be built over a post with 100.<\/p>\n

Another common question you might hear from customers is:<\/p>\n

What\u2019s the ETA on this?<\/div>\n

In most cases, you probably don\u2019t want to give a specific date. As we all know, unexpected things are bound to come up and create delays.<\/p>\n

\n

How to correctly estimate a project's completion date:<\/p>\n

1. Analyse the factors involved and come up with a rational figure of time
2. Wrong.<\/p>\n

— I Am Devloper (@iamdevloper) December 31, 2013<\/a><\/p><\/blockquote>\n