How do you take it when people suggest features in user interviews?

Hi all- I would appreciate any advice on the matter.

In the past week, my designer and I conducted a couple of user interviews, and I noticed people would be really keen on suggesting features, mostly when I asked them how motivated they would be to use the product. I’ve been interpreting this as the app not being useful enough for them to use, but I am getting slightly overwhelmed at thinking of how to make this more useful.

Am I correct in thinking this way, and is the solution just to brainstorm ways to make it more useful?


If a customer suggests a feature, I’d want to try to figure out how they arrived at that conclusion. Had they used that feature in a competitor product? Or had they used a similar feature in an analogous task? Then have them talk about those things to understand why they felt those were successful and learn about that. Sometimes there are insights about the conditions of successfully completing a task that come out. But I’ve definitely used competitors features as the stimulus in a user interview.


People love to suggest features, it’s only natural. You would do the same if you were asked about a product. Won’t you?


People are very, very good at describing their problems and issues. People are not as good at coming up with solutions, especially when they don’t understand your tech stack. That’s your job as a PM - come up with solutions that satisfy the problems your users are facing.


Echoing this, when they suggest a feature, what is the problem they are trying to address? Focus on the underlying problem and consider addressing that. There are typically multiple ways to address the same core problem outside of the solution proposed by the user, evaluate the different approaches, and determine what makes sense for your product or if the problem even needs addressing.


Yes, but, sometimes users have great solution hypos. Don’t just follow them, but don’t disregard them either.


I would tweak slightly and say your job as PM is to really sharply define the problem statement. Designers and developers are problem solvers - you are a problem finder.


Probably 5 whys 80% of the time. If they can be super specific about why a solution would work, you could have them walk through their solution and probe into that more. 5 Whys is just hard if you’re not used to interviewing people. You could ask them if they’ve ever seen a feature in competitor products and what the pros and cons of it were if they’ve used it. Lots of mirroring work well and are easier when trying to keep conversation going.


@NathanEndicott, What are the 5 Whys, if I may ask?


Literally asking why to every answer they give you. The idea is it takes 5 “why’s" to typically get to the root cause of the problem.

My original comment about 5 why’s was more because the conditions to be able to literally ask why repeatedly have to be just right. The conversation has the be set up correctly and it can feel like an uncomfortable tactic if you’re not used to doing it and you haven’t done enough to build rapport with the participant. So, I tried to give OP a different way to get to 5 whys.

5 why’s is great. And totally a good thing to do when you encounter a suggester. But as a researcher tactic, it can be uncomfortable to pull off the first few times you do it.


@NathanEndicott, This is actually super helpful. I’m not very used to interviewing people, so I find myself not being able to get past the 2nd why very often.


Figure out why they are suggesting those features. They are probably trying to solve a pain point. Figure out which one it is or have them free-list the pain points that that solution might solve. It’s rarely one, often it’s death by 1k paper cuts.


Completely normal, I can’t remember a user interview where they didn’t request some sort of feature.

Our job is to figure out why they are requesting it and what opportunity it relates to. “OK, if you were able to use {feature request}, what would that do for you?” We have discovered some great new opportunities to meet our business outcomes through questioning users about their feature requests. It can uncover some great discover opportunities.

Very rarely, if ever do I tell them we will implement what they ask. I typically end that portion of the conversation reiterating what the core problem was and what outcome they were chasing without mentioning the specific feature.


Customers don’t want a quarter-inch drill, they want to quarter inch hole.
Better yet, they need that hole to hang a picture on the wall.


As a PM, you’ll need to build what your users need, not what they want. Use these suggestions as yet another source of feedback and data, along with quantitative metrics, competition research etc. Try to find insights and trends in all these suggestions. Feature requests are good indications that there’s a problem out there to be solved, but they’re just one of the many dimensions of how you do your discovery and prioritization. How much the suggested feature aligns with your vision and strategy? How many other users or customers have the same problem? What would be the level of effort required to build and ship it? Most importantly, WHY your users are requesting that particular feature? Keep in mind that you’re the one discovering problems and coming up with a new solution: if you ask people what they want, they will always say “faster horses”.


If they suggest feature. Note it down and ask “Why” do they need the feature.

Then classify the feature in to Functional or Desire or Delightful.

Then classify in user needs vs business needs.

Then you will arrive at a conclusion. Test it with same user groups, gather feedback, optimize and release to test.


“That’s a great idea that I am writing down. Let’s get back to how you were describing the problem, one more time, so I can be sure I understand it.”


Look at this as gold!

A couple reasons to look at it this way:

  1. Generally, this kind of feedback – requesting features or issues they have that aren’t related to your focus – is a goldmine of potential areas to create more value for your users, whether they be small updates or more robust feature development. It’s gold you don’t need to dig for!
  2. The unsolicited feature requests also generally suggest that your users care about and like your product – this is a very good sign. They are emotionally vested in the product improving and fitting all their needs – they want a perfect product that makes their life easier, and they are asking for things that will get them there. If they didn’t like your product at all, they likely wouldn’t be making specific feature requests, they’d just complain…

Remember that it’s human nature to focus more on negative or difficult things. It’s extremely unlikely to interview a user and have them just list out all the great things about your product. Our biological tendencies are to focus on the pain points and try to fix those. Your users want to feel heard, cared about, and listened to.

I found a big challenge that some new product managers have is actually respecting the users as people – they have things they’re trying to get done to do their job, and your job is to provide them with a tool to do their job better. They spend time (likely a lot of time) on your product, and they want to feel like you’re listening to them.

I find it helpful to have ‘conversations’ with users, rather than ‘user interviews’. I know this is just semantics, but the slight perspective shift can really change the dynamic of the interaction for both you and the person you’re talking to. Get good at tracking the things they talk about freely, maybe diving into some of them if time allows, but also redirecting to the specific data you need from them.


Your end users are going to be one of the greatest sources of feedback. You need to manage their requests against the roadmap and vision your product has identified, but if you can’t keep current users you won’t retain future users.


I find this to be somewhat limiting … and not all places have UX researchers. Developing that product interviewing skills will serve you well in the long run, but as I noted elsewhere it takes practice to do it well and requires work up front.

The goal is to understand what problems the user struggles with. The most effective way of doing this is to both ask why and observe their struggles in action through their behavior with your software. It’s not a bad thing if they start offering solutions, it’s only natural, but direct the conversation back to their “why” or back to their behavior interacting with the UI.

1 Like