Run Competitive Deep Research with a Verification Ledger

Workflow area: Competitive & Market Analysis · Tier: Core · Hands-on time: ~40 minutes

Competitive analysis is where AI research shines and where it burns PMs publicly: pricing pages change monthly, features get announced and quietly killed, and deep-research agents cite with equal confidence a competitor's current docs and a 2023 blog post. The fix is not "don't use AI research" — it's refusing narrative output. A claims table with per-claim sources and freshness dates converts a persuasive essay into an auditable artifact, and the verification ledger converts your skepticism into a reusable calibration record: you learn which claim types your tools get wrong.

When to use — and when not to

• Use it for the quarterly competitive refreshdeep research across three to five competitors' features, pricing, positioning, and recent moves, done in an afternoon instead of a week.
• Use it before any strategy doc cites a competitorpb-21's red-team pass and your roadmap arguments are only as good as the competitive facts underneath them.
• Use it when entering a category you don't knowthe breadth-first sweep is where research agents genuinely outperform a human afternoon.
• Skip it for claims that will reach customers or legal contextsbattlecards asserting a competitor's weakness, public comparisons, anything in an RFP. Those need primary verification of every claim, not a top-ten sample.
• Skip the parts you can observe directlysign up for the competitor's trial and look. Ten minutes in their product outranks any research agent's summary of it.

The recipe

1. 1.

   Frame the questions, not the topic. "Research Competitor X" produces a book report. Write five to eight specific questions: pricing model and tiers, how their AI feature actually works, target segment shifts, recent launches and killed features, hiring signals. What decision will this research feed? Cut every question that doesn't serve it.

2. 2.

   Run the deep-research pass with table-only output. In ChatGPT deep research, Perplexity, or Claude with web search:

   Copy

   Research [COMPETITOR] to answer these questions: [QUESTIONS]
   
   Output ONLY a claims table, no narrative:
   CLAIM_ID | CLAIM (one specific, falsifiable sentence) | SOURCE URL
   | SOURCE TYPE (official docs / pricing page / press / third-party
   review / forum) | SOURCE DATE or "undated" | CONFIDENCE (high/med/low)
   
   Rules:
   - One claim per row; no compound claims.
   - Prefer official sources; mark third-party claims as such.
   - If sources conflict, output BOTH rows and flag the conflict.
   - If you cannot find evidence, write "NOT FOUND" — do not infer.
   - Never present a plan or announcement as a shipped capability.
   

   Run it once per competitor; merge the tables in a sheet.

3. 3.

   Rank claims by decision impact and pick the top ten. Not the ten most interesting — the ten that would change your roadmap, pricing, or positioning if wrong. Pricing claims and "they can't do X" claims almost always make the cut; "they were founded in 2019" never does.

4. 4.

   Manually verify the top ten and fill the ledger. For each: open the cited source and confirm it actually says what the claim says; check freshness against the live page; where stakes are high, verify in-product via a trial account. Log every result:

   Copy

   CLAIM_ID: C-07
   CLAIM: "Competitor X's Pro tier is $49/user/mo with SSO included"
   VERIFICATION: opened pricing page 2026-08-05
   RESULT: FAILED — Pro is now $59; SSO moved to Enterprise tier.
            Cited source was a cached page from 2026-01.
   ACTION: corrected in table; flagged all pricing rows for re-check
   

   Statuses: VERIFIED, FAILED, PARTIAL (true but materially incomplete), UNVERIFIABLE. Expect one to three of ten to come back not-clean; a ledger that's all VERIFIED usually means the checks were shallow.

5. 5.

   Write the brief from the table, with the ledger attached. Now — and only now — write the narrative: what it means for your positioning, where the openings are, what to watch. Every factual sentence cites a CLAIM_ID. Unverified claims appear only with an explicit "unverified" tag or not at all. The ledger travels with the brief so readers see the error rate instead of assuming zero.

Make it yours

• Cross-tool triangulation: run the same questions through two research tools and diff the claims tables — where they disagree, you've found either a moving target or a hallucination, and both are worth knowing before a stakeholder finds them.
• The standing watch: feed this quarter's verified table into pb-06's weekly briefing prompt as ground truth, so the weekly digest reports deltas against verified claims instead of re-deriving everything.
• Ledger analytics: after three runs, tally failures by source type and claim type. If pricing claims from third-party roundups fail 40% of the time, your prompt's source rules — and your verification priorities — just wrote themselves.

Quality check

• Every claim is falsifiable and singular"strong enterprise momentum" is not a claim; "signed 3 Fortune-500 logos in H1 per their press page" is.
• Freshness dates are realspot-check that SOURCE DATE reflects the page's actual date, not the retrieval date; agents routinely conflate the two.
• The top ten were chosen by decision impactand the choice is written down, so a reader can challenge the sample, not just the claims.
• Failed claims stayed visiblethe ledger records failures rather than silently fixing them; the error rate is the calibration data.
• Announced vs. shipped is distinguished everywherethe single most common competitive-research error, and the one that most reliably embarrasses a roadmap argument.