How to Build a SaaS Competitive Analysis

“Do a competitive analysis” can mean two different jobs. One is the ongoing process of reading competitor changes and deciding what they mean. The other is a specific deliverable: a landscape map, a battlecard, a pricing comparison, or a win/loss summary.

Teams get stuck because they try to make one document do all four jobs. A sales battlecard needs different detail from a board-level market map. A pricing comparison needs different evidence from a product roadmap review. Pick the artifact first, then collect only what it needs.

If you are unsure, build the one-page landscape first. It forces you to name the market, the buyer, and the competitor set. The other artifacts can be derived from it later.

The template below fits on a single page if you keep each block to a few bullets. It is deliberately boring. The value is in the discipline of filling it with dated evidence and a clear implication.

1. Scope. What decision is this analysis supporting, and by when? Name the market, segment, and geography.
2. Competitor set. Three to seven companies, each with a one-line reason it is included. Note the source of the list.
3. Landscape. Place competitors on two axes that matter to buyers, such as price versus depth or self-serve versus sales-led. Label the axes and explain why you chose them.
4. Comparison. A short table of the dimensions that change deals: target buyer, entry price, packaging, core workflow, proof, and a clear strength or weakness.
5. Where we win and lose. Three bullets each, tied to evidence from deals, reviews, or product tests. Avoid generic claims.
6. Implications. What should change in pricing, messaging, product, or sales? If nothing should change, say so.
7. Actions and owners. One to three actions with an owner and a date. A document with no actions is a report, not an analysis.
8. Sources and review date. Link the pages you used, date the capture, and set the next review.

The first pass does not need to be perfect. It needs to be dated, sourced, and useful enough to discuss. A time-boxed sprint keeps the document from turning into a research project.

If you already have a weekly change report, the first 55 minutes are mostly assembling evidence you already have. That is the advantage of separating monitoring from analysis: the raw material is current before the document sprint starts.

Most competitive analyses do not fail because the research was wrong. They fail because nobody owns them. Six months later, a sales rep is quoting a price that changed in March and a feature that was discontinued in June.

• Name an owner. One person is responsible for the document, even if several people contribute.
• Date every claim. Put the capture date next to the price or feature. If a claim has no date, it is not ready to share.
• Link the source. A URL is faster to verify than a screenshot, and it lets the next reviewer refresh the evidence.
• Label confidence. Mark estimates as estimates. “Published price” and “inferred from a sales call” are different levels of evidence.
• Set a review date. Monthly for pricing and messaging, quarterly for the full landscape. Put it on the calendar.
• Archive old versions. Keep the previous version so you can explain why a recommendation changed.

The review cadence should match the market. A fast-moving category needs a monthly refresh; a stable enterprise category may only need a quarterly one. How often should you analyze your competitors? has a framework for choosing.

• The fifty-row feature grid. It takes hours to maintain and rarely explains a purchase. Compare the five features that change deals, not every checkbox.
• Unsourced claims. “Competitor X is enterprise-ready” is an opinion until you link the pricing page, docs, or customer story that supports it.
• A history of every change. The document is a snapshot, not a changelog. Keep the change history in your monitoring tool.
• Strategy-by-imitation. A competitor's move is evidence, not an instruction. Copying their pricing page without their cost structure or buyer is a fast way to damage your own model.
• A deck with no actions. If the last slide is “questions?”, the document is not finished.

A competitive analysis is only as good as the evidence behind it. The document can be a one-time sprint, but the inputs need a rhythm: pricing pages, homepage messaging, product pages, changelogs, and proof points.

Traced monitors those public pages every week and sends a report of what changed, with dated diffs and AI-written summaries. When it is time to refresh the one-pager, you are editing a current document instead of rebuilding it from memory.

For the interpretation step, how to analyze SaaS competitors has a six-step loop. For the most common failure modes, see common mistakes in competitor analysis.