AI for competitive battlecards: one sourced link per claim, or the row does not ship

What is a battlecard actually for?

It is a claim document built almost entirely from facts you do not control. Every line about another company can change the week after you write it, without anyone telling you, and your sales team will still be reading the old version. That property, not the writing, is what makes competitive material hard, and it is why a battlecard should be designed around verification rather than around persuasion.

The failure everyone recognises: a rep confidently states that the other product cannot do something, the buyer says it shipped in March, and the rest of the call is spent recovering. The card did not cause that by being too soft. It caused it by carrying a claim nobody could trace back to a page.

So the method below is mostly about structure, and only a little about what AI can write.

The rule that makes everything else work

Every row on the card carries three things, and a row missing any of them does not ship:

• The claim, stated as a plain fact with no adjective attached.
• A link to the source, which is the other company's own current public page, opened by a person on the day the row was written.
• The date it was checked, printed on the card where a rep can see it.

That is the entire discipline. It is unglamorous and it removes most of the exposure, because an unverifiable claim becomes structurally impossible to add without someone noticing the empty field. It also gives the card an honest expiry signal: a rep looking at a row checked eight months ago knows to verify before saying it out loud.

The legal frame points the same way. The FTC's policy statement on comparative advertising supports truthful, clearly identified comparisons, and the corresponding rule in 16 CFR 14.15 is explicit that comparative advertising is acceptable where the comparison is clearly identified, truthful and not deceptive. What creates risk is the unsubstantiated claim, not the act of comparing. Sourcing every row is what substantiation looks like in practice.

A worked example, with two products that do not exist

Take two invented products so the method is visible without anyone's real page being mischaracterised here. Loopdesk is yours: a workflow tool for operations teams. Quellmark is the alternative you keep meeting in deals. Both are fictional, invented for this page.

A weak row reads: "Quellmark has poor reporting." That is an adjective, it is unsourceable, it will sound defensive in a call, and it will be wrong the moment Quellmark ships a reporting update.

A strong row reads: "Quellmark's published plan comparison lists scheduled exports on its top tier only (checked 18 September 2026, link to their pricing page). Loopdesk includes scheduled exports on every paid plan." Both halves are facts. Neither half characterises the other company. A buyer who checks will find exactly what the row says, which is the outcome you want, because the buyer will check.

Then one more field, which is the field that actually wins conversations: "If the prospect already has Quellmark and only needs exports, this is not a reason to switch." A card that tells a rep when a comparison does not apply is a card a rep trusts on the rows where it does.

Write every row assuming the other company will read it, because eventually one will. Competitive material is pasted into buyer emails, quoted in procurement threads, and forwarded by a prospect who knows both vendors. Marking a document internal changes nothing about where it travels. The practical test before a row ships: if this sentence appeared in front of the company it describes, would you defend it as accurate, or would you explain that it was only meant for internal use? The second answer means the row is wrong, not that the distribution failed, and deleting it costs you nothing you were entitled to keep.

What should the model do, and what must it never do?

Do not ask a model what a competitor offers. Its account of another company's pricing or packaging comes from training data of unknown vintage, and it arrives in the same confident register whether it is current or two years old. Anthropic's own guidance on reducing hallucinations points at the workable pattern: restrict the model to documents you supply, and give it explicit permission to say it does not know. Applied here, that means you open the page, you copy the text, and the model works from that text only.

Inside that constraint, a model is genuinely good at four jobs. It normalises: eight rows written by four people become one consistent shape. It strips adjectives: ask it to rewrite every row as a fact with no characterisation and it will catch the ones you stopped seeing. It drafts the honest limitation field, which humans skip. And it generates the questions a skeptical buyer would ask about your own side of the comparison, which is the counter-argument pass that Product Marketing with AI builds into its positioning module.

The fifth job is the one worth setting up properly. Save the text of each source page when you check it. Next quarter, give the model the old text and the new text and ask what changed. Diffing public pages is dull, high-volume work that people do badly by eye, and it is the step that keeps a card alive rather than the step that creates one. Perplexity for product managers covers the retrieval half of this, where citations are part of the default output, and Claude Code competitor teardown covers doing the collection and comparison from a terminal.

Why most battlecards are answering the wrong question

Here is the counterargument to the whole artefact. Teams build battlecards because reps report losing to a named alternative, but "we lost to Quellmark" is frequently not what happened. Deals stall because nobody inside the buyer owned the change, because the problem was not expensive enough this quarter, or because the buyer expected something different from what your own material implied. A card comparing feature rows cannot fix any of those, and building one lets a team feel busy while the real loss reason goes unexamined.

Before building the card, cluster the actual lost-deal notes and see how many name a competitor at all. If most do not, the work is expectation-setting and qualification, which is the ground Sales for Product Managers covers when it separates an objection that is a product gap from one that is a messaging problem. If your positioning is the thing sending the wrong signal, the fix sits in product positioning, not in a comparison table.

And if the pattern is that you keep meeting the same alternative in the same segment, that is a strategy question about where you compete and where you decline to, which is what Product Strategy works through as segmentation and defensible choice. A battlecard is downstream of that decision; it cannot substitute for it.

Build the review before you build the card

The card is a week of work. Keeping it true is the standing cost, and the teams whose competitive material stays useful are the ones that decided the review cadence before the first row was written: who re-checks, how often, and what happens to a row whose source page has moved.

Write the date field into the template first. It is the only part of a battlecard that tells the truth about itself.

See the Product Marketing with AI bootcamp

For the audience definition that decides which comparisons matter, ideal customer profile is the shorter read.