Strategy
Part of A closer look at competitive intelligence
Working through the competitive intelligence checklist in order
A competitive intelligence checklist walks from source register to claim audit, so each competitor claim is dated, sourced and safe to repeat.
What to take away
- Run the competitive intelligence checklist in order. A claim audited before its source is dated is an audit of nothing.
- Every competitor claim gets a source, a collection date and a shelf life. Undated claims are the ones that get repeated after they stop being true.
- Copying a rival's wording is the failure mode this list exists to stop. Rewrite the claim or drop it.
- Descriptive reporting and a controlled effect estimate are different jobs. Pick one before you collect.
- Keep the finished checklist with the release it cleared.
The competitive intelligence checklist, step by step
The list runs from raw collection to published claim. Each step feeds the next, so a step skipped early shows up as a claim you cannot defend at launch.
Checklist: Collection to Published Claim
- Source registerURLs, pull dates, snapshots
- Claim inventoryevery repeated competitor claim
- Claim auditverified, unverified, expired
- Evidence filesource attached to claim
- Privacy passrun before collection
- Source register.List where competitor facts come from: SEC EDGAR for US filings, Companies House for UK filings, and the USPTO's patent and trademark searches for IP. Add pricing pages and release notes. Record the URL, the pull date and who pulled it. Save a dated Wayback Machine snapshot: a source you cannot re-open is not a source.
- Claim inventory.Write down every competitor claim your team repeats, in the words your salespeople actually use. Add any comparison lines pulled from G2 or Capterra review grids. This is the list that gets audited.
- Claim audit.Mark each claim verified, unverified or expired, with the reviewer and the date. Expired claims are the quiet problem: a feature list from eighteen months ago still sits in a deck. Give each verified claim a shelf life. Ninety days is a workable default.
- Evidence file.Attach the source to the claim. Where the source is a person, record the role and the date, not the name, unless they agreed to be quoted.
- Privacy pass.Run the privacy check before collection, not after, whenever the research touches call recordings, contact lists or CRM notes. Call-recording tools such as Gong and Chorus capture buyer conversations, so confirm consent first.
- Gap list.Note what you could not verify. This becomes the research queue, not a set of assumptions to fill in later. Rank it by how often the claim shows up in live deals.
- Rewrite or cut.Rewrite the claim in your own words or drop it. If the number came from the competitor's page, say so and date it. If it came from nowhere, cut it.
- Refresh trigger and release gate.Set the date or event that forces a re-check: a competitor launch, a price change, a funding round. Crunchbase and PitchBook track funding rounds. EDGAR 8-K filings flag material events. Keep the finished checklist with the release it cleared.
Steps two and three are where programs drift. A team stops collecting and starts speculating, and the speculation reads exactly like evidence in a slide.
Copying a competitor's claim is the failure mode
Case 165 is the pattern: a launch deck carries a rival's phrasing almost word for word, including a performance number nobody on the team measured. It survives review because it sounds like the category standard.
Can You Source the Claim?
Does the claim have a dated, re-openable source?
Keep it, cite the source and date in the deck
Cut it, or move it to the gap list
The fix is a source, not softer wording. If the number came from the competitor's own page, say so and date it. If it came from nowhere, cut it. A claim you cannot source is a claim your buyer can disprove in one search.
Stale feature lists fail the same way. A comparison table built two quarters ago will name features a competitor has since shipped or dropped. Rebuild the table from the current source register before every launch.
Descriptive reporting or a controlled estimate
The NIST experimental design selection guidance starts with the objective and the practical constraints, then picks the design. That order matters here.
If you are describing what competitors do, you are reporting. If you are claiming your change caused a shift in win rate, you need a controlled comparison, and you need to say what you held constant. Most competitive intelligence programs claim the second while doing the first.
Write down which one you are doing before you collect a single data point. The competitive intelligence working file should carry that decision, the approved scope, the version and the owner.
Privacy checks belong in the collection step
Competitor research that touches personal data, such as call recordings or contact lists, needs a privacy pass before collection, not after. The W3C Privacy Principles set out shared concepts for system designers and warn against pushing privacy work onto individuals.
The NIST Privacy Framework starting guide describes a voluntary process for identifying privacy risk, assigning owners and recording responses. It is a management aid, not legal clearance.
For Canadian teams, PIPEDA, CASL and Quebec's Bill 96 each touch how you collect, store and message. Name the statute, then get qualified Canadian counsel to confirm how it applies to your collection method.
Software and supplier checks
When the competitor you are tracking is a software supplier, add supply-chain questions to the source register. The CISA software acquisition fact sheet points buyers toward development practice, supply-chain exposure, deployment and vulnerability management.
Wappalyzer and BuiltWith read a supplier's stack from public page source. That tells you what they run, not how well it holds up.
Those answers describe the supplier. They are not approval to publish anything about it.
Worked example: auditing one claim
| Field | Test | Recorded result |
|---|---|---|
| Claim | "Competitor X ships weekly." | As written in the sales deck |
| Source | Release notes page, pulled 14 October | URL, pull date and a Wayback snapshot |
| Status | Verified, expires in 90 days | Reviewer and date |
| Rewrite | Claim restated in our own words | Draft kept in the working file |
| Action | Keep, with source cited in the deck footnote | Owner and next check |
A claim that fails the source test goes to the gap list, not back into the deck.
Common questions
What is the first step?
Build the source register. Every later step depends on being able to re-open the document a claim came from.
What belongs in the source register?
Primary filings, pricing pages, release notes, job ads and review grids, each with a URL, a pull date and a collector's name.
How often should the list be refreshed?
Set a trigger rather than a calendar. A competitor launch, a price change or a funding round should force a re-check of the claims it touches.
What if a claim cannot be verified?
Move it to the gap list and stop repeating it. An unverified claim in a launch deck is a liability, not a placeholder.
Does this replace legal review?
No. Privacy, competition and advertising rules vary by jurisdiction. Name the regulator, then take advice from qualified counsel.
