Competitor Research Template: Choose Three Criteria Before Reading Reviews
Competitor research often goes wrong before the first review is opened: the comparison criteria are still undefined. Start with three columns—price, target audience, and limitations—then inspect the public pages of two competitors. Record only statements you can connect to a URL and confirmation date. If an AI assistant supplies a plausible detail that the page does not support, return that cell to blank.
Here is the three-line answer:
Choose the comparison criteria before collecting opinions.
Treat public product pages as evidence and reviews as later context.
Keep unsupported cells empty, even when a guess sounds reasonable.
This is a beginner field-test protocol, not a report claiming that two named products were tested. No verified competitor pages or product results were supplied for this episode. The useful deliverable is therefore the method and its required artifact: a dated source map.
Reviews answer a different question
Reviews are attractive because they appear to compress the work. Someone has already formed an opinion, found a complaint, or chosen a winner. That feels efficient.
But a review mixes several layers:
- What the product publicly promises
- What one customer expected
- What happened under that customer’s conditions
- The reviewer’s final judgment
Those layers can be useful later. They are a poor starting point for a basic comparison because they can set the criteria for you. Read several complaints about missing integrations, for example, and integrations may suddenly seem like the central buying criterion—even when your actual question is whether the product fits a specific audience at an acceptable price.
The first pass needs a narrower job: establish comparable facts.
A review is an interpretation; a source map is a record of what the page actually supports.
Price, target audience, and limitations work well as opening criteria because they force three different checks. Price asks what the buyer exchanges. Audience asks who the offer is designed for. Limitations ask where the offer stops.
They do not settle the buying decision. They create enough structure to investigate it without smuggling in a conclusion.
The test conditions are deliberately small
The protocol is dated 2026-09-04. Its conditions are simple:
- Compare two competitors.
- Use freely accessible public pages.
- Record only price, target audience, and limitations.
- Attach a direct URL and confirmation date to every supported entry.
- Leave unavailable or ambiguous information blank.
- Do not use reviews during the first pass.
This scope matters. “Research the market” is broad enough to invite wandering. “Fill six evidence-backed cells” is reviewable.
For continuity, imagine two fictional products serving operators who track promotions for a fictional convenience-store deals app. Competitor A presents a lightweight monitoring service. Competitor B presents a broader planning service. Those descriptions are placeholders, not evidence. They must not enter the completed comparison unless the corresponding public pages say so.
The same rule applies when an AI assistant proposes likely pricing tiers, likely customer types, or common restrictions. Plausibility does not upgrade a sentence into a fact.
Build the source map before writing conclusions
Create the source map first. The comparison table comes second.
| Source ID | Competitor | Page purpose | Direct URL | Confirmed on | Notes |
|---|---|---|---|---|---|
| S1 | Competitor A | Pricing | 2026-09-04 | ||
| S2 | Competitor A | Product or audience | 2026-09-04 | ||
| S3 | Competitor A | Limits, terms, or FAQ | 2026-09-04 | ||
| S4 | Competitor B | Pricing | 2026-09-04 | ||
| S5 | Competitor B | Product or audience | 2026-09-04 | ||
| S6 | Competitor B | Limits, terms, or FAQ | 2026-09-04 |
A row is not complete merely because it contains a homepage URL. Link to the page that supports the entry. If the pricing claim comes from a pricing page, use that page. If a limitation appears only in an FAQ, cite the FAQ separately.
Next, fill the comparison:
| Criterion | Competitor A | Source | Competitor B | Source |
|---|---|---|---|---|
| Price | ||||
| Target audience | ||||
| Limitations |
Each factual cell should point back to at least one source ID. A clean sentence without a source ID is unfinished research.
Use restrained wording. “The page names independent retailers” is an observation. “Best for small businesses” is a recommendation unless the page makes that exact positioning clear. “Probably lacks exports” is an inference. If exports are not addressed, the correct entry is blank or not stated on the reviewed page.
An empty cell is more useful than a polished assumption because it shows exactly what still needs verification.
Separate observation, inference, and recommendation
The easiest quality check is to label each note mentally—or visibly—as one of three types.
Observed evidence: The public page directly states the detail.
Inference: The detail appears likely based on wording, layout, or missing information, but the page does not confirm it.
Recommendation: A judgment about which competitor better fits the buyer’s situation.
Only observed evidence belongs in the first comparison table. Inferences can sit in a separate follow-up section. Recommendations wait until the evidence is sufficient for a decision.
Suppose a page displays a monthly amount but says nothing about taxes, contracts, or usage thresholds. Record the displayed amount and its visible billing basis. Do not infer the total cost. Put the unresolved elements in a question list.
Suppose the homepage shows a solo operator in its examples. That image alone does not prove the product targets solo operators. Look for explicit audience language in headings, product copy, documentation, or eligibility terms.
Suppose no limitation page is easy to find. Do not write “no limits.” Write not stated on the reviewed public pages and preserve the URLs you checked.
The first failure is usually premature completion
The most dangerous output is not an obvious error. It is a complete-looking table assembled from partial evidence.
Three common failure modes deserve a stop rule:
- The inferred audience: Broad marketing language is converted into a precise customer segment.
- The reconstructed price: A visible starting price is treated as the buyer’s final cost.
- The invented limitation: A familiar restriction from similar products is assigned to this competitor.
In each case, delete the unsupported detail. Do not soften it with “likely” inside the evidence table. Move it to an inference list or turn it into a research question.
This protocol also has limits. Public pages can be incomplete, outdated, region-dependent, or unclear. A page can describe availability without revealing practical suitability. The three criteria do not cover support quality, reliability, onboarding effort, privacy, or total operating cost. Reviews may help investigate those questions later, but they still need dates, conditions, and careful attribution.
No verified cost, user count, conversion rate, revenue, experiment duration, or completed competitor outcome is available for this episode. None should be inferred from the template.
The reusable competitor research checklist
Use this checklist before accepting the comparison:
- I selected exactly two competitors.
- I fixed the criteria before browsing: price, target audience, limitations.
- Every factual entry points to a direct public URL.
- Every source includes the date checked.
- I preserved the billing basis shown beside any price.
- I used explicit audience language rather than visual cues.
- I distinguished “not stated” from “not available.”
- I removed AI-supplied details that lacked page support.
- I kept inference outside the evidence table.
- I postponed reviews until after the factual pass.
- I listed unresolved questions instead of completing them by guesswork.
- I can trace every conclusion back to the source map.
The source map is the receipt: without the URL and date, the comparison is only a draft.
My final decision is to keep the first competitor pass intentionally narrow. Compare two options across three criteria, preserve the evidence trail, and accept blanks. Read reviews only after the source map reveals which questions remain unanswered.
Related build logs
- First Digital Product Pricing Strategy: Check Three Bottlenecks Before Cutting
- Competitor Research Template: A Beginner Five-Field Source Map
For first-pass competitor research, choose price, target audience, and limitations, cite every entry with a URL and date, and return unsupported guesses to blank.