loading words...

Apr 17, 2019 16:24:11

Responding to feedback

by @hum | 674 words | 🐣 | 215💌

Sarah Hum

Current day streak: 0🐣
Total posts: 215💌
Total words: 107318 (429 pages 📄)

Should we respond to all requests?

One of our goals with Canny is to reduce the work required for your team to get insights from feedback. For those getting feedback from a lot of people, this isn't easy. There's a balance between showing you're listening and getting overwhelmed by the amount of feedback you're getting.

We follow this general rule:

Respond when it's helpful for both you and your user.

Responses like "thanks for the feedback" are nice but don't really add value to you or the person who gave feedback.

Here are some examples of when a responses is called for:

When you need more context

Oftentimes, people can be vague about their requests or problems. Canny's job is not to tell you what to build. Usually, you need to dig deeper to understand a request.

What problem are they actually trying to solve? Can this be solved in a different way? Can it be solved with a different feature?

The work you put upfront will come in handy. When you're ready to build out that feature, you'll have all the additional context you need.

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.

When you need to set expectations

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.

In those cases, we respond with something like this:

“We absolutely 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.”

On the other hand, a nice thing about Canny is that it almost automatically 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.

Another common question you might hear from customers is:

“What’s the ETA on this?”

In most cases, you probably don’t want to give a specific date. As we all know, unexpected things are bound to come up to create delays. Ideally you under promise, over deliver—not the other way around. As a general rule, multiply your estimates by three.

Most of the time, we don’t give a specific estimate:

“We do not have an estimate for this feature at this time. We’ll be sure to update you when we do!”

The great thing about Canny vs. email is, you can post an update once that everyone can see.

When you have updates to share

This is the fun part! Your customers spent time to give your team feedback—close the feedback loop when you can. Your customers will appreciate it and it will reflect well on your company brand.

Canny has built-in status updates for certain phases of a request. They are great checkpoints you can use to keep your customers engaged and excited.

  1. Under Review: We're considering building this
    For times when you might need more insight on a request. Setting an "under review" status gives it a bit more visibility so you can get more feedback before deciding to prioritize something.
  2. Planned: We're going to build this
    Use this time to collect customer anecdotes that will help you scope out a project. Doing this research ahead of time ensures the product team has everything they need to execute.
  3. In Progress: We're building this now
    Your customers will love to see this status! If you want to run a beta test, this might be a good time to ask if people are interested in participating.
  4. Complete: We've built this!
    The ultimate status—celebrate your new update! You've successfully brought something from feedback, to roadmapping, to completion. Let your customers know by changing the status and updating your Canny changelog.

Originally published at canny.io

From Sarah Hum's collection:

contact: email - twitter / Terms / Privacy