No spam, no B.S.
Unsubscribe if you’re not happy.
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.
The quote often attributed to Henry Ford says that if he had asked his customers what they wanted, they would ask for a faster horse rather than a car. I don’t think that quote is true, but the sentiment definitely holds water.
In today’s terms, we might consider a product like Slack. It’s become such a ubiquitous part of work in such a short time frame because it met an obvious demand. But, if you had asked the average person a few years ago if they wanted a chat application for work, it probably wouldn’t have ranked high on their list of priorities.
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. It can’t be the entire guiding force for everything that we create, or we’ll end up with a faster horse (with cup holders) rather than the hot rod we really should be building.
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.
As I mentioned already, 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.
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:
In other words, feedback is just one piece of a much larger equation. Many teams allow this 20% piece to commandeer the ship—and the product development just becomes a game of whack-a-mole.
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. So let’s discuss some of the ways that teams achieve it at scale.
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.
Let’s start with the Cadillac option. If your team has the size and resources, then implementing a full-blown VOC program is often the best and most pain-free way to capture feedback and build it into your processes.
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.
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.
Make time every week to have non-sales calls with your customers and learn about their needs, how they use your product, and what they’re thinking, saying, and feeling.
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.
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.
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:
For bonus points, look at the reviews of adjacent or competitive products:
The opportunities are boundless. Just don’t spend all of your time reading reviews and forget about the other elements of product planning.
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:
And, the last part of this process is to fold this feedback into your broader product management/planning process.
These briefs, specs, or user stories should be provided by the VOC team, product manager, or another team/person who is responsible for gathering this feedback. Then, they should be used as part of the discussion when it comes time to groom the backlog and make product management decisions.
One other way to incorporate this feedback is to use it to guide items that are already part of the product plan.
Say your roadmap involves building out an improved sign-up flow.
That’s the perfect time to tap into customer feedback and figure out what parts of the current process require the most attention, which social login features are likely to get the most use, and other tactical decisions that go into the development.
In this case, customer feedback is extremely valuable as part of the scoping and planning process, without necessarily introducing new items to the backlog.
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.