Competitor Review Analysis Prompts for Competitive Intelligence

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

That is also why the export matters more than the prompt. A block of review text with the dates stripped out cannot answer the only question a battlecard needs answered. That question is not what people have complained about. It is 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. Then it sits in the listing for years as 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. A cluster still adding mentions this quarter is a live one. A percentage worked out across the whole listing flattens both into the same number. A live cluster is also the material a competitor battlecard needs, because it is the complaint a buyer might raise this quarter rather than two years ago.

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 set of themes 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 is the one people skip, and it decides whether this is a one-off exercise or a measurement. Theme definitions written down once can be pasted into every later run. Definitions worked out fresh each time produce a sensible scheme every time, and never twice the same. The trend you were building then becomes a comparison between two different instruments.

The first codes the reviews. The second 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. Ask a model to code themes and judge which ones matter in one pass, and you get a weaker version of both. 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. They are worth asking in this order.

The third question is the one most often skipped, and it has measurable consequences. The State of Competitive Intelligence Tools found that one criticism, alert noise, came up for all four products often enough to matter. 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. They would then have 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 you have. 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 different. There, someone who broadly likes the product names the one thing that nearly stopped them, and that is the objection a rep will meet in a live deal. Said instead by somebody who left, the same sentence becomes a coded row in a win/loss synthesis, counted against a scheme rather than read.

The coding you have just done describes a set of reviews frozen at the moment you exported it. New reviews arrive all the time, and the ones that matter most are the newest. They are the only ones describing the product a buyer would be buying now, which is what separates this from voice of customer work on your own base.

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

What no monitoring settles is what a theme means for you. Whether a competitor’s recurring complaint is an opening depends on whether your own product genuinely answers it. That is a question about your roadmap, not about their reviews.

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

The habit that carries all of this is the smallest one on the page: write the theme definitions down once and reuse them. The same reviews coded twice against the same scheme produce a trend. Coded against a fresh scheme each time, they produce two pictures that cannot be compared. The same rule decides whether churn reasons can be added up across two quarters, and it is the one nobody writes down.