How I Decide Which Feature Requests to Ship (and Which to Politely Refuse)

Most builders I know are drowning in feature requests by month three. Slack DMs. Support emails. "Quick one?" replies under a launch post. Half of them sound reasonable. Almost none of them are free.

I used to treat every ask like a vote. More votes meant more important. That filled the roadmap with work that made one loud user happy and everyone else a little more confused. The product got wider. Activation got worse. I shipped less of the thing people already paid for.

Here is the filter I run now before I say yes, maybe, or a polite no.

Score the ask in five minutes, not five days

I keep a dumb spreadsheet with four columns. Frequency, impact on the core job, cost to ship and maintain, and confidence that the requester actually uses the product weekly.

Frequency alone lies. One person asking three times is still one person. Impact on the core job matters more: does this help the user finish the job they signed up for, or does it add a side path? Cost is not just the weekend of coding. It is the support load, the edge cases, and the next three features this one unlocks in people's heads. Confidence is whether they are a real weekly user or someone browsing for a free custom build.

Anything that scores high on frequency and impact and low on cost goes into a thin ship. Everything else goes into a dated "not now" note with a reason. I revisit the list every two weeks. Most "not now" items die quietly, which is fine.

Separate "we should have this someday" from "this unblocks revenue this month"

Builders love future-proofing. Users ask for integrations, roles, white-label, export formats, mobile apps. Some of those matter later. Almost none of them matter before people repeatedly finish one job in your product.

When an ask is really an integration wish list, I treat it as a different problem. I wrote a separate note on how to choose your first integration when users ask for everything. Same idea: prefer the thing that sits in the post-signup workflow, validate with a manual workaround, ship a thin v1, measure activation for 14 days. Do not start with the loudest brand name.

If the ask is coming through support tickets, read them as patterns, not as a pile of chores. Same idea as turning support tickets into your next product priorities: tag fast, cluster weekly, score frequency against cost. I also wrote a shorter Hashnode take on stopping treating tickets like interruptions. One repeated friction beats ten one-off wishlist items.

Refuse without disappearing

A soft no that never gets sent is worse than a blunt no. People assume you ignored them. Then they churn and tell two friends the product "doesn't listen."

My default reply is short:

Thanks for writing this up. Right now we are focused on X so new users can get to Y without help. I am not shipping this in the next two sprints. If that changes I will ping you. In the meantime, here is the workaround we use: ...

I keep a "not yet" folder of those replies. When the same ask comes from three different paying users in a month, that is a signal. When it comes from one free user who never activated, that is noise.

Ship the smallest version that answers the real job

If you say yes, do not ship the fantasy version. Ship the version that lets you learn in a week.

Examples that worked for me:

• Instead of full roles and permissions, a single "viewer" share link
• Instead of a custom report builder, one CSV export of the exact columns people paste into Sheets
• Instead of a Zapier suite, a webhook that fires on the one event that matters

Then measure. Did activation or retention move for the cohort that needed it? If not, you learned cheap. If yes, deepen it. The point of triage is not to become a product dictator. It is to stop trading your only scarce resource — focus — for applause from the loudest inbox.

A weekly ritual that keeps the backlog honest

Every Monday I look at:

1. The top five open asks by score
2. Anything I promised a date to (almost never promise a date)
3. One thing I can refuse cleanly this week

If the backlog grows every week and nothing leaves it, you are collecting wishes, not building a product. Kill stale rows. Archive the ones you already answered. Keep the sheet boring on purpose.

Feature requests are useful. Treating them as a to-do list is how indie products get fat and slow. Score fast, protect the core job, say no in writing, and when you say yes, ship thin.