How to use AI for competitive analysis that survives a check

What is AI actually adding to a competitive analysis?

Reading speed across sources you chose, and nothing else. A model will work through forty pages of a competitor's documentation, terms, changelog and careers page and come back with a structured summary in the time it takes to make coffee, and that is a genuine change in what a small team can cover.

What it is not adding is knowledge of the competitor. The failure mode of every AI competitive analysis is the same: someone asks the model what a company charges, gets a confident answer, and puts it on a slide. Anthropic's own model documentation publishes two separate dates for each model, a training data cutoff and an earlier reliable knowledge cutoff, which is the vendor stating plainly that the most recent stretch before the cutoff is thinner than the rest. A competitor's pricing page changed last month sits inside exactly that gap.

Rank your sources by how costly it is to be wrong in them

This is the whole method, and it takes one minute to apply. Put at the top the things a company is bound by: regulatory filings, terms of service and data processing agreements, the published price list, the status page, the changelog, the API reference, and the job adverts. All of those cost something to misstate, which is why they are the most reliable public description of what a company actually does. PostHog, for one, publishes its full price list openly, which makes pricing a quotable fact rather than a rumour; where a competitor does not publish, the honest row is "not public," not an estimate.

Below that sits marketing: the homepage, the case studies, the conference talk. Useful for reading positioning, useless as a description of the product. Below that sit third-party roundups and comparison sites, most of which are recycling each other. And below everything sits a model answering from memory.

A model given the top tier and told to use nothing else produces a boring, accurate document. The same model given a search tool and a vague prompt will quietly promote a comparison blog to the top of that list, because it reads like an answer.

Run collection and verification as two separate passes

Collection first: fetch and save the actual pages, one file per source, with the URL and the access date written into the file. Not a summary of the page, the page. The point of saving is that the verification pass has something to check against, and a summary cannot be checked against itself.

Then draft against those files and nothing else, with the instruction made explicit: every factual row cites the file it came from. Then verify, as a separate pass, ideally on a different day or by a different person, because checking your own draft an hour after writing it mostly reproduces your own assumptions.

The verification pass: a quote, a URL, a date, or it goes

Each row in the claim register gets four fields: the claim, the exact quote supporting it, the source URL, and the date the page was read. A row that cannot produce all four is deleted. Not hedged, not marked "approximate," deleted.

That rule sounds harsh until you have watched the alternative. A softened claim travels: it appears in the appendix as "roughly," gets summarised into the body as a figure, and turns up in a board deck six weeks later with no hedge attached and nobody able to say where it came from. Deletion is the only edit that actually removes a claim from circulation.

Save a dated snapshot while you are there. The Internet Archive's Wayback Machine will archive a page on request, and a competitor's pricing page that changes silently is exactly the case the archive exists for. For a company with filed accounts, the register is better still: the UK's Companies House, and its equivalents elsewhere, publish filings that carry legal consequences for being wrong.

What does the model get confidently wrong about a competitor?

Three things, in order of frequency.

• Pricing tiers. It will reproduce a plan structure that was replaced, often with the old plan names intact, and there is no tell in the output that anything has changed.
• Feature absence. "They do not have X" is the single least reliable output in competitive research, because absence from the model's recall is not absence from the product.
• Company size and funding. Round numbers about headcount and raised capital circulate widely in secondary sources, which is precisely why they end up in training data unattached to any primary record.

Feature absence is the one to watch hardest, because it is the claim most likely to shape a roadmap. Build against a gap that does not exist and you spend a quarter finding out.

Which comparisons actually change a decision?

Not the feature grid. The grid is what gets asked for and it is the artefact least likely to alter anything, because every row reads as parity and the rows that matter are never binary.

What changes decisions is structure. Where does a plan boundary sit, and what specific action pushes a customer across it? How does packaging map to buyer size, and which buyer is each tier really built for? How often does the changelog move, and on which surface? What do the open roles imply about where investment is going next quarter? Those questions are answerable from public sources, they are quotable, and each one leads directly to a choice about your own packaging or roadmap. The vocabulary for turning that into a position is in product positioning and value curve analysis.

The honest limitation of a public-source teardown

Public sources describe what a company ships, never what is failing inside it. You cannot see their churn, their renewal rate, which feature the sales team apologises for, or which segment they have quietly stopped serving. A teardown built entirely on public material will therefore always overweight what is visible, which is the marketing surface and the shipped product.

The correction is customer conversations, specifically with people who evaluated both and chose one. Five of those will tell you more about a competitor's real weakness than forty pages of their documentation, and no model can substitute for them.

The second correction is cadence. A teardown is a snapshot with a shelf life measured in weeks for a fast-moving product, so the useful artefact is not the document but the watch list underneath it: the handful of pages whose change would alter your decision, checked on a schedule. Monitoring six URLs monthly beats rewriting a forty-page teardown twice a year, and it is the part a model is genuinely well suited to running.

Write the decision at the top before you collect anything

A teardown with no decision attached becomes a document nobody rereads. Name the choice first: whether to add a tier, whether to defend a segment, whether the gap you think you see is real. Then collect only what bears on it, and the register stays small enough that verification actually happens.

See the Product Strategy bootcamp

Product Strategy runs two weeks with 4 live sessions and 8 microlessons and is built around choices you can defend: what to build, who it is for, and why you win. Product Marketing with AI covers the market to narrative to launch loop in one week, and Growth for Product Managers covers what to do with a positioning finding once it is real. For the tooling mechanics, see running a competitor teardown with Claude Code and Perplexity for product managers.