How to Handle Feature Requests That Don’t Make Sense

Sometimes, clients or PMs ask for features that you think might not really add value or could even cause problems. Your first thought might be, “How do I build this?” but the more important question is, “Why do we need this in the first place?” The best approach is to focus on the problem, not just the feature itself. Take the time to understand what the request is trying to solve.

For example, a client once asked me to autoplay every product video on hover. At first, it sounded doable, but when I asked why, I learned the real goal was to make key product features more noticeable. Instead of autoplaying dozens of videos, I suggested a small badge with a click-to-play button. It achieved the same result without extra scripts, layout shifts, or slowing the page down.

Asking clarifying questions is another key step. You want to uncover the outcome they truly care about. Questions like, “How will users interact with this?” “What happens if we skip it?” and “What are we actually trying to achieve?” can reveal simpler, smarter ways to reach the goal. Often, you’ll find there is a better path than what was initially requested.

It also helps to explain trade-offs in plain language. You do not need to talk about frameworks or code. Just focus on what the feature means for the product. For instance, you could say, “Autoplaying videos on hover will load more assets, increase memory use, and make the page slower. Highlighting key features with click-to-play achieves the same result without hurting performance.” Being clear about trade-offs helps people understand why a feature you think might not be worth it could actually cause problems.

Offering alternatives is usually more effective than simply saying no. Most clients care about the outcome, not the exact implementation. Showing them other ways to solve the problem can get them what they want while keeping the product smooth, reliable, and maintainable.

Finally, be honest when it matters. Sometimes a request could hurt performance, SEO, or future maintainability. Explaining the risks and suggesting a better approach usually builds trust and leads to better decisions. At the end of the day, handling feature requests is not about saying no. It is about making sure the features you build actually solve problems and keep the product reliable, fast, and easy to manage.