When to listen to a customer and when not to?

First recognize the gold mine you have- people are talking to you, most customers could give a shit. Second, organize the data- get into some analysis, frequency, topical theme, stemming foundation or future fork. Next dont promise anything. Then look into the patterns. Dev for foundational goodness first if you have low funding, if you are minted build what should be next not now. Dont be too anal on things- really depends on where you are at with fit on product, cash for burn and morale for change and certain uncertainty.

@james_afino good question - my approach has always been to listen not just to 'what' they're asking for, but to really understand 'why' they want that thing. Their goals / intentions are always right, but often their imagined solution isn't the best one.

Sometimes, I come across a feature request that I just instantly get. You know, those "aha!" moments where you realize something about your product that you had never thought of before. I tend to prioritize those features. You may call it gut feeling, but it has worked just fine on a small scale for me. In general, although I didn't know about the RICE framework before this post, it seems like a good way of thinking to guide you towards the correct prioritization. I might just start using it later on :)

Well, you should always listen to your customers :). But then it, you should probe them to understand why. Why is he/she requesting of a feature? What problem is he trying to solve? Once we understand that it will be easier to make decision. Also I feel rather then asking if the feature is requested by many, we should try to understand if this problem is more common place. Because often if one feature is used to solve variety of problem, then it indicates that it might not be scalable and it might can help your product roadmap. Also, the usages of those features are generally very low. It also depends on what kind of platform you are building. If you are building a custom product for a single customer and charging premium. Definitely, you will have to include requested features. But if you are building for masses, then it is better to avoid complicating your product. You might lose one customer, but in long term you will end up with better and scalable product. I have often listened to customer request certain features which looks important but it generally ends of being result of laziness. :) It is true. Most customers just want one button to do all the things. Sometime that is not possible and not relevant to the actual problem you want to solve. Hope that was helpful.

It's not about listening, it's all about selecting

Always listen but be selective in your priorities : I wonder whether the request involves only passionate users or whether it concerns the majority and whether I can propose a perfect or imperfect solution in a reasonable time frame. I rank the requests according to that

Great question. Some companies have been successful by sticking to a clear vision and saying "no" to features that don't enhance that vision. Unless your company is led by the rare visionary who truly understands a gap in the market and will stop at nothing to blaze a trail, then I think you will need to listen to your customers to help guide your product. I would use the 80/20 rule where 80% of your customers give you the most headaches while 20% pay the bills and "have the most value". Listen to the 20% and build the product THEY need. You may also want to check out the public message boards/support forums of your competitors. That is a great source for "low hanging fruit". Fill in the gaps that have left your competitor's customers frustrated.

Hi there :) I guess it's important to mention that many people, many minds. If you deal with customer acquisition and hear 3-4 times one and same idea/request - seems like you should at least consider it. Also, if you already have paid customers, talk to them, analyze if the feature will be useful to them. If not, why waste resources on it? If you don't want to dumb a prospect, but the feature is not really useful, you can offer to develop it specially for them and for a special price.

You have to be careful with decisions like this. Sometimes customers can be greedy, they request for features that solve a unique problem they are having, but in a wider business domain it may not be very relevant or useful long term. so you have to consider the value offering of these features and how does it align with your product long term goals. If you can't find any real value for a wider business domain or at least align with your long term business vision? I will say PUT IT OFF!

RICE all the way! So glad we started using this framework.

There isn't anything to dive deep into the customer. Ask - If it is saving their time and money which in return leads to more productive work user will pay. KISS keep it simple and stupid

I'm not really familiar with the RICE framework but when it comes to decisions like this, I always ask myself: Is it really necessary? Will it make the life of the customers better or easier? Will it still be useful after 3-5 years? Is it feasible? Will I sacrifice too much in order to do/have it?

When customers start asking for features, always ask them why, what is it that they are looking for? When the why and what is clear, you may be able to offer a better suggestion, or an alternate solution. Don't jump into a feature request just because a client asked for it. The general assumption is - If I add all the features my client wants, my product will improve, and I will be able to sell more. Sometimes, the reverse it true - too many features makes the product complicated and increases the learning curve for new clients and also your support staff.

Listening to the customers is the first priority of any business. When customer tells its requirement for the business it should be listened carefully but when the requirements are not possible or are irrelevant in terms of technicality of the app or software, we shouldn't listen to them but it doesn't mean to ignore them as sometimes the ideas they give can help in building and developing a new and innovative thing.

We commonly use the ICE framework, but you've all opened my eyes to adding an "R"! Thanks! Part of the ICE framework is "confidence", which relies on you having quantified customer requests. I think the key is quantifying how many customers are asking for the same thing or (more importantly) have the same underlying painpoint. We've learnt quickly that it's not a good idea to build a new feature for a single client, but if several of your customers, without talking to each other, are requesting the same feature, that's a strong indicator that they're seeing a flaw in your product which you need to sit up & listen to.

sometimes client has a need and he thinks that feature solves certain problem, so I focus on the problem and I use time and cost arguments. How do you use RICE? Do you use rice framework with client himself or make workshop with client?