Why feature requests are hard to collect manually
Feature requests rarely arrive clearly labeled. A customer submitting a support ticket is usually describing a problem, not making a feature request — but embedded in that problem description is often an implicit request. "I wish I could filter this table by date" is a feature request. "Can I export just the items from last month?" is a feature request. "Every week I have to manually calculate this" is a feature request.
At low volume, a human reading every ticket can pick these up. At scale, they get lost. The result is that product teams tend to act on the feature requests that were loudly and explicitly stated — by the customers who sent the most emails or showed up in the most calls — rather than on the requests that were most frequently implied across the full customer base.
AI-based feature request extraction tries to surface the full distribution: what is being requested, how often, and in what context.
What extraction identifies
Rereflect's feature request extraction looks for two categories of signal:
- Explicit requests — direct statements of desire: "I'd love to be able to...", "Is there a way to...", "It would be great if...", "Can you add...", "We need...". These are the easiest to catch because the language is unambiguous.
- Implicit requests — descriptions of workarounds, frustrations with missing functionality, or comparisons to other tools: "Right now I have to export to spreadsheet and do this manually," "Tool X has this and it saves us hours," "Every time I need to do X I have to leave the app." These require more inference to identify as feature requests.
A keyword system catches explicit requests reasonably well. Implicit requests require a language model — recognizing that "I have to do this manually every week" contains a feature request requires understanding the context of what "this" refers to and inferring that automation is being implicitly requested.
When no LLM is configured, Rereflect extracts explicit requests through keyword matching. With an LLM configured, it also captures the implicit requests that keyword matching misses.
How extraction maps to categories
Raw feature request extraction produces a set of items that contain requests. To be useful for roadmap planning, those items need to be grouped and counted — which is where the feature request categorization taxonomy comes in.
Your configured feature request categories define the buckets that requests get sorted into. If your taxonomy has a category for "reporting and analytics," requests like "I want to be able to export charts," "add a monthly summary report," and "we need aggregate views by segment" all land in that bucket. The count in that bucket across your full feedback history gives you a frequency signal: this is how many customers, across what time period, have requested something in this area.
The quality of this aggregation depends on the same factors as any categorization: how clearly your categories are defined and how distinctly they are separated. A catch-all "integrations" category that includes both "connect to Salesforce" and "webhook support" produces an inflated count that obscures which specific integration type is being requested.
Turning extracted requests into roadmap signal
Volume is a starting point, not a conclusion. A feature requested by 50 customers in a given month is not automatically more important than one requested by 5 — it depends who those customers are, what their request implies about your product strategy, and whether you can build it.
More useful ways to read the extracted data:
- Volume combined with customer segment — requests from customers in a specific tier, industry, or use-case cluster often reveal underserved segments more than raw count does.
- Requests co-occurring with churn signals — a feature request accompanied by urgency signals or negative sentiment is a different kind of signal than a neutral wish list item. "We will leave if X isn't available" deserves different treatment than "it would be nice if X existed."
- Velocity over time — a category of requests that is growing week over week represents a growing need. A stable category represents a chronic but not accelerating gap.
- Requests about the same area as pain points — if your most complained-about category and your most requested feature category overlap, you have high-confidence signal about where to focus.
What extraction gets wrong
Feature request extraction is not perfect. Common failure modes:
- Requests framed as questions — "Is there a way to do X?" is a feature request if X does not exist, but a support question if it does. The extraction layer may not know which is the case.
- Requests for things that already exist — customers sometimes request features that the product already has. These will be extracted as feature requests when they may actually be discoverability or documentation problems.
- Vague requests — "make it easier to use" or "improve the dashboard" express dissatisfaction but do not identify a specific request. These will be captured but cannot be meaningfully categorized.
- Compound requests — a paragraph that contains three separate feature asks may have the most prominent one extracted while the others are missed.
None of these failure modes make the extraction useless — they mean you should treat the output as a distribution with noise rather than a complete and accurate enumeration. The high-frequency categories are real signal; the long tail deserves more skepticism.
Periodically review a sample of the extracted items in your top categories and check whether they actually belong there. If they do, the count is meaningful. If the category is attracting a lot of mismatches, the description needs work.