Feature requests

How to find feature requests on Reddit

“I’d pay double if it just had bulk export.” 31 upvotes, four “+1, this is the thing keeping me from upgrading.” No ticket, no survey — the clearest roadmap item that team shipped that quarter.

What a feature request actually looks like

People rarely post “Feature request:”. They phrase it as desire, a question, or the reason they’re leaving. The shapes:

  • Wish phrasing — “I love it but I wish it could schedule recurring exports”; starts with affection, ends with a gap, and tells you a user who wants to stay
  • Question phrasing — “does it support SSO yet?”, a request wearing a disguise; a thread of unanswered “does it do X” questions is a backlog
  • Demand phrasing — “it needs a dark mode”, “it really needs an API”; blunt users who already decided the gap is obvious
  • Switching phrasing — “switched from it because it can’t handle large files”; the most valuable, covered below

Feature request vs bug vs startup idea

A feature request says “I want it to do something it doesn’t do.” A bug says “it’s supposed to do this and it’s broken.” A general pain says “this whole category frustrates me” without naming a fix. These blur, and one thread often holds all three — sort as you read.

This is also a different job from hunting for a brand-new product to build from scratch. Here the product is live; you have users, churners, and a competitor’s users eyeing the door, and you’re anchoring on a specific product and its named gaps rather than scanning for unmet problems in general.

Where feature requests hide

Requests cluster in predictable places, and each colors how you read them:

  • Your own product’s subreddit — densest and easiest, grounded in real workflows, but skewed toward power users; read top-of-month and top-of-year, not just hot
  • Competitor subreddits — every “I wish [competitor] could…” is a gap you could fill; their churned users do your demand research for free
  • Category subreddits — r/projectmanagement, r/Notion, r/CRM, r/selfhosted; “what’s everyone using and what does it still not do” threads name five products’ gaps at once
  • Comparison and “alternative to” threads — nobody seeks an alternative when their tool does everything; each reason listed is a feature gap

The gold in “switched away because”

If you read one kind of thread, read the churn confessions. A wish-list comment tells you what would be nice. A “switched from X to Y because…” comment is a user who already paid the cost of leaving — who valued the missing feature enough to learn a new tool and migrate their data. The feature didn’t just annoy them, it cost you the account. That’s the difference between “would be nice” and “this loses revenue,” and it should jump the queue.

These appear two ways: on your sub or a category sub, “leaving [your product], here’s why,” and on a competitor’s sub, “moved here from [your product] because it couldn’t do X.” Both are churn-attributed requests, and churn-attributed beats everything because the cost is proven in dollars, not upvotes. One person leaving over a missing integration is an anecdote; five is a board-meeting slide.

The search phrases that surface them

Run these quoted (wrap in quotes to match exactly), swapping in your product or a competitor’s, and pair with site:reddit.com on Google for broader recall:

  • "wish [product] could" and "wish [product] had"
  • "does [product] have" and "does [product] support"
  • "[product] needs" and "[product] should add"
  • "missing feature" paired with the product or category name
  • "switched from [product]" and "alternative to [product]"
  • "is there a way to" inside the product’s subreddit

Telling a real request from a one-off

The internet requests everything. Three tells, in order of weight:

  • Frequency across threads — the same feature in ten threads from ten accounts over months is a pattern; one mention is a data point. The strongest filter
  • Upvotes on the request itself — a request at 40 upvotes where most comments get 3 is a crowd nodding along; weight against the sub’s baseline
  • “+1, I need this too” replies — the richest confirmation, and they often narrow “better exports” into the buildable spec “CSV export with custom columns”

Then turn requests into a plan

A raw list of everything users asked for is not a roadmap — it has no weighting, no cost, no sense of which requests move retention. Mine first, then prioritize, or you’ll build the loudest thing instead of the most valuable one.

Prioritize these into a roadmap

Frequently asked questions

How do I find feature requests on Reddit?

Mine three places: your product’s subreddit, competitor subreddits, and category subreddits like r/projectmanagement or r/SaaS. Read posts sorted by top of the month and year, and run quoted searches like "wish [product] could", "does [product] support", and "alternative to [product]", including with site:reddit.com on Google. Then sort by how often each recurs, its upvotes, and the “+1, need this too” replies.

What phrases signal a feature request?

Four shapes: wishes (“I love it but I wish it could…”), questions that hide an ask (“does it support…”), blunt demands (“it needs an API”), and switching statements (“switched away because it can’t…”). The switching phrasing is the most valuable, because the missing feature cost a real account, not just an upvote.

Should I build every requested feature?

No. Most requests are one-offs from a single user with an unusual workflow. Build the ones that recur across many threads and accounts, draw agreement in upvotes and replies, and especially the ones attached to churn (“switched away because”). A request mentioned once is an anecdote; the same request across ten independent threads is a pattern. Prioritization is a separate step.

How do I find requests for my competitor’s gaps?

Search the competitor’s subreddit and category subs for “wish [competitor] could”, “does [competitor] have”, and “alternative to [competitor]”. Comparison and “thinking of switching” threads concentrate these. Every unmet request about their product is a gap you might fill. If users leave them over a feature you already ship, that’s an acquisition message; if nobody has it yet, it’s a market opening.

What’s the difference between a feature request and a bug report?

A feature request asks for something the product doesn’t do yet (“I wish it could export folders”). A bug report says something that’s supposed to work is broken (“export crashes on large folders”). They often appear in the same thread, so sort as you read. Requests feed your roadmap; bugs feed your fix queue.

How is finding feature requests different from finding startup ideas?

Feature requests assume the product already exists, and you’re finding what to add next to keep and win users. Startup ideas assume no product yet, and you’re finding a problem worth building something new around. The subreddits overlap, but here you anchor on a specific product and its named gaps rather than scanning for unmet problems in general.

Validate what people actually say, not what you wish they would.