How to Build a Competitor Feature Map with AI

AI can organize a competitor feature map, but it should not decide that a capability exists because a product sounds likely to have it. Build the map from dated primary sources, keep evidence beside every claim, and distinguish Confirmed, Unclear, and Not found in reviewed sources. “Not found” is not the same as “not supported.”

Define the decision before collecting features

Write down the comparison date, products, plan tiers, platforms, region, audience, and the decision the map should support. A feature on an enterprise plan should not be compared with a competitor’s free plan as though they were equivalent.

Use an evidence table, not a yes-or-no checklist

These rows are illustrative and do not claim facts about real products.

Use a source hierarchy

1. Official product documentation and admin guides
2. Official pricing and plan-comparison pages
3. Official release notes and availability announcements
4. Official support statements when published documentation conflicts

Marketing copy may confirm that a capability is promoted but may omit limits. Record both the URL and the date because product behavior and plan packaging change.

Capture the vendor’s wording before normalization

“Scheduled export,” “recurring export,” and “automated report delivery” may overlap without being identical. Preserve the vendor’s exact term and limitation in the evidence field, then add a separate normalized feature label for comparison.

Use AI for bounded extraction

Using only the sources I provide, create rows with:
- normalized feature label
- vendor wording
- product, plan, platform, and region
- Confirmed / Unclear / Not found in reviewed sources
- source URL and checked date
- exact limitation or prerequisite
Do not use prior product knowledge.
Do not convert “not found” into “not supported.”
Quote no more than the short phrase needed to identify the evidence.

Review every high-impact row against the original source. AI may join conditions from different plans, treat a beta as general availability, or overlook a footnote.

Separate evidence from scoring

Keep “better,” “worse,” and “winner” out of the evidence layer. Create a separate decision sheet with weights tied to your use case. A feature can be objectively available and still be irrelevant to a particular team.

Handle conflicting sources openly

If a pricing page says a feature is included but an older help page says otherwise, keep both links and mark the row Unclear. Compare update dates, rollout language, plan names, and platform scope. Do not silently choose the answer that makes the table cleaner.

Record plan, rollout, platform, and region

• Separate free, individual, business, education, and enterprise plans.
• Record web, desktop, mobile, API, and admin-console availability separately.
• Do not treat an announced feature as available to every account.
• Record add-ons, usage caps, administrator controls, and regional limits when material.

Avoid false “absence” claims

A missing search result may mean the documentation uses different wording, the feature is bundled into another capability, or the source is incomplete. Use Not found in reviewed sources until a primary source explicitly states that the feature is unavailable.

Review the rows that could change the decision

1. Sort by decision weight.
2. Reopen the strongest evidence for the highest-weight rows.
3. Confirm the plan, region, platform, and date.
4. Flag stale or ambiguous evidence.
5. Save a snapshot of the source list with the decision record.

For reusable extraction instructions, How to Write Reusable AI Instructions for Consistent Results explains how to keep stable rules separate from source data.

Completion checklist

• Every affirmative claim has a dated primary source.
• “Not found” is not presented as proof of absence.
• Plan and platform differences are visible.
• Conflicting sources remain visible.
• Scoring is separate from factual evidence.
• High-impact rows were manually rechecked.