DEV Community

Cover image for How to Collect, Curate (and Ignore) Customer Feedback in Your Product Development Process
Devs @ 7pace for 7pace

Posted on • Updated on

How to Collect, Curate (and Ignore) Customer Feedback in Your Product Development Process

Collecting and implementing feedback can seem like a pure positive for product teams. Of course you want to listen to your customers and then meet their needs, right?

The problem is that customers, in many cases, are just dead wrong.

It’s incredibly difficult for people to know what they want unless they see it and experience it first.

That doesn’t mean we should ignore their feedback, but it means that we need to be careful about how we collect and implement customer feedback.

Too many organizations build processes around customer feedback that don’t have the proper mechanisms in place to filter it and plan toward its implementation. It’s just a fire hose of complaints and nice-to-haves.

The process becomes a constant treadmill with product teams chasing ever-changing customer expectations that may or may not align with any kind of overarching company goals or product strategy.

User feedback cannot become the only mechanism that drives product development decisions.

As enticing as it may seem to be super responsive to customer feedback, this is a reactive process. First, come to terms with reality. Unless your product is dead or dying, you will never stop receiving user feedback. This is a never ending cycle–and it should be.

So how do you incorporate this feedback without letting it run amok and take over everything your team holds dear? Well, you should start with a plan.

Developing a Product Development Roadmap and Strategy

The number one mistake that teams make is assuming that simply listening and responding to customer feedback can constitute some kind of a coherent product roadmap or strategy.

Let’s put that to bed. It can’t.

A pile of customer complaints isn’t a roadmap.

Alt Text

Yes, feedback should be incorporated as part of that planning—but it falls well short of all of the inputs that you need. The plan for your development should be driven by a number of factors:

  • Strategic initiatives
  • Overarching business goals
  • Competitive analysis
  • Market/industry trends
  • Customer feedback

Really, the way to think about the role of customer feedback is a guiding hand on the wheel. It shouldn’t be allowed to chart the entire course, but it might be able to help you navigate unfamiliar waters.

Or, to cut the metaphors, your team should use customer feedback as one of the mechanisms that guides the priority and implementation of your plan, but doesn’t dictate the plan itself.

In order to accomplish this, you need to then have the proper mechanisms in place to capture, catalog, and implement that feedback.

How to Capture Robust Customer Feedback

Let’s talk about how you wrangle feedback from customers.

It can feel a bit like opening the floodgates.

Yes, you are going to get a lot of noise. And, yes, you will probably end up ignoring a good chunk of it. But capturing a steady stream of feedback from various sources is still a good way to keep a pulse on how customers are receiving the product and features that your team is building and shipping.

You need a feedback loop. Otherwise your job would just be too damn easy, wouldn’t it?

So, some strategies for gathering and formalizing that feedback include the following.

1. Voice of Customer (VOC) program

There are a lot of opinions and guides on what these programs look like. But, in a nutshell, you have a person or team of people are own the function of speaking for the customer.

This person or team conducts interviews, surveys, and collects other types of feedback. They synthesize it down, and then they “represent” the customer’s interests, needs, and wants in any discussion about product development, roadmap, priorities, and the like.

In theory, this is a perfect solution.

In reality, it’s a bigger investment than many teams can make. So, there are tactical ways to get some of this accomplished, without having a full-blown VOC program or team.

2. Workshops and interviews

Even if you don’t have a formalized VOC program, you can still conduct workshops or interviews with your customers. Focus on uncovering their needs and use cases, delving into how they use your product and what functionality would help them do their jobs better.

Unstructured conversations with customers can lead to major insights. But they do require an outlay of time (and possibly resources) to make it happen.

From these interviews, create a backlog of the feedback and input that you receive. Again, it’s important not to take one interview as gospel and rush back to the team demanding that you prioritize the feedback of a single customer.

Instead, take a deep breath.

If you do these interviews well, you will learn a lot in each instance. But not every takeaway can be a priority.

Take this feedback and incorporate it into the product planning process. Give it weight within the discussion about new features or prioritizing the backlog. But, do not–I repeat, do not–throw it on the top of the pile and neglect all of the other items and priorities that are already in queue.

3. Support team

Don’t neglect your support team for their wealth of knowledge and feedback from customers.

They deal with customer questions and complaints all day and they can provide guidance as to which issues and requests they’re seeing most frequently. That’s another data point to add to the product discussion.

Invite a member of the support team to relay this information to product management, then, again, incorporate that feedback in a structured way that doesn’t entirely derail the larger thinking and strategy.

4. Reviews

Lastly, mining customer reviews can also give you insight into how people are feeling about your product. Looking at positive and negative reviews can all be helpful. While detractors may point out flaws in your product and give you some places to improve, reading between the lines of a positive review may offer insight as well.

Positive reviewers often mention the features that they use most and neglect to mention the items that make less of an impact on them. That’s helpful data to collect.

When looking at product reviews, ask yourself a few questions:

  • Which parts of the product are mentioned most often?
  • Which parts of the product are not mentioned at all or least often?
  • Does the review reveal anything about the way the customer is using the product?
  • How closely does the language of the review align with internal thinking and discussion about the product and its capabilities?
  • Are there specific items in the review that seem to indicate a gap in key features or functionality?
  • Do certain types of users leave similar feedback that would indicate a key customer group is having the same (good or bad) experience?

Turning Feedback into Action Items (Or Not)

Collecting feedback is important. Incorporating that feedback is more important.

If customer feedback is steel ore, then what you really want to do is take that feedback, smelt it down, hammer it into shape, and turn it into a sword that you can wield in battle.

That might be an extended metaphor. But, here’s my point: You need to take raw customer feedback, filter it, and then translate it into actionable items that your product and development teams can act upon.

First, it’s important to realize that some feedback may not be useful or relevant.

Just because one customer complains about the way a button looks does not mean that your team should prioritize changing the button to appease that person. It’s about looking at the trees and seeing the forest.

What are the broad trends and important themes in the feedback you’re receiving?

Then, what action items need to be created in order to address that feedback?

Here are some basic steps that you can take:

  • Collect the feedback from one or multiple sources
  • Categorize the feedback into themes or areas
  • Assess each feedback item based on urgency, importance, volume/value of customers affected, feasibility (can this actually be fixed or changed?)
  • Select the highest-rated items to turn into tasks
  • Collect as much additional context as possible on the feedback and what a proper solution would look like
  • Develop a brief, spec, or user story that can be relayed to the development team and includes the context of the feedback, what makes it important, and what an ideal solution would look like.

And, the last part of this process is to fold this feedback into your broader product management/planning process.

We’ve already covered this, but feedback is just one of many competing factors that should steer your product decisions. Whether you’re using it as a mechanism for planning product improvements or you’re letting it guide the discussion on scoping and implementation, the most important aspect of your feedback program is the ability to analyze and curate the flow of comments and ideas–distill it down into something useful and actionable. Weigh all feedback against other priorities and make strategic decisions about the urgency and importance of each one.

When you do that, you won’t end up on a ship overrun with pirates headed straight for the beach.

Alt Text

7pace Timetracker is the only integrated, professional time management solution for teams using Azure DevOps.

Alt Text

Top comments (1)

use_response profile image
Anna Kuzma

Totally agree with you that simply listening and responding to customer feedback can't build a product roadmap or strategy. A company should have a system for collecting, categorizing, and prioritizing incoming feedback. There can actually be more sources of feedback like feedback from social media, forums, contact forms, blog comments, emails, chatbots, internal feedback... The fact is that customers need a convenient place to leave feedback and feature requests, this can be in-app feedback, feedback widget or feedback community that can be organized with a tool like this: Such specialized feedback tools not only help to organize feedback collection, categorization but also get quantitative and qualitative information for building product development roadmaps.