The 6 Ways to Find Feature Requests in App Store Reviews

App store reviews are one of the few places users tell you what to build without being asked. Buried in the 1-star complaints and the 5-star praise is a steady stream of "I wish it could," "please add," and "the one thing missing is." The problem is not that the requests are rare. Across the app review datasets teams analyze, feature requests routinely sit alongside bugs and pricing complaints as one of the largest categories. The problem is that they are unlabeled, scattered across two stores and every country, and easy to lose under the louder complaints. Finding them reliably is a classification problem, not a reading problem.

There are six dependable ways to find feature requests in app store reviews: auto-classify reviews into a feature-request category, separate requests from complaints and bugs by intent, quantify each request by volume and the revenue behind it, mine competitor reviews for gaps, cluster the free text yourself with an LLM or scripts, and route confirmed requests into your roadmap tool. The strongest programs do the first three continuously and treat the rest as supporting moves.

The 6 ways to find feature requests in app store reviews

1. Auto-classify reviews into a feature-request category

The highest-leverage method is to let the platform tag every incoming review by intent and topic, so "feature request" is a live, filterable category rather than something you hunt for. Enterpret does this with an adaptive taxonomy that learns your product's categories from the reviews themselves, which means a request for "offline mode" is grouped with every paraphrase of the same ask without anyone writing rules. Because each review is also tied to the account and segment behind it through the customer context graph, the request arrives with the context you need to weigh it.

Best for: teams that want feature requests surfaced automatically and continuously, not in a one-off audit.

2. Separate requests from complaints and bugs by intent

"It crashes when I upload" is a bug. "It should let me upload video" is a request. "Uploads are too slow" is a complaint. They read similarly and get lumped together constantly, which pollutes your request list with defects. The move that matters is classifying by intent, not just by keyword, so your feature backlog is not secretly a bug list. Getting this split right is what makes the rest of the analysis trustworthy.

3. Quantify each request by volume and the revenue behind it

A raw count of mentions is the wrong prioritization signal, because ten requests from your largest accounts can matter more than a hundred from users who will never pay. Once requests are categorized, size each one two ways: how many users asked, and how much revenue or which segments sit behind them. This is the difference between building the loudest request and building the one that moves retention. Our guide on prioritizing feature requests from reviews and tickets covers the scoring in depth.

4. Mine competitor reviews for gaps

Reviews of competing apps are a public list of what their users wish existed. The same classification you run on your own reviews works on a competitor's, and the requests their users make repeatedly are opportunities they have not shipped. Appbot and similar tools let you monitor competitor reviews across stores, which turns their 1-star feedback into your roadmap input.

Best for: finding differentiators, not just parity features.

5. Cluster the free text yourself with an LLM or scripts

If you are doing a one-time pass, exporting reviews and clustering them with an LLM or a Python script gets you a usable list of themes quickly. It is cheap and flexible. The limits are real: the taxonomy resets every run, frequency counts are unreliable unless you are careful, and there is no link to the account behind each review. It is a good way to start and a poor way to run an ongoing process.

Best for: a first pass or a quick validation before investing in a system.

6. Route confirmed requests into your roadmap tool

Finding requests only pays off if they reach the backlog. The last step is pushing a confirmed request, with its supporting reviews and its size, into Productboard, Jira, or Linear through workflow integrations, so it competes for roadmap space with everything else. A request that dies in a spreadsheet was never really found. Our guide on detecting feature requests in support conversations shows how the same routing works across channels.

Why volume is the wrong prioritization signal

The instinct once you have a list of requests is to sort by count and build from the top. It is the wrong default, because count measures loudness, not value. The requests that show up most in app store reviews skew toward consumer power users, who are vocal but not always representative of the accounts that drive revenue. The reframe is to prioritize by weighted demand: the volume of the request multiplied by the value of who is asking. That requires tying each review to the customer behind it, which is precisely what raw store exports cannot do and what a customer context graph is for. For the connection to roadmap decisions, see using customer feedback to prioritize the product roadmap.

How to choose your approach

For a one-time exploration, method 5 (LLM clustering) plus manual routing is enough. For an ongoing program, lead with methods 1 through 3: automatic classification by intent, quantified by weighted demand. Add competitor mining (method 4) when you are looking for differentiation, and wire in routing (method 6) so nothing you find is lost. The decision rule: prioritize requests by who is asking and how much they are worth, not by how many times a phrase appears.

FAQ

How do I find feature requests hidden in app store reviews?

Classify every review by intent and topic so "feature request" becomes a filterable category, rather than reading through reviews manually. An adaptive taxonomy groups every paraphrase of the same ask together, so a request for offline mode is captured whether the user wrote "offline mode," "works without wifi," or "use it on a plane."

How are feature requests different from bugs in reviews?

A bug reports something broken, a request asks for something new, and a complaint criticizes something that exists. They read similarly and get grouped together often, so classifying by intent rather than keyword is what keeps your feature backlog from filling up with defects.

Should I prioritize feature requests by how many people asked?

Not by raw count alone. Volume measures loudness, not value, and ten requests from high-value accounts can matter more than a hundred from users who will never convert. Weight each request by the revenue and segments behind it, not just the mention count.

How does Enterpret find feature requests in reviews?

Enterpret ingests App Store and Play Store reviews, classifies each one by intent and topic with an adaptive taxonomy that learns your categories from the data, and ties it to the account and segment behind it through the customer context graph. That surfaces feature requests as a live, quantified category you can prioritize by weighted demand and route to your roadmap tool.

Can I use ChatGPT or Claude to find feature requests in reviews?

Yes, for a one-time pass. Exporting reviews and clustering them with an LLM produces a usable theme list quickly. The limits are that the taxonomy resets every run, frequency counts can be unreliable, and there is no link to the account behind each review, which makes it better for a first look than for an ongoing process.

If you want feature requests surfaced and sized automatically from every channel, see how Enterpret turns unstructured feedback into a prioritized backlog.

‍