How to run a competitor teardown with Claude Code without inventing facts

What makes a teardown useful rather than a feature list?

A decision it was written to serve. A teardown with no question behind it turns into an inventory of everything three competitors mention on their marketing pages, which is long, feels rigorous and changes nothing. Write the question at the top of the file before you collect anything: should we build tiered pricing, is our onboarding slower than the alternatives, are we the only one without an audit log. The question decides which pages you save and which rows exist in the output.

This is also the step that makes the agent useful rather than merely fast. A model handed an open brief produces breadth, because breadth is what an unconstrained summary looks like. A model handed a specific decision produces the rows relevant to it, and, more usefully, produces the places where the public evidence does not answer the question at all.

How do you collect the sources so the output can be checked?

Save them yourself, to disk, with dates. Create a folder, put each competitor's pricing page, docs index, changelog and any relevant public case study in it as a separate file, and name the files so a human can tell what they are. This sounds fussy and it is the entire foundation of the workflow: the agent can only cite a source that exists as a file, and you can only verify a citation you can open.

The agent can fetch pages for you, and Anthropic notes that web fetch runs in its own separate context window precisely to avoid injecting potentially malicious prompts from fetched content. Even so, fetching at draft time means the analysis is built on whatever the page said at that moment, with no copy to check afterwards. Saving first costs ten minutes and makes every later argument about the document resolvable.

For sources that live in your own systems rather than on the web, competitor mentions in support tickets or lost-deal notes in a CRM, an MCP server can connect Claude Code to those tools directly. Treat adding one as a trust decision: it widens what the agent can read, and Anthropic requires explicit trust verification for a new server on first use.

What does the drafting prompt need to say?

Three constraints, and the third is the one people miss.

First, restrict the evidence: use only the files in this folder, and do not use anything you know about these companies from elsewhere. Second, demand structure tied to the decision: one row per capability relevant to the question, one column per competitor. Third, and this is the one that changes the output, require the model to report absence. Ask explicitly for a list of the questions the saved sources do not answer, kept separate from the comparison table.

That third clause is what stops the document reading as more complete than it is. A teardown with fourteen confident rows and no gaps section is lying by omission, because there are always questions the public pages do not answer, and an analyst who does not name them has either not noticed or filled them in.

Why does verification cost more than drafting, and how do you actually do it?

Because the failure mode is invisible in the output. A row that came from a competitor's real pricing page and a row that came from a plausible reconstruction of one look identical in a markdown table, and the reconstruction is often more confident because nothing in the source complicated it. Anthropic's best-practice guidance generalises the point: the agent stops when the work looks done, so without a check it can run you become the verification loop.

The check that works is mechanical rather than judgemental:

• Every factual row names its source file and quotes the line it came from, in the row itself, not in a bibliography at the end.
• You open each cited file and confirm the quoted line exists there, exactly.
• Any row that cannot produce a quote is deleted, not reworded into something vaguer.

Deleting rather than softening matters. The instinct on finding an unsupported claim is to hedge it into "reportedly around" and keep it, which preserves the shape of the analysis while quietly removing its basis. A teardown with nine verified rows and a named gaps section is a stronger document than one with fourteen rows of mixed provenance, and it is the only version you can defend when someone senior asks where a number came from.

What are you allowed to write down about a competitor?

What their own public materials state, linked and dated. Price, plan structure, published features, stated integrations, documented limits. That is the entire set, and a teardown that stays inside it is both safer and more useful, because facts from a competitor's own pages are checkable by anyone in the room.

Everything else belongs in a clearly separated section written in your own voice as interpretation. Your read on where they are weak, what their pricing structure implies about who they are selling to, which of their public bets you think will not land. Keep that section short and keep it labelled, because the moment interpretation and evidence share a table, the whole document has to be re-verified before anyone can use it.

How long does this take, honestly?

Half a day for three competitors, and the split is not what people expect. Writing the question takes fifteen minutes. Saving the sources takes about an hour, because it is manual and because you keep finding a fourth page worth keeping. The drafting pass takes a few minutes of wall time. The verification pass takes the rest, and it is the part that gets cut when the meeting is tomorrow.

Cutting it is the decision that determines whether the document is an asset or a liability, so make it explicitly rather than by running out of afternoon. A verified teardown of one competitor beats an unverified teardown of four, because the first can be quoted in a strategy document and the second has to be redone by whoever wants to use it. If the deadline only allows one pass, narrow the scope, not the checking.

The second run is much cheaper. The sources are named files with dates, so refetching the same pages and asking what changed since the saved versions turns a half-day exercise into an hour, and the diff is often more interesting than the original teardown was. A competitor quietly removing a plan tier tells you more than the tier list ever did.

What does a teardown feed into?

A strategic choice, not a backlog. The common waste pattern is a good teardown that becomes a list of features to match, which is how a product ends up with a shape defined by whoever else is in the market. Builders Camp's Product Strategy bootcamp frames the useful version as deciding where to compete and where not to, with differentiation grounded in customer reality rather than in a competitor grid, and it runs 2 weeks across 4 live sessions of 120 minutes.

For an AI feature specifically, the teardown question is usually the wrong one until later. Builders Camp's AI Product Management bootcamp puts the deliverable somewhere else entirely: the evals that define what good looks like, the harness the feature runs in, and the business design that captures the value, none of which a competitor's marketing page will tell you.

The skill underneath this is reviewing output you did not produce

Running a teardown is a specific case of a general habit: reading a confident artefact an agent generated and finding the part that is not backed by anything. Builders Camp's Claude Code for Product Managers bootcamp is built around that habit, in 1 week across 2 live sessions and 8 self-paced microlessons, with a practical challenge on catching what an agent changed while you were watching a different part of the output, and a certification quiz at a 70 percent pass mark.

See the Claude Code for Product Managers bootcamp

For the research end of the same job, Perplexity for product managers covers cited web research and NotebookLM for product managers covers working against a fixed source set. The failure this whole workflow is designed around has its own entry in AI hallucination.