How to read competitor reviews for product gaps

Customer research is normally expensive because getting strangers to tell you the truth about a purchase is hard. Reviews invert that. People who have already paid, already been disappointed, and have nothing to sell you have written it down voluntarily — with the product named, the failure described, and often the workaround they settled for.

The reason this goes underused is that reading reviews feels like research while producing nothing. You skim thirty of them, form a vague impression that the competitor is "fine but people complain about support", and stop. That impression is not a finding. A finding is specific enough that you could change your offer because of it.

Start with the right question

Do not open the reviews asking "is this competitor good?" You do not care. Open them asking a question you could act on:

• What do people buy this to accomplish? Reviews describe the job in the customer's own words, which is almost never the vendor's words. That gap alone is often worth the exercise.
• Where does it fail them, repeatedly? Not one furious outlier — the same failure, described independently by people who have never met.
• What did they do instead? Workarounds, spreadsheets, a second tool bought to patch the first one. A workaround people maintain by hand is a product that does not exist yet.
• Who says it is not for them? Mismatched buyers reveal the edges of the incumbent's positioning, and the edges are where you can stand.

Read the middle of the distribution

The instinct is to read the one-star reviews, because that is where the anger is. It is usually the least useful band.

One-star reviews are dominated by things that will not help you: billing disputes, delivery failures, an individual bad interaction, and occasionally a buyer who purchased the wrong thing entirely. These are real experiences, but they describe operational accidents rather than structural gaps. You cannot build a position on "their support was rude that one time."

Five-star reviews are the other trap. Many are short, generic, and written under a nudge from the vendor at the happiest possible moment. They tell you the category works, not where it is weak.

The useful band is the middle — the three- and four-star reviews. These come from people who fundamentally like the product and kept using it, and are therefore describing the limitation that survived their goodwill. That is exactly the profile of a real structural gap: not bad enough to leave over, annoying enough to write about. When someone says "we love it, but we still export everything to a spreadsheet every Friday", they have handed you a product requirement.

Separate the three kinds of complaint

Once you have thirty or forty rows, sort every friction into one of three buckets. This sort is the entire value of the exercise, because the buckets have completely different implications.

• Execution complaints. They do a thing badly that they intend to do well — slow support, bugs, a clunky flow. These are fixable by the incumbent, often quietly, and they may already be fixed. A position built here can evaporate without warning.
• Scope complaints. They do not do a thing at all, and it is adjacent to what they do. Sometimes a roadmap item, sometimes a deliberate exclusion. Worth checking their changelog and public roadmap before betting on it.
• Structural complaints. The thing people want conflicts with how the incumbent makes money, who they serve, or how they are built. An enterprise tool cannot become simple without insulting its enterprise buyers. A high-touch agency cannot serve small budgets without breaking its cost structure.

Structural complaints are the ones worth building on, because the incumbent's inability to address them is not a matter of attention. They would have to damage their own business to follow you. That is a durable opening; the other two are races.

Count the pattern before you believe it

The failure mode here is finding one vivid complaint that confirms an idea you already had, and treating it as a market signal. Guard against it with a few cheap rules:

• Require independent repetition. The same friction from several unconnected reviewers, ideally across more than one platform. One eloquent complaint is an anecdote no matter how right it feels.
• Check it recurs across competitors. A friction that appears in reviews of every provider in the category is a category-level gap — the most valuable kind. A friction unique to one provider may just be that provider's bad quarter.
• Weight by recency, and check for fixes. Complaints older than a year or two may describe a product that no longer exists. Look for the point in the timeline where they stop.
• Watch for reviewer mismatch. If the complaints cluster among users who were never the target customer, you have found a targeting artefact, not a gap.
• Read the vendor replies. Public responses tell you what they consider a defect versus intended behaviour. "That is by design" is a strong signal you are looking at a structural gap.

One caution about the sample itself: reviews are not a representative survey. People write them when they are unusually pleased or unusually annoyed, some platforms are actively gamed, and vendors solicit selectively. This method is good at telling you what kinds of problems exist and whether they recur. It is not good at telling you what share of customers have them. Do not convert review counts into percentages and present them as market sizing — that is a fabricated number wearing a lab coat.

Turn the gap into a sentence you can test

A finding is only finished when it survives being written as a claim. Force each one into this shape:

Buyers of [category] repeatedly report [specific friction], evidenced across [n] independent reviews spanning [providers/time]. Incumbents have not solved it because [structural reason]. An offer that [specific response] would be chosen by [specific buyer] over [named alternative].

Most candidate gaps die at this sentence, which is the point — they die on your desk for free, rather than after you have built something. The ones that survive are testable: you can put that promise in a headline, show it to the people who wrote those reviews, and find out quickly whether it lands.

Where to look

Vary the venue, because each has a different bias. Marketplace and app-store reviews skew toward transactional friction; software review sites carry longer, more considered write-ups but heavy vendor solicitation; forums and community threads are unfiltered and often the only place the workarounds get described in detail; local review platforms surface service delivery rather than product design.

Two practical rules. Read what is public — anything behind a login or a scraping ban is not worth the exposure, and public sources are plentiful enough. And record where each quote came from, with the date, as you go. Reconstructing sources afterwards takes longer than logging them, and a finding you cannot source is a finding you cannot defend when someone asks.

The short version

• Read for the job, the recurring friction, and the workaround — not for whether the competitor is good.
• Mine the three- and four-star reviews. That is where structural limits get described by people who stayed.
• Sort every complaint into execution, scope, or structural. Build only on structural.
• Require independent repetition across reviewers and providers before you believe a pattern.
• Never turn review counts into market percentages. Reviews are a biased sample, and they are still the cheapest honest research you have.
• Write each gap as a testable claim. Most will die there, cheaply.