The Feature Request Dilemma

A customer says "Can you add dark mode?" Another says "I need an API." A third says "Why can't I export to CSV?"

Each request feels reasonable. Each customer seems like they'd be happier if you built it. The temptation is to say "Great idea! We'll look into it." Which the customer hears as "We're building it."

Then 3 months later, the feature doesn't exist, and the customer feels lied to. You didn't lie. But you promised something you couldn't deliver.

The Framework

Every feature request gets one of four responses:

Response 1: "We have this." Sometimes the feature exists and the customer doesn't know. "Actually, you can export to CSV from Settings > Data > Export. Here's a quick guide: [link]."

This happens more often than you'd think. Check before assuming it's a feature gap.

Response 2: "This is on our roadmap." You're planning to build it. Say so — but without a date. "This is on our roadmap. I can't give you a timeline yet, but I've added your request so the team knows there's demand."

Never give a date unless you're certain. "Q3" becomes "they promised Q3" becomes "they broke their promise" faster than you think.

Response 3: "We're not building this, but here's a workaround." You've decided against this feature. Be honest. "We're not planning to add dark mode because it would add significant maintenance overhead for our small team. As a workaround, you can use a browser extension like Dark Reader — it works well with our app."

Customers respect honesty more than vague promises. Some will be disappointed. That's okay.

Response 4: "I've logged this for the team." You haven't decided yet. The request is noted but you're not committing either way. "Thanks for the suggestion. I've logged it for our product team. I can't promise we'll build it, but your input helps us prioritize."

This is the default response for most requests. It's honest, it acknowledges the customer, and it doesn't over-promise.

Routing Feature Requests With Automation

Feature requests classified as feature_request get routed to your product board automatically:

• Create a Linear/Notion/Jira card with the customer's request
• Tag it with the specific feature area
• Auto-respond with Response 4 ("Logged for the team, can't promise a timeline")

This does two things: the customer gets an immediate response, and your product team gets a structured feed of feature requests without anyone manually copying and pasting.

Over time, you can see which features are requested most often. "20 customers asked for CSV export this month" is a stronger signal than one PM's gut feeling about what to build next.

What Not to Do

Don't say "great suggestion!" to everything. If you react enthusiastically to every request, customers expect results. Measured acknowledgment is better than empty enthusiasm.

Don't ignore feature requests. A customer who takes the time to suggest something is engaged. Ignoring them signals you don't care. Always acknowledge, even if the answer is no.

Don't build for one loud customer. One customer asking for a feature doesn't make it worth building. Ten customers asking is a pattern. Look at aggregate data, not individual requests.

Don't use feature requests as retention tools. "If we build X, will you stay?" puts you in a position where every churn conversation becomes a feature negotiation. Build what makes sense for the product, not what one customer threatens to leave over.

The Aggregation Play

The most valuable thing about feature requests isn't any single request — it's the pattern across hundreds of them.

If you're classifying support messages, you can pull every feature_request intent by month and see:

• What features are requested most often
• Whether request volume is growing or shrinking for specific features
• Which customer segments request which features

This data is more reliable than user interviews, NPS comments, or advisory board feedback. It's unprompted, high-volume, and directly tied to customer needs.

Feed it to your product team weekly. Let the data speak.