Careers
Part of A closer look at competitive intelligence
How to research competitive intelligence for business teams: the honest picture
Competitive intelligence for business teams turns rival evidence into launch decisions, with dated sources, win loss notes and claims your proof can carry.
What to take away
- Rank every positioning claim against the evidence you hold, and cut the ones you cannot show a buyer.
- Run competitive intelligence as a dated file, not a folder of screenshots, so a claim can be traced to its source and its date.
- Interview three to five won and lost buyers after each launch phase; their language beats any competitor teardown.
- Give sales enablement assets an owner and a review date, or they drift out of step with the product.
- Write down what would stop the launch, and who decides.
Build the evidence file before the messaging
Start with what you can date. A competitor's pricing page, a job posting, a patent filing, a trade show booth, a changelog entry: each is a fact with a timestamp. Screenshots without dates are opinions.
Named sources and what they can tell you
Competitive-intelligence platforms such as Crayon and Klue can monitor competitor changes and surface leads for follow-up. Treat an alert as a prompt to check the original page, not as evidence on its own; a capture may miss context or when a change took effect.
For public-company filings, search SEC EDGAR. For patent records, use USPTO Patent Center or Google Patents. These sources document filings, not whether a feature is available or a launch is imminent.
G2 and Capterra offer user reviews; Gartner and Forrester publish analyst research; Crunchbase, LinkedIn, Glassdoor, and Similarweb provide company, hiring, or traffic signals. Reviews can reflect a self-selected group, analyst reports may be paywalled, and company databases or traffic estimates can be incomplete or out of date. Check each claim against a primary source where possible.
A repeatable competitor-research pass
For example, if you are positioning a launch against Salesforce and HubSpot, gather evidence about the same product dimension from each company’s public product pages, release notes, and pricing pages. Check SEC EDGAR filings where relevant, and use G2 or Capterra reviews as customer-reported context—not as proof of a product claim.
Start by writing the launch question and the competitors you need to understand. For each finding, record the source title, URL, date accessed, the source’s own publication or update date if available, and the exact statement. Separate what the source says from your interpretation, and seek an independent source or buyer interview for claims that could change a launch decision. Recheck important evidence before it goes into messaging, and mark conflicting or stale information rather than presenting it as settled.
Evidence File Columns
- Claimwhat the competitor says
- Sourcewhere you found it
- Datetimestamp of the fact
- Confidenceyour own label
- Unsourced items stay out
Keep research to information obtained lawfully and ethically. SCIP’s Code of Ethics offers a professional standard for competitive-intelligence work; do not impersonate people, solicit confidential information, bypass access controls, or access systems without authorization. In the United States, the Computer Fraud and Abuse Act (CFAA) addresses unauthorized access to protected computers. For research involving personal data or questions about site terms, get qualified legal advice; the applicable rules depend on the circumstances.
Rank claims by what you can prove
Sort every candidate claim into three tiers.
- Demonstrated.You have a test, a customer result, or a documented specification. This tier can carry the headline.
- Supported.You have partial evidence, a pilot, or a credible third party. This tier belongs in the body, with the limit stated.
- Asserted.You believe it. This tier goes in the internal deck and nowhere else.
Most launches fail on tier three claims that reached the website. A claim that outruns its proof gets corrected in public, usually by a buyer.
For pilot design, the NIST experimental design selection guidance starts from the objective and the practical constraints. That split matters: descriptive reporting and a controlled effect estimate are different jobs. Decide which one your pilot is doing before you collect data.
Where AI enters the workflow
If a model drafts competitor summaries or sorts interview notes, the NIST AI RMF Playbook lists voluntary actions under govern, map, measure and manage. It is a reference, not a certification, and it does not rank vendors.
Set one rule: no AI summary enters the evidence file without a human checking the source. The failure mode is a confident paraphrase of a page nobody opened.
Run the win loss interviews
Interview buyers who chose you and buyers who did not. Three to five per phase is enough to hear patterns. Ask what they compared, what they expected to pay, and what nearly stopped them.
| Phase | Who you interview | What you record |
|---|---|---|
| Pre launch | Five target buyers | Their words for the problem |
| Pilot | Three pilot users | What broke, what they worked around |
| Post launch | Won and lost deals | The comparison set they actually used |
Record the buyer's phrasing verbatim. Their words become the headline; yours become the footnote.
Keep the enablement assets current
Sales enablement fails quietly. A battlecard written in March is wrong by September and nobody notices until a rep repeats a stale feature list to a buyer who has already evaluated the competitor.
Give each asset an owner, a version, and a review date. Retire anything past its date rather than leaving it in the folder. Check that the structure of your comparison tables is available to screen readers, as the W3C guidance on information and relationships sets out, since a table that only works visually excludes part of your audience.
Common questions
What should the evidence file contain?
One row per claim, with the source, the date you found it, and your confidence label. Anything unsourced stays out of the positioning document and out of the enablement assets.
How do we know a claim is ready for the website?
It sits in the demonstrated tier: a test, a customer result, or a documented specification you can show on request. Supported claims can appear if the limit is stated next to them.
When should a launch be stopped?
Write the stop condition before launch day and name the person who can call it. Common triggers are a pilot that cannot be reproduced, a claim that fails legal review, or a competitor move that removes the problem you were solving.
