How to Analyze Competitors

Short version lives on the project dashboard as a three-line strategic note. This is the long version — the working document the note is derived from. If you only skim one thing, skim the thesis in the first H2 and the funnel table near the end.

TL;DR

A competitor table with a star rating and a price column is not competitive analysis. It's a shopping list. Real competitive analysis produces exactly one thing: a defensible reason this project should exist at all, stated as a sentence you could be wrong about, then stress-tested against every competitor you can find until it either survives or breaks.

Do it in this order: (1) state a one-sentence strategic thesis before you research anything, (2) build a competitor table with decision-relevant columns and put yourself in it honestly, (3) run a "dead or irrelevant" pass to throw out competitors that only look alive, (4) run a "who actually makes money" pass to find out which competitors will even bother fighting you, (5) convert findings into tagged verdicts that each end in a decision, (6) chain a funnel from audience to paying users so "success" becomes a number with a realistic time horizon, and (7) map the channels nobody is competing on. All of it in one document, one confidence legend at the top.

This lesson assumes you already wrote the How to Write a Brief — the brief's light two-table competitive sketch is where this starts. This lesson is that sketch, taken seriously.

Confidence legend (reuse across every section)

Same convention as the brief. Do not invent a second one.

• [V] Verified — I checked it directly. A live app store listing, a real pricing page, a dated last-update.
• [A] Assumption, ours — a reasonable estimate we are choosing to act on, but did not verify.
• [?] Open — we don't know yet, and it matters. Flagged so it can't hide.

An analysis with zero [A] and [?] tags is lying. You never have that much certainty this early.

1. Lead with the thesis, not the conclusion

Most competitive analyses build up to a conclusion at the bottom. Invert it. The thesis is the header, and every section below either supports it or dents it.

The thesis is a single sentence that names a specific combination of capabilities that, cross-referenced against everyone you found, nobody else combines. The magic word is "combination." Almost any single capability is already taken. The gap is almost always at an intersection.

Format it as: "Many players do ONE of these. Almost none do both/all."

Thesis (running example — Blockyard, a neighborhood classifieds portal). Plenty of apps do local buy-and-sell. Several do verified real-world identity. Almost none combine (A) verified-neighbor trust — a listing carries a badge proving the seller is a real, address-verified person on your block — with (B) shared household accounts, where several members of one home manage the same listings and message thread without sharing one login. [A]

Write the thesis before you open a single competitor's app. Then spend the rest of the document trying to kill it. If you can't kill it, you have a project. If competitor research quietly destroys it, you just saved yourself the entire build — which is the whole point of doing this before code, in the same spirit the mockup catches architecture surprises cheaply (see How to Build an HTML Mockup).

2. The competitor table: columns are the whole game

The columns you choose decide whether the table reveals anything. "Name / rating / price" reveals nothing, because it doesn't map to your thesis. Choose columns that answer: does this competitor close the gap my thesis claims is open?

So the columns become your two thesis capabilities (A and B), plus one column that most tables never have and that matters most: the specific exploitable weakness — not "they're worse," but a precise gap on an axis your thesis cares about.

And you put yourself in the table, filled in honestly. If your own row doesn't clearly out-cover the gap columns, there is no gap and the thesis is dead.