競品比較中最有價值的一格，是用戶評論中的矛盾

Feature grids tell you what everyone ships. Reviews tell you where the market splits.

Most competitor comparisons end up as a grid. Twelve features down the side, four apps across the top, checkmarks and empty cells. You finish it knowing exactly what everyone ships and nothing about why anyone stays.

The problem isn't the research. It's the unit. The grid is built out of the vendors' own vocabulary — "offline mode", "smart tags", "AI assistant" — and that vocabulary is the least reliable thing in the category. It's marketing copy wearing a row label.

Reviews give you a better unit: the job someone was trying to finish when they opened the app.

Compare one job, not the whole product

Pick the job you're actually competing for. If you're building a habit tracker, that might be "log yesterday's workout two days late, from the couch". Three apps, one job, and you stop reading everything else.

This sounds like it throws away information. It does. That's the point: a comparison that covers the whole product ends up measuring nothing precisely, because every row is answered by a different user with a different job.

Three columns, not one score

For each app, sort what you find into three buckets:

• Praised — what a replacement would have to preserve. This is the part every idea list leaves out.
• Blamed — the friction. The usual complaint pile.
• Disagreed — two reviewers describing the same behaviour, one as the reason they stayed, the other as the reason they left.

The first two columns are what most people already collect. The third one is where the comparison starts paying for itself.

The cell that matters is the contradiction

Say you're comparing three habit trackers, and one of them offers a "skip today, keep the streak" option.

Some reviewers love it, in almost the same words: it stopped them from abandoning the app after one bad day. Others describe the exact same feature as the reason they quit — it made the streak meaningless, so the number stopped meaning anything.

Same behaviour. Opposite verdicts. If you're building the fourth app, this is not a gap to fill. It's a segment boundary.

Copying the praised behaviour wins the first group and loses the second. And notice what you can't resolve from the data: which group is bigger, and which one pays. That's a question for a conversation or a shipped test, not for more reviews.

That's the output I actually want from a competitor comparison — not a longer feature list, but a small number of places where the market splits, each attached to the reviews that show it.

Four rules that keep this honest

Keep the denominator attached. 4.9 from 300 reviews and 4.4 from 41,000 are not comparable, and neither is "most users complain" without a count. For each app, write down how many reviews you read and how many mentioned the job at all.

Three mentions is a hypothesis, ten is a pattern. Below three independent mentions you're reading your own hope into one annoyed person. I keep the raw count next to every line so I can tell later whether I was pattern-matching or guessing.

Quote, don't paraphrase. Every claim in the brief carries the sentence it came from. Paraphrase drifts toward your hypothesis within two rewrites, and by the third you can no longer tell which parts the user actually said.

Praise is not performance. Users saying something works is evidence they believe it works. It is not evidence the app is faster, more reliable, or better built. Star ratings aren't semantics either — a one-star review can describe a missing feature you'd kill for, and a five-star review can describe a bug that's about to cost someone their data.

What you should end up with

Not a feature matrix. Per app: a short praised list, a short blamed list, and the disagreements. Then, out of all of it, one or two contradictions you can't resolve from the data and one question you'd answer by talking to someone.

The contradictions are the valuable part because they're the only cells the grid can't hold. A feature comparison tells you what to build. A contradiction tells you which market you're choosing.

I'm building ReviewFold, which turns App Store and Play reviews into a comparison across several competing apps — strengths, gaps and disagreements, each line linked back to the original review. There's a public example report if you want to see the shape of the output before reading the method. The method itself is written up at how to analyze competitor app reviews, and the "praised" column has its own piece at finding product strengths in app reviews. No signup needed for either.

Written by me; research and editing were done with an AI assistant, and anything I couldn't support with a review quote is marked as a question rather than a finding.