Competitor Review Analysis Prompt Techniques

Reviews accumulate and nothing removes them. A complaint written about a version of a product that shipped two years ago sits in the same list, in the same typeface, as one written last week, and every summary that treats the listing as a description of the product today inherits that. This is the single thing that separates a useful review analysis from a misleading one, and it has nothing to do with how well the summarising is done.

It is also the reason the export matters more than the prompt. A block of review text with the dates stripped out cannot answer the only question a battlecard actually needs answered, which is not what people have complained about but what people are complaining about now.

Themes do not fade, they stop

A criticism that was fixed does not tail off gradually. It stops, usually within a release or two, and then persists in the listing for years as accumulated history. That makes the shape of a theme over time unusually readable: a cluster of mentions ending abruptly eighteen months ago is a fixed problem, and a cluster still adding mentions this quarter is a live one. A percentage computed across the whole listing flattens both into the same number.

Decide before you start what the coding is for, because it changes which themes are worth separating. Coding to brief a rep produces a different taxonomy from coding to inform a roadmap, and a scheme built to serve both usually serves neither. That decision is yours rather than an input you paste, which is why it is not in the contract above.

The second input there is the one people skip and the one that decides whether this is a one-off exercise or a measurement. Theme definitions written down once can be pasted into every later run; theme definitions derived fresh each time produce a plausible scheme every time and never twice the same, which means the trend you were building is a comparison between two different instruments.

The first codes the corpus. The second is the one that separates live problems from historic ones and is worth running every time. The third only makes sense once you have coded your own reviews with the same definitions.

Note what none of them asks for: a verdict. Asking a model to code themes and judge which matter in one pass produces a weaker version of both, because the judgement depends on which decision you are serving and the model has not been told.

Four questions turn a theme table into something that changes a decision, and they are worth asking in this order.

The third question is the one most often skipped, and it has measurable consequences. Our study of 500 verified reviews across four competitive intelligence platforms found that one criticism, alert noise, appeared for all four products at material frequency, while every other significant theme belonged to a single product. A team that had coded only a competitor’s reviews would have read the shared complaint as that competitor’s weakness, and built a differentiator on something nobody in the category had solved.

The four-star review is where the objection lives

The instinct is to read the one-star reviews, and they are mostly the least useful text in the corpus: a customer who hated the product enough to write at length usually had a problem so total that it never came close to being a purchase decision. The four-star reviews are where somebody who broadly likes the product names the one thing that nearly stopped them, which is the objection a rep will meet in a live deal.

The coding you have just done describes a corpus frozen at the moment you exported it. New reviews arrive continuously and the ones that matter most are the newest, because they are the only ones describing the product a buyer would be buying now.

That produces an awkward rhythm. Re-exporting and re-coding monthly is enough work that it gets skipped, and skipping it has a specific failure mode: the theme that was fading when you last looked is the one that either disappeared, which changes your battlecard, or accelerated, which changes it more. Neither is visible until somebody repeats the whole exercise, and in the meantime the analysis reads exactly as authoritative as it did on the day it was correct.

Watching review platforms continuously is ordinary competitive monitoring rather than analysis. Flares tracks what customers are publishing about the companies you compete with, so a new theme or a sudden cluster of mentions reaches you without a fresh export, and the coding you do next starts from what changed.

What monitoring cannot do is decide what a theme means for you. Whether a competitor’s recurring complaint is an opening depends on whether your product genuinely answers it, which is a question about your roadmap rather than about their reviews.