Make a great product, seek and listen to customer feedback, and use the feedback to make your product even better. Simple right?
The reality is much harsher.
In this video I share the harsh lessons I’ve learnt in dealing with customer feature requests in my 20+ years of creating software.
Transcript:
When you manage the same software product for long enough, you will discover that the feature requests never stop coming.
In this video, I’m sharing with you some harsh lessons I’ve learned about dealing with customer feature requests.
Ten, harsh lessons to be precise.
One, the feature requests never stop coming. No matter how hard you try to get through your backlog, you’ll always receive way more feature requests than you could ever possibly implement.
Two, receiving many customer feature requests is a good thing. It’s a positive sign of people engaging with your product. It means they’re relying on your product to get their job done or to improve their lives. So if that’s your case, congratulations, I think you should stop and give yourself a little pat on the back.
Three, customers mostly request iterative improvements to your product and not innovative changes. They’ll ask for a feature to be enhanced slightly or a new screen that’s quite similar to an existing screen. The really innovative changes, those ideas need to come from within your team thinking creatively.
Four, it’s tempting, so, so tempting to implement the easy requests instead of the popular requests.
Maybe there’s something that’s been asked for once or twice, but you know you can get it done next Thursday before lunch, deploy it, and inform all your customers that your product has a new feature, and feel like you’re moving forward. It’s a false feeling. Meanwhile, the popular request that you received a hundred times in the last three months, you’re not doing that because it will require you to reengineer your database or to rethink your entire user interface. I don’t think you need me to tell you that you’ve got to prioritize the requests that people actually want, and not just the easy ones.
Five, not all feature requests will fit your vision for your product. Now, I find this one quite hard. If one person requests something that’s not right for my product, it’s easy to not do it, to say no.
But what if we’re getting a lot of feature requests that don’t fit my vision? At what point do you actually give in a little bit and bend and change your product vision. To what degree should you just stand firm to what you believe it should be? That’s for you to decide, and I don’t have an easy answer.
Six, “we’ll consider it” as an answer, is often misinterpreted as “it’s coming soon”. I learned quite quickly not to just simply say we’ll consider it, but to really answer that we do get a lot of requests and that we have to really balance them all up and that we’ve listened, but we don’t make any promises.
Seven, you need a diplomatic way of saying, no.
Now this will have to fit in with your personality and your products, personality, and your team, but you do need a way of letting customers know that the thing they request is probably never gonna happen without just saying no outright. Why can’t you say no outright because it actually gets customers offside. It’s it makes people feel like they’re not being listened to.
Eight, your competitor’s most popular features will become feature requests for your product. Now this one surprised me as a product person, but it turns out some of your customers, especially those customers who are still assessing you against the competitors, they’re much more aware of the competitive landscape than you realize.
And if there’s something your competitor has added that’s a real successful feature, they will tell you because they’ll start requesting that feature yourself. The features your competitors have that your customers are not asking for is probably a bit of a flop and your competitor who regrets ever having done it.
Nine. The first implementation of a new feature is almost always inadequate. You can follow the best product management methodology, but unless your customers are software development experts themselves, they find it really hard to explain what they want. And until they can click and use a new feature, they won’t quite understand whether it’s what they wanted, and that’s why the first implementation is almost always inadequate.
And ten, tracking feature requests is messy. Always has been, always will be. This is why we created Feature Upvote, but because this is not a sales video that’s all I’ll say on that topic.
My ten harsh truths of dealing with customer feature requests. Thanks for watching and see you next time.