Every product team has a feature graveyard — ideas that seemed brilliant in the meeting and never shipped, or shipped and made everything worse. Learning to say no confidently and early is one of the most valuable skills a product manager can develop.
The Three Tests
Before any feature makes it onto the roadmap, we put it through three tests. First: who specifically asked for this, and how many customers like them do we have? A feature requested by one enterprise customer is a professional services engagement, not a product decision.
Second: what outcome does this feature drive, and is that outcome in our strategy? Features should exist to move a metric that matters. If you can’t connect a feature to a number you care about, it doesn’t belong in the roadmap.
Third: what does this feature cost to build, maintain, and support? Most product decisions undercount the long-term costs. Every feature you add is a feature you have to document, QA on every release, support when it breaks, and make decisions about when your design system evolves.
How to Say No Well
The best way to say no to a feature request is to say yes to the underlying problem while declining the proposed solution. “We hear that your team is struggling with X — we’re planning to address that in a different way in Q3” is more constructive than a flat no and keeps the conversation focused on outcomes rather than features.
