Operations
Part of A closer look at competitive intelligence
Competitive intelligence signals: what each status lets you do
Competitive intelligence signals earn action by status: what shipped, limited release, announced and inferred each allow, and how to close an entry.
A trend deserves action only after you know its status, because what a competitor shipped, what it announced and what you merely suspect call for three different responses.
What to take away
- Sort every signal into shipped, limited release, announced or inferred before anyone acts on it.
- Only shipped and limited release signals support a production change. Announced and inferred ones stay on the watchlist.
- Source each entry from a primary record, not from commentary about it.
- Give each entry an owner, a test and a rollback condition before anyone acts on it.
- Recheck the primary source on a set date and close the entry when the signal dies.
Match the response to the status
Status decides what you may do next. A shipped feature can justify a tested change to your own product, sales or response work. An announcement or an inference can justify only a note and a review date.
| Status | What the record shows | What it supports | What it does not support |
|---|---|---|---|
| Shipped | A dated release note or changelog says it is available | A tested change to product, sales or response work | A claim about how many customers use it |
| Limited release | A dated record names who can use it | Preparation, and a trial of your response | Treating it as available to everyone |
| Announced | A statement of intent with no release record | A watchlist entry and a review date | A production change |
| Inferred | Your own reading of the signs | A question to check against a primary record | Any statement to a buyer |
A status can move in either direction. An announced item becomes shipped when a dated release record appears, and a limited release can stall. Change the status when the record changes, and keep the old line so the history stays readable.
Record where a limited release applies. A regional rollout is a limited release for a team in another market, and Canada-to-US launch positioning covers what changes across the border.
Source the status from primary records
A primary record is the page or document that carries the claim directly, with a date and a status you can point to. Commentary about a release is a lead, not a record, and it should never be the only line on an entry.
- Regulator filings and dockets
- Vendor release notes and changelogs
- Pricing and plan pages
- The competitor's own dated documentation
A dated primary record looks like this. A changelog entry dated 14 March 2025, status shipped: "Added audit log export to the Team plan." That one line names the change, the date and the plan it touches.
For a US public company, the SEC's EDGAR database gives free access to the filings the company makes with the SEC. Save the exact line, the URL and the date you read it, because pages change and the entry must still make sense on the review date.
Give each entry four fields and a close
Each watchlist entry needs a primary record, a status, one named workflow it touches and a review date. Without all four it is a rumor with a date on it.
Four Watchlist Fields
- Observed changeprimary record and effective date
- Limited releaseeligibility and current behavior
- Announcementpublisher wording and stated date
- Inferencereasoning and disproof signal
The named workflow keeps the entry honest. A change at a competitor matters only where it touches one internal process, so name that process, its owner and the test path. An entry that touches no workflow can be closed at the first review.
The review date comes with a stop rule written before the entry is filed. Close the entry when the primary source is withdrawn, the effective date passes with no shipped change, or the effect on the named workflow cannot be reproduced. For positioning claims, positioning trend reviews add an effective date and a rollback condition.
Write the rollback condition before any change goes out: the observation that would make you undo it. That way a reversal is a planned step with an owner, not a debate held after the fact.
Substantiate before you repeat a competitor claim
A competitor's public claim stays unverified until you hold the evidence behind it. The FTC's advertising substantiation policy says advertisers and ad agencies need a reasonable basis for advertising claims before they are disseminated.
That standard also applies to how you talk about a rival. Copying a competitor's claim into a battlecard, a launch deck or a landing page makes their evidence gap yours. Log the source date and its limits beside the decision, and keep the competitive intelligence file as the single place where a claim is either backed or dropped.
A competitor's figure needs the same check. Before you plan around a number, test it the way a positioning benchmark claim is tested: who measured it, over what period, and against what.
Worked example: one signal, three statuses
Take the changelog line above. Suppose the competitor first announced an audit log export. At that point the status was announced, so the entry carried a review date and no action. When the dated changelog line appeared, the status moved to shipped.
The named workflow then got a test, and the entry gained a rollback condition. Had the changelog line never appeared, the entry would have closed on its review date. Outside lists work the same way: a signal in go-to-market strategy trends or product marketing strategy trends is a lead until a primary record backs it.
Common questions
What is the first decision?
Name the owner, the audience, the outcome and the dated evidence file. Then state what evidence would stop the work, so the entry can be closed without an argument.
Can an inferred signal ever justify action?
Not a production change. Check it against a primary record. If none exists, hold it as a question with a review date.
When does an entry leave the watchlist?
When the primary source is withdrawn, the effective date passes with no shipped change, or the effect on the named workflow cannot be reproduced. Close it on the review date and note why.
What should a team avoid?
Copying competitor claims and carrying stale feature lists. Preserve the affected record and correct the public or internal output where the error appeared.
