What should you analyse in your top competitors app reviews?

App store reviews are one of the few places where users say exactly what they think, without a moderator, a survey structure, or a brand relationship getting in the way. For a competitor's app, that honesty is available to anyone who knows how to read it properly. Most product teams scan reviews for star ratings and move on. The teams building sharper products treat the same data as a window into what a market actually wants, and what it is not getting.

App reviews are a window into what a market actually wants, and what it is consistently not getting.

The question is not whether you should read competitor reviews. Of course you should. The question is what you are looking for when you do. A one-star rating tells you a user was angry. It does not tell you why, what they expected, what they had been using before, or whether their complaint represents a pattern shared by thousands. Getting useful intelligence out of review data means reading with a specific framework in mind, not just scrolling until something catches your attention.

Across the chapters below, we work through the different layers of competitor review data and what each one can tell you. Some of it is about features. More of it is about emotion, context, and expectation. Read together, these layers build a picture of where a competitor is genuinely failing its users, and where your product has room to do something meaningfully different.

Recurring complaints about missing or broken features

The most obvious starting point is also the most actionable. When users complain about the same missing or broken feature across dozens of reviews, they are telling you about a gap the current market leader has chosen not to fill, or has not yet managed to fix. That gap is a product decision waiting to be made.

The signal worth paying attention to is the pattern. According to Ministry of Programming, a complaint appearing in around 15% of reviews is a meaningful signal worth investigating. At that frequency, you are no longer looking at individual frustration. You are looking at a structural failure the product team either does not know about or has deprioritised.

Broken features and missing features are worth separating. A broken feature tells you the competitor built the thing but delivered it poorly. A missing feature tells you users expected it and it was never there. Both are useful, but they point to different opportunities. A broken feature signals execution failure. A missing feature signals a deliberate or unconscious product decision you can challenge.

When cataloguing recurring complaints, keep broken features and missing features in separate columns. The distinction tells you whether a competitor has tried and failed, or simply has not tried.

What users expected versus what they actually received

Expectation gaps produce some of the most revealing content in any review set. A user who got exactly what they expected rarely leaves a review at all. The ones who do write are often describing the distance between what the app promised and what it delivered, and that distance is exactly what you need to understand.

Reading for expectation gaps means looking past the complaint itself to the assumption behind it. A user who writes "I thought this would let me track my progress over time but it only shows today's data" is telling you two things. First, that the competitor's marketing or onboarding created an expectation the product did not meet. Second, that longitudinal tracking is a genuine user need in this category that has not been addressed well.

This connects to something we ask at the start of most projects. What are users doing right now to meet this need, and how do they feel about it? When reviews reveal that users expected a feature that does not exist, they are often describing their current workaround and why it is not good enough. That context is more useful than the complaint itself.

Pay particular attention to reviews from users who rated the app three stars. They are often the most articulate about the gap between expectation and reality, because they sit in a middle register of measured dissatisfaction. They are describing a specific mismatch, clearly.

Emotional language and the frustrations behind it

Users do not write app reviews in neutral language. When something goes wrong, the words they choose carry information about the emotional weight of the failure, and that weight tells you how much the problem actually matters to them in practice.

There is a behavioural dynamic worth understanding here. Users are more likely to leave a review after a negative experience than a positive one, because the frustration creates a need to express it. As Simon has observed, people tend to assume that positive feedback primarily benefits the company rather than other users, so they are less motivated to provide it unless they have had a genuinely bad time. This means the emotional language in negative reviews is often raw and specific in a way that positive reviews are not.

Emotional language in reviews tells you the weight of the failure, not just the fact of it.

Words like "useless", "embarrassing", "infuriating", and "let me down" signal something more than inconvenience. They signal that the user had a meaningful moment of need and the product failed them at that moment. Travel apps are a good example of this pattern. When a travel app cannot show a boarding pass or itinerary offline, users do not write measured critiques. They write one-star reviews that describe the experience as stressful or humiliating, because the failure happened at an airport or a station with no connectivity and real consequences. The emotion is proportional to the context, and the context tells you exactly how critical the feature is.

Cluster emotional language by severity, not just topic. "Annoying" and "humiliating" are different signals even if they describe the same feature failure.

Scope creep signals: when reviews reveal an app is trying to do too much

One of the most useful things competitor reviews can reveal is not a specific feature problem, but a structural one. When users consistently describe an app as confusing, cluttered, or hard to navigate despite acknowledging that it has many features, you are usually looking at a product suffering from scope creep.

We worked directly on a project like this with a grassroots football app. The client compared every individual feature in their product to best-in-class single-purpose competitors and insisted the booking flow needed to be more intuitive. We pushed back but ultimately complied with the requests. The changes made little to no difference. The real issue was that the client was trying to do too many things in one product. There was a reason those features existed across several separate apps. Despite our efforts to build something cohesive and emotionally grounded, the result was overly complex, too verbose, and not fit for the audience or its core purpose.

Competitor reviews flag this pattern clearly. Look for reviews that combine positive and negative sentiment in the same sentence: "Great for X but completely overwhelming for Y", or "I only use it for one thing because the rest of it confuses me." These are signs that users have found a narrow use case that works and are ignoring the rest of the product. That ignored portion represents wasted development and often drives down the overall rating unfairly, because users are frustrated by parts of the app they did not even want.

• Reviews that praise one feature while ignoring all others
• Complaints about an unclear purpose or confusing navigation
• Users asking for a "simpler version" or a way to turn features off
• Confusion about which problem the app is actually for

The difference between feature requests and unmet needs

Reviews often contain feature requests, and product teams often treat those requests as direct briefs. That is a mistake. A feature request describes a proposed solution, not the underlying problem. Building to the request without understanding the need behind it produces features that technically answer the question and practically miss the point.

A user asking for a dark mode might actually be struggling with eye strain during evening use. A user asking for a sharing button might be trying to coordinate purchases with a partner. A user asking for filters might be overwhelmed by the volume of content and looking for any way to narrow it. In each case, the feature request is a symptom. The unmet need is the disease, and solving for the symptom without diagnosing the disease produces a product that still does not quite work.

This distinction matters when you read competitor reviews because it shapes what you build in response. If you build the feature a competitor's users asked for, you are matching the competitor. If you understand the need behind the request, you have the chance to solve it better than either party has managed so far.

The question to ask for every feature request in a review is: what were they actually trying to do, and why could they not do it? That answer is the brief. The feature they named is just one possible response to it.

For every feature request you find in a review, write one sentence describing the underlying need it points to. Build to the need, not the request.

Reviews that reveal context and use case, not just opinion

The most valuable reviews are often the ones that describe a situation, not just a verdict. A user who writes "terrible app" tells you nothing useful. A user who writes "I was trying to check my order on the train and the app needed a signal to load my purchase history, which is absurd" tells you the use case, the context, the failure, and the implicit expectation all in one sentence.

Context-rich reviews are worth reading carefully because they describe how and where the product is actually being used. This is often different from how the product team imagined it being used, and that gap between design intent and real-world use is where a lot of product failures live. A wellness app might be designed for quiet morning sessions at home but used primarily on lunch breaks, standing up, one-handed. A food and drink app might be built for leisurely browsing but opened under time pressure at a supermarket. The product that works for the designed context may fail completely in the actual one.

When we evaluate a competitor product, one of the questions we start with is how users are currently meeting this need and what their day actually looks like when they do it. Reviews that describe a context answer that question directly from the outside. A user describing where they were, what they were trying to do, and what went wrong is giving you ethnographic data without the research budget.

Look specifically for reviews that mention time pressure, location, other people present, or device constraints. Each of those details maps to a real use case your product can be designed to handle better.

What high ratings can still tell you about unresolved friction

Four and five-star reviews are easy to dismiss as satisfied users with nothing useful to say. That is a missed opportunity. High-rated reviews frequently contain passing mentions of friction that the user decided to tolerate because the rest of the product was good enough. Those tolerances are exactly what a competitor should target.

A user who gives four stars and writes "love this app, wish the checkout was a bit less clunky" has told you the competitor has a checkout problem that loyal users are living with. They are not angry enough to leave, but they are not delighted. A product that solves the checkout problem and matches the rest of the experience wins those users easily, because the competitor has already trained them to expect better.

This is related to a broader pattern we pay attention to: silence is not always approval. Users frequently stop using apps without submitting complaints, cancellation reasons, or support tickets. The absence of outrage does not mean the experience is working. High-rated reviews with buried caveats are the visible edge of a much larger group of quiet leavers who found something similar and switched without saying why.

Organising review findings into a usable brief

Reading competitor reviews is only valuable if the findings feed into something. Raw observations sitting in a document do not change a product. Patterns organised into a clear brief do.

The approach we use starts with grouping findings by the type of signal they represent. Broken features go in one group. Expectation gaps go in another. Emotional severity gets noted alongside each item. Context and use case details get pulled out separately because they inform design decisions that cut across multiple features. Feature requests get rewritten as underlying needs before they go anywhere near a product decision.

One practical principle here is that not every review carries equal weight. A complaint from a user who fits your target audience precisely is more useful than the same complaint from someone using the product in a context you are not building for. Before drawing conclusions from any cluster of reviews, it helps to ask who wrote them and whether their situation matches the users you are actually designing for. This is a habit we bring to our own research too: understanding the profiles of who answered before deciding how much weight their feedback deserves.

According to Ministry of Programming, analysing fifty to one hundred recent reviews from each of your top five competitors gives you a workable sample for pattern detection. That is a manageable scope for a structured review session, and it is enough to surface the recurring signals that matter.

1. Group findings by signal type: broken features, missing features, expectation gaps, emotional severity, context and use case
2. Rewrite every feature request as the underlying need it describes
3. Note which findings come from users who match your target audience
4. Identify the top three patterns with the strongest frequency and emotional weight
5. Write a one-paragraph brief for each pattern describing the problem, the user context, and the design opportunity

Conclusion

Competitor app reviews are a market research resource that renews itself every day. Users describe what they needed, what they expected, what went wrong, and how it made them feel, in their own words, without any prompting. For a product team that knows how to read them, that is a continuous brief for where the market is underserved.

The framework matters as much as the reading. Star ratings on their own produce a number, not a direction. Patterns in complaint language, emotional weight, expectation gaps, scope creep signals, and use case descriptions together produce something closer to a design brief. They tell you what users were trying to do, where the product failed them at a meaningful moment, and what a better version of this product should actually be.

The grassroots football project we described earlier was a direct lesson in what happens when review signals are read but their structural implication is ignored. The booking flow was not the problem. The scope of the product was the problem. Reviews were pointing at complexity and confusion. The brief kept returning to a single feature. Getting from the surface complaint to the real issue is the skill, and it applies as much to a competitor's reviews as it does to your own.

If you are building a product in a competitive market and want to turn review data into a clear direction, let's talk about your product strategy.

Frequently Asked Questions