How to Collect Product Feedback and Feature Requests from Reddit, X, and Hacker News

Why the usual feedback channels miss it

Most teams collect feedback from three places: support tickets, an in-app widget, and sales calls. All three have the same bias. They only hear from people who are already talking to you.

Public threads are different. Someone who churned last month won't fill in your survey, but they'll happily explain on Reddit why they left. A prospect who's comparing tools will list what's missing from yours in a "which one should I pick?" post. That's feedback you'd never get any other way, and it often comes with replies from other users agreeing or disagreeing, which tells you how common the problem is.

The catch is volume. If you search your product name once a week, you'll find a handful of threads, usually too late to reply. If you set up a raw alert on your name, you'll get every mention, including the ones that have nothing to do with the product. The trick is to write alerts that look for feedback specifically.

Writing alerts that look for feedback

A KWatch alert matches every keyword in its list, so commas act like AND. That's what makes feedback alerts work. Instead of one alert on your product name, you pair the name with the words people use when they want something changed.

Here's a starting set, with "acme" standing in for your product name:

1. acme, wish and acme, would be nice for feature requests
2. acme, bug and acme, broken for bug reports
3. acme, switched and acme, cancelled for churn reasons
4. acme, missing and acme, doesn't support for gaps people hit while evaluating

Each line is a separate alert, because an alert with all those words would need all of them in the same post. You'll probably tune the wording after a week, once you see how your own users talk. People rarely type the words "feature request", so look for the phrases they do use, like "would be great if".

A few filters do most of the cleanup. On Reddit and Hacker News, turn on Whole Words Only if your product name is short or common, so "acme" doesn't match "acmeplex". Add your own team's accounts as Excluded Users, so your replies and launch posts don't trigger alerts. If you have a product subreddit, you can make a separate alert scoped to it with Included Subreddits and drop the second keyword entirely, since nearly everything posted there is feedback anyway.

Excluded keywords work the other way around from included ones. Included keywords all have to match, but a post is dropped as soon as any one excluded keyword appears. Keep that list short and specific, or you'll filter out real feedback along with the noise. Our post on reducing noise in keyword alerts goes through every filter in more detail.

Where to listen first

Not every platform gives you the same kind of feedback. I find Reddit and Hacker News are where people write the long, specific complaints. X is shorter and angrier, which is useful for catching a broken release fast. Linkedin is mostly praise and announcements, so it's lower on this list unless you sell to people who post about their tooling there.

Speed also differs by platform, and it changes how you'll use each alert. These are the refresh rates from our docs:

For feedback, none of these are slow. What the table tells you is that a Hacker News thread can reach you while it's still on the front page, which is the moment a reply from someone on the team carries the most weight.

Getting it to the product team

An alert nobody reads is just a nicer search. The part teams usually skip is deciding where feedback lands and who sees it.

The simplest setup is a dedicated Slack channel. KWatch lets you set a Slack webhook per alert, and a per-alert webhook overrides your account-wide one. So your sales alerts can keep going to the sales channel while the feedback alerts go to something like #product-feedback. Product managers and engineers who only need to read can join your KWatch team with the Reader role, which receives notifications but can't create or delete alerts.

If you want to count requests over time, send the same alerts to an API webhook instead. Each match arrives as a JSON payload. Here's the example from our docs:

{
  "platform": "reddit",
  "query": "Keywords: vllm",
  "datetime": "19 Jan 24 05:52 UTC",
  "link": "https://www.reddit.com/r/LocalLLaMA/comments/19934kd/sglang_new/kijvtk5/",
  "author": "lmzoo",
  "content": "sglang runtime has a different architecture on the higher-level part with vllm.",
  "sentiment": "neutral"
}

Point that at a Zapier or n8n webhook and append a row to a spreadsheet, with one column per field. The query field tells you which alert fired, so a request alert and a bug alert sort themselves. The sentiment field (positive, negative, or neutral) gives you a quick way to pull out the angry posts first. We wrote up the Zapier and n8n setup step by step if you haven't wired one before.

Email alerts work too, but long posts get truncated in email. Feature requests tend to be long, so Slack or a webhook is the better fit here.

What to do with what you find

Once feedback is flowing in, the temptation is to reply to everything. I'd hold back a bit. A short, useful reply from someone who clearly works on the product ("that's on our list, here's the workaround for now") does a lot. A string of replies that all end in a signup link gets you downvoted, and on some subreddits, banned.

The more valuable habit is the weekly read. Once a week, someone on the product team goes through the channel or the sheet and tags each item: request, bug, churn reason, or not relevant. After a month you'll have a rough count of what people ask for in public, next to what they ask for in tickets. When the two lists disagree, that's usually the interesting part.

If some of your most useful feedback comes from a handful of known people (power users, analysts, a competitor's founder) rather than from keywords, our sister product MultiFollow follows specific Linkedin and X accounts and alerts you when they post, which complements keyword alerts nicely.