Competitive analysis finds industry convention, not user need

What it is

Competitive analysis systematically compares how other products handle features, flows, information structure, and visuals. The output is a map of industry convention: where this category puts settings, how many checkout steps it uses, which permissions it turns on by default. Convention is the current distribution of market solutions, not an observation of user need. That three products share an entry point shows it has become category-standard. It does not show that target users need it, or that its absence would fail. Writing “competitors all have this” as a need source treats a supply-side description as demand-side evidence.

Why it happens

Products are visible to one another. Design teams, component libraries, and review checklists treat existing modules as mandatory. Frequency then reinforces itself on the supply side: what appears often gets copied more, and a blank looks like an omission. Evidence of need comes from goals, obstacles, and alternative behaviors, which do not appear automatically in someone else’s screenshots. Screenshots are also biased toward survivors—living products get analyzed, withdrawn failures drop out of the sample—so convention looks more “market-tested” than it is. The more complete the analysis, the easier it is to feel that user wants are already known, because the blanks have been filled with a feature table.

Studying it

Align the “common practice” list from competitor coding with independently collected user goals and failure events, counting overlap, competitor-only items, and user-only items. Overlap is not mutual validation; a third material (behavior, tickets, fieldwork) is required to promote a claim. Trace how a convention entered the requirements document; if the chain ends at a competitor screenshot, label it convention rather than need. Comparing new entrants with long-tail products can show whether a convention is only shared packaging among category leaders.

Where it stops holding

Procurement, channel access, and compliance can turn some conventions into real constraints. “Competitors all have this” is then a market condition—still not an end-user need, but a specification that must be met. A brand-new category has almost no convention to map and the analysis goes hollow; look at adjacent tasks instead. Internal “competitors” (legacy versions, sibling products) reflect organizational inertia, which is not the same as external category convention and should be coded separately.

Applying it

• Add an evidence-type column to the competitor table, defaulting to “convention”; change it to need only with separate user evidence.
• Ban “three of them have it” as a reason to build; require a statement of how users would fail without it.
• Ship two lists: conventions to consider matching, and conventions that still need research to confirm or kill—do not mix them on one requirements sheet.
• Audit competitor citations in requirements: demote any item that cannot be traced to a user observation to an untested assumption.

Related

• Same group: Q2.17.1 Benchmark against similar tasks across industries, not peer products · Q2.17.3 Copying a competitor inherits its untested assumptions · Q2.17.4 Separate a competitor’s design intent from its actual effect
• Adjacent: Q2.09 Heuristic evaluation · Q2.10 Expert review
• Search terms: competitive analysis · industry convention · supply-side bias