Best Practices

Don’t Fear Customer Feedback

Happy Friday the 13th. A day so revered that some people change their routines entirely … refusing to fly, do business, or even get out of bed. Whether you buy into the lore or not, it seems the perfect day to discuss what can be a fear-inducing part of being a PM: managing customer feedback successfully

I say fear-inducing not because talking to customers or collecting feedback is scary, but because customer feedback is so critical to building good products that you want to get the collection, analysis, and application of feedback right every time. 

So how can you ensure that you are getting the most out of customer feedback? How can you pick the worthwhile insights from the ones that might send you down the wrong path? Here are a few tips to rev up your customer feedback engine. 

Make it a priority: Set a weekly quota for customer calls

A lot of product teams say customer feedback is important. However, they don’t actually do the work to prioritize it. Pick a number of customers you (or your product team) will commit to talking to on a weekly basis. Share it widely. Include it in your quarterly goals. Set up a tracker that is visible to your superiors. Taking these extra steps to hold you and your team accountable will make a big difference in developing a culture where customer feedback is valued and leveraged on a regular basis. 

Always ask for more context

The first time I read Clayton M. Christensen’s Harvard Business Review article, “Know Your Customers’ ‘Jobs to Be Done‘,” it was a lot like putting on glasses for the first time. Things that I had a blurry understanding of were suddenly crystal clear and everything was just a bit brighter. If you aren’t familiar with it, I recommend reading the article and then following it up with Competing Against Luck: The Story of Innovation and Customer Choice.

What Christensen hones in on is that you can collect all the data you want about a user, but you still may not understand why they use your product and what they need it to do. What you need to focus on is, as he puts it, “The progress that the customer is trying to make in a given circumstance.” This requires context, and lots of it. 

When you are talking with customers, ask them to explain when they are executing a task with your product. What time of the day is it? What was happening before they visited your website or opened your app? Then ask them what comes after. You should think of yourself as a detective trying to piece together a detailed timeline of all the events surrounding the critical moment of using your product.

By doing this, you will often learn that the progress a customer is hoping to accomplish with your product isn’t perfectly aligned with what your product does. This is risky, because if your product doesn’t help them make that desired progress, they may look for other solutions. But it’s also potentially rewarding if you can improve your product to help them achieve that progress. In that case, you have a great chance of retaining that customer. 

Stay away from the top 10% and the bottom 10%

The easiest groups to get product feedback from are often the most problematic. They fall into two buckets: super users and disgruntled users. Both are willing to talk your ear off about what they need and what could be better, but rarely do they represent the majority of your user base. You want to avoid adding features that cater to a small audience and over-complicate the experience for everyone else.

If you are leveraging super user feedback or input from disgruntled/churned customers, it’s important not to treat them as uniform blocks. Just because a group of users is finding value doesn’t mean their needs or motivations are the same. You will still need to dig deeper and segment this group. I’ve often tried to seek out a successful user in the same industry as larger groups of users who were struggling. This gave me insight into the contributing factors that were leading them to succeed where others were failing and gave me ideas on how we might address that in the product. 

Pair qualitative with quantitative data

When I was building a team focused on increasing product adoption for a social search and discovery tool, I had to deal with misleading quantitative data. The numbers told a story of active users who created a lot of searches in our product. These looked like healthy users who were getting a ton of value.

When we actually got them on the phone to talk about their habits, we uncovered a different story. They were creating so many searches because they weren’t finding what they wanted. The results didn’t match what they thought their search string would find so they tried again and again and again. Without the qualitative color commentary, we may have thought these high volume searchers were power users. Instead, we uncovered a product pain point and set out to improve our search function so that the results better matched user expectations. 

As a product manager, you should never be relying on just one type of data. Basing product decisions on hard data alone can lead you astray because it often lacks the needed context.  Similarly, a customer might ask for a very specific feature and then rarely use it once it’s built. It’s the old, “If I had asked people what they wanted, they would have said faster horses,” Henry Ford quandary. Finding a balance of qualitative and quantitative data will ensure you are making the most informed decisions when it comes to roadmap prioritization and feature development. 

Be honest with customers about the problems you are looking to solve next

There are lots of different philosophies on if you should make a public-facing roadmap available and how much you should communicate about your development plan. My belief is that instead of talking about the nitty-gritty details, you should stay high level, focusing on the problem you want to solve next. This keeps you from committing to features and timelines you might not be able to deliver on. Plus, it can be a great way to solicit more feedback. If the problem you think is priority No. 1 isn’t top of mind for the customer, that can be a good indication that you need to re-evaluate or that the customer might not be your ideal target user. 

Go back to customers often during product development

You may have chuckled a bit or rolled your eyes when you read this. “Well, duh” may have even escaped your mouth. It’s easy for this to be something you talk about, but not something you always do. As the product manager and engineers developing a new feature, you inherently understand how to use what you built because you built it. For you, it’s intuitive and delivers the needed value. I guarantee your customers will find room for improvement. This is why usability testing is so important and should be done even on smaller sets of features.  

It’s critical to schedule usability testing when you still have time to adjust your product. The closer you get to your target date, the more pressure there is to ship on time. This might mean you are only incorporating a small percentage of customer feedback even if all the feedback was relevant. Build in extra testing time so you can avoid this outcome. Usability testing and A/B testing will help reduce the number of tweaks you need to make immediately after a release and often catches some forehead-slapping easy wins you might have overlooked by being too close to the product.

Enjoy your Friday the 13th, and stay safe out there in the product management trenches.