How do you say no to a feature that would obviously get used?

Easy to kill a feature nobody wants. Much harder to kill one that would clearly get real usage, just not enough to be worth what it costs to build and support.

Went through this properly with a batch of automation features for letsflw. Started with 8 candidates, all genuinely useful on paper. Ended up shipping 3. The other 5 got cut for standalone demand that was real but thin the kind of thing where you'd get a trickle of users, permanently, and permanently maintain a feature for that trickle.

The trap I was trying to avoid: building something because it completes the set, not because the demand actually justifies it. "We have 7 tools in this category, we should have an 8th" is a reason to build the wrong thing.

What actually got cut stayed cut even when it would've been easy to justify keeping "just in case." The hard part wasn't identifying weak ideas it was admitting a genuinely good idea wasn't good enough to be this idea, right now.

Curious how others draw that line is it a demand threshold, a maintenance-cost gut check, something else? And has anyone shipped the "obviously fine" feature anyway and regretted the ongoing cost of it?