Info iconLetter I in a circle

By continuing to use this site you consent to the use of cookies in accordance with our cookie policy

The when and where of product feedback

Main illustration: Dylan Lathrop

Most product feedback is categorized by what was said, and occasionally who said it.

But there’s more to it than that. When and where it was said is information you can’t afford to ignore.

The new and the old are different

It’s a given that customers can only give useful product feedback on products they have used. New users can’t fairly assess your product, or tell you what you need to build next. But they can give great insight into your onboarding.

So when new users insist a certain feature is missing, or isn’t working properly, bear in mind this is their first rodeo. Knee-jerk reactions shouldn’t be the core of your product feedback.

Likewise, a lifelong user’s feedback will be skewed by how they’ve adapted themselves, their team, and their workflows around your product, warts and all. This type of feedback is not necessarily invalid, but it’s certainly atypical.

So when you hear your biggest product issue is a missing configuration of an obscure feature you’ve planned to sunset, or that “the old layout was better”, understand this isn’t coming from your typical user.

Where matters

When a customer asks about a feature, it’s easy to tag these queries as “missing feature” or “customer unaware how to add team”, and move on. But where in your product that question was asked carries valuable information.

A quick-fix to the above situation is to have your support team reply with a pre-canned response: “Go to the Team Configuration page.” The real solution is to ensure the feature is findable (and preferably usable) where customers are asking for it.

So when you’re getting good product feedback, make sure you’re recording the basics.

  • Who is the user – are they a free or paying customer? Active or inactive?
  • When did they say this – was it on their first session? Or their 300th?
  • What are they saying – was it a feature request? Or a bug report?
  • Where are they saying it – was it on the “teams” page? Or on the “new project” page?
  • How are they saying it – are they positive or negative? Patient or urgent?

Every piece of feedback contains so much information. It’s a mistake to only index on one.