# 6 competitor analysis frameworks, and when to use each
> Choose a competitor analysis framework for the decision: six SaaS examples show when to use a matrix, SWOT, buyer research, Five Forces or Wardley mapping.
You have a planning meeting on Friday and a request to “do a competitor analysis.” One person expects a feature table. Another wants to know whether the market is worth entering. A third wants a positioning slide. A feature table can help settle an integration requirement. It cannot tell you whether a market will support your business.
Choose the framework by the decision: jobs-to-be-done for the competitive set, a feature matrix for a specific purchase, SWOT for your response options, a perceptual map for buyer perceptions, Five Forces for industry economics and Wardley mapping for dependencies and build-or-buy choices. Use the smallest method that can answer the question with evidence you can actually obtain.
The examples below show how that choice works with Jira, Slack, Kertos, Comp AI, Notion and Amazon SES. They are teaching applications of public material, not claims that these companies used the frameworks themselves. Current documentation was checked on October 29, 2026; the two historical company records retain their September observation dates.
## Start with the decision and the missing evidence
Write a sentence before opening a template: “We need to decide whether to ___ for ___ before ___.” The first blank should contain a choice you can make, such as targeting an operations team, supporting a required integration or buying email delivery rather than building it. “Understand competitors” leaves the scope open forever.
For example, a hypothetical brief could read: **Decision:** choose a collaboration plan for a project team. **Buyer:** the person responsible for retrieving past project decisions. **Non-negotiable:** the required records must remain retrievable. **Public evidence:** plan documentation distinguishes access from deletion. **Missing test:** confirm that the actual records still exist and can be retrieved under the proposed plan. That brief calls for a feature matrix, not an industry-economics study.
Then name the person who can act and the evidence that would change their mind. A product manager deciding whether to support an integration needs the buyer’s workflow, required permissions and available alternatives. They do not need a full competitor funding history. A founder entering a new market needs distribution and switching-cost evidence that a feature checklist cannot provide.
| Decision | Start here | Evidence you need | Conclusion it cannot establish alone |
|---|---|---|---|
| Which alternatives solve the buyer’s problem? | Jobs-to-be-done | Buyer circumstances and actual workarounds | How common a need is across the market |
| Which option meets this purchase requirement? | Feature matrix | Plan-specific capability and a comparable test | Overall product quality |
| What should we do about a competitive development? | SWOT | Our capabilities plus external evidence | The probability of success |
| How do buyers perceive the choices? | Perceptual map | Consistent research with a defined buyer group | Perceptions inferred from vendor copy |
| Where does bargaining power sit? | Five Forces | Buyers, suppliers, substitutes, entry barriers and rivalry | A precise revenue forecast |
| What should we build, buy or stop maintaining? | Wardley mapping | User need, dependencies and component maturity | A guaranteed timetable for market change |
Public pages are useful for promises, packages and stated availability. They are weaker evidence for customer preference, implementation quality and commercial performance. Keep those distinctions visible in the finished analysis rather than hiding them in a footnote.
The broader [competitor analysis manual](/competitor-analysis/) covers discovery through action. Here the narrower job is choosing a method. You should leave with a research question you can complete, not six diagrams to maintain.
## 1. Jobs-to-be-done: choose the real competitive set
Use jobs-to-be-done when the rival list looks obvious but buyers keep choosing something outside it. Ask what progress the buyer needs to make in a specific circumstance, how they accomplish it now and what makes changing worth the trouble. The current workaround belongs in the analysis even when nobody sells it.
Start with the triggering event. “Manage projects” is broad. “Coordinate a cross-functional launch when engineering and marketing work in separate systems” gives you a situation, people and constraints. The useful comparison includes handoffs, decisions and consequences of delay. Let those observations inform the category labels.
### Jira: follow the work beyond the engineering label
Atlassian’s Jira page, checked October 29, names design, marketing, HR, operations and engineering as teams that can plan and track work together. It also describes assigning work to coding agents and providing context through MCP and a CLI. These are current vendor claims. They do not tell us which departments use those capabilities successfully.
For a SaaS team considering a launch-coordination product, that page is a reason to include Jira in discovery even if the original competitor list contained only marketing tools. The next question is whether a prospective buyer already coordinates the launch in Jira, stitches together several tools or relies on a person to chase updates.
An instructional job statement might be: “When several teams share a launch date, help me identify blocked handoffs early enough to change the plan.” Validate that wording with buyers rather than presenting it as a quote. Ask them to walk through their most recent launch, show where the handoff stalled and explain what they did next.
That evidence changes the competitive set. A shared spreadsheet, an internal coordinator or a decision to reduce launch scope might compete with the proposed software. None deserves exclusion because it lacks a pricing page. Conversely, a product with similar features may solve a different problem and deserve less attention.
**What to produce:** a short list of actual alternatives, each connected to a circumstance, desired outcome and switching obstacle. Preserve the buyer’s own terminology. If interviews reveal several different jobs, separate them before scoring vendors.
**Where it breaks:** a few conversations establish possible jobs, not population-wide demand. Recruiting only enthusiastic customers excludes people who never adopted the product. Use this method to discover and sharpen hypotheses; validate prevalence before making a large investment. Our [buyer interview guide](/blog/win-loss-buyer-interviews/) covers neutral questions and sampling limits when the decision involves a completed purchase.
## 2. Feature matrix: compare one buyer’s requirements
A feature matrix works when the buyer, use case and purchase constraints are already clear. Put requirements in rows and specific offers in columns. “Slack Free” is a usable column; “Slack” often hides the terms that decide the result.
Separate eligibility from preferences. A requirement needed for legal approval should not disappear inside an average score because another product has an attractive interface. Establish mandatory conditions first, then compare the remaining options on meaningful trade-offs.
Use explicit states: confirmed for this plan, restricted, planned, unavailable and unknown. A blank cell is ambiguous. A checkmark that combines a live capability with a future announcement is worse because it looks certain.
### Slack: searchable history and retained history are different rows
Slack’s free-version limitations, checked October 29, distinguish access to the most recent 90 days of message and file history from deletion of data more than one year old. The page says an upgrade reveals messages and files beyond the access limit. That must not become a promise to recover data already deleted.
For a buyer who needs to retrieve an old project decision, a row named “message history” conceals the important distinction. Split it into searchable history under the proposed plan, retention or deletion rules and the conditions for recovering inaccessible content. Keep the workspace and plan qualifications alongside the answer.
A filled instructional comparison entry would read: “Slack Free: latest 90 days accessible; data older than one year deleted under the documented policy. Whether the required project records remain available is unverified.”
| Requirement | Documented boundary | Decision consequence |
|---|---|---|
| Search older decisions | Free access limited to the latest 90 days | Test the intended plan against the actual record |
| Retain historical evidence | Workspace data older than one year deleted on Free | Check whether the record still exists |
| Recover inaccessible material | Upgrade reveals history beyond the access limit | Do not promise recovery of deleted data |
The purchase test is to locate the buyer’s required record in the relevant workspace, review applicable retention settings and confirm the intended plan’s terms. Avoid copying that entry into a competitor claim without a new check.
*Instructional illustration: inaccessible records and deleted records need separate answers. This is not a Slack screenshot.*
The matrix now points to a decision. If access to an older decision is mandatory and cannot be demonstrated, the option remains unresolved regardless of its score elsewhere. If the buyer needs only short-lived coordination, the same limitation may carry little weight.
**What to produce:** a requirement table with the offer, evidence, date, qualification and test result in each important row. A compact buyer-facing table can link to the detailed notes; it should not pretend those notes are unnecessary.
**Where it breaks:** feature counts reward products for capabilities the buyer never uses. Weighted scores are useful only when the weighting reflects the buyer’s priorities and uncertain cells stay uncertain. Re-run the ranking under a plausible different weighting. If the winner flips, present the trade-off instead of announcing a definitive winner.
## 3. SWOT: turn an external development into response options
SWOT separates strengths and weaknesses inside your business from opportunities and threats outside it. Use it when the question is what your team should do given its capabilities and a change in the market. The competitor’s launch is external; your ability to respond belongs on the internal side.
Give every item a consequence. “Strong engineering” is too vague to inform a decision. “We can support this buyer’s required identity provider within the existing architecture” can be checked. External opportunities also need a route to value: who might buy, what remains difficult and why your team can serve them.
### Kertos: a planned integration is a research question
Our published [Kertos company record](/companies/kertos/) reports a September 5, 2026 integration-section change involving new provider logos and “Coming soon” indicators. This is a historical public summary. It establishes what the record reports, not a fresh test of the integrations or a launch date for every logo.
For an adjacent vendor, the SWOT question could be whether a particular connector creates a defensible opportunity. A planned listing offers a reason to investigate demand and availability. It does not establish that Kertos cannot serve the buyer through another route.
The internal half requires your own evidence. Can your connector perform the required operation? Does it support the right permissions? Can you maintain it when the upstream API changes? A roadmap item in your own backlog is also planned, and deserves the same restraint as a rival’s.
The resulting response might be a customer-discovery task rather than a build commitment. Identify buyers who need that exact connection, test their current workaround and estimate support effort. If buyers do not need the named operation, do not build it merely because a rival displays the logo. If demand is rare or the workaround adequate, a new connector may be the wrong use of engineering time. If repeated demand and implementation capacity are both established, it becomes a stronger candidate.
*Instructional illustration: available, planned and unknown are different states. The symbols are examples, not vendor ratings.*
**What to produce:** a small number of paired arguments: external development, relevant internal capability, possible response and evidence needed before committing. That is more useful than filling every quadrant with an equal number of bullets.
**Where it breaks:** the labels invite wishful thinking. An opportunity needs demand; a strength needs proof. Ask someone outside the proposal to challenge the strongest item. If it survives only because the team likes it, leave it out of the decision. The [integration-page guide](/blog/competitor-integration-pages/) helps identify follow-up sources without treating a listing as a completed implementation.
## 4. Perceptual mapping: distinguish buyer beliefs from vendor claims
Use a perceptual map to understand how a defined group of buyers sees the alternatives. Choose dimensions that matter to those buyers and collect comparable judgments. Two convenient axes chosen by your own team can produce an attractive picture with little connection to purchase behavior.
A map of vendor messaging is a different artifact. It can show what companies emphasize on their public pages. It cannot establish what buyers believe, how well a product performs or whether an empty-looking position represents demand.
### Comp AI: a changed promise does not move the buyer dot
The published [Comp AI record](/companies/comp-ai/) reports an August 29, 2026 shift toward speed and deal velocity, followed by a September 5 manifesto emphasizing security, open-source verification and continuous evidence collection. Those are dated summaries of public messaging. They do not measure customer perception or prove the earlier emphasis disappeared from the product.
For a marketer studying compliance software, these records suggest candidate research dimensions: speed of becoming ready for an audit, confidence in ongoing security evidence or help removing procurement friction. They are questions to test, not positions to assign by intuition.
Ask a defined buyer group which differences matter, then ask them to evaluate products they know using the same wording. Record unfamiliarity instead of forcing a rating. A buyer who has never used or considered Comp AI cannot provide the same kind of judgment as an experienced customer. Keep sample composition visible when interpreting the map.
If you only have public pages, label the output “stated positioning.” Quote the exact relevant language and its date. Place uncertain observations in notes rather than fabricating coordinates. If later buyer research disagrees with the messaging map, investigate the mismatch. Before repositioning, test whether better proof or a clearer explanation resolves it.
**What to produce:** either a buyer-perception map with sample and question wording, or a messaging comparison with sources. Keep the two separate. An empty quadrant is a hypothesis about a possible position; follow it with demand and feasibility research.
**Where it breaks:** arbitrary scales create false precision. One-to-five scores from a workshop can be useful discussion prompts if labeled as team judgments. They become misleading when presented as market research. Our [homepage-rewrite guide](/blog/competitor-homepage-rewrite/) helps inspect public promises; it cannot supply missing buyer beliefs.
## 5. Five Forces: examine the economics around the product
Use Five Forces when the decision concerns entering, expanding or remaining in a market. The Harvard Business School explanation covers rivalry, new entrants, substitutes, supplier power and buyer power. These forces concern how value is divided, beyond a list of direct rivals.
Define the market narrowly enough to examine. “AI software” hides very different users, distribution channels and switching costs. A writing tool for a small editorial team and a regulated document-review product may share model providers while facing different buyers and approval barriers.
### Notion: bundled access changes the substitute question
Notion’s AI FAQ, checked October 29, says Notion AI is available on Business and Enterprise plans, while Free and Plus users receive limited complimentary responses. It also qualifies higher-credit-consumption models and administrative access. A feature’s presence in the product does not establish identical access for every buyer.
For a standalone writing or workplace-search vendor, this is useful substitute evidence. Some prospective customers may already have relevant functionality inside an existing subscription. That creates a question about the incremental cost and effort of buying another product. It does not prove that the bundled feature meets their requirements or that they will stop paying for specialist software.
Work through the other forces separately. Buyer power depends on available alternatives and switching costs. Supplier power depends on essential inputs, contractual terms and the ability to replace them. Assess entry barriers through distribution, trust, access to useful data and the work required beyond a demo. Rivalry includes how incumbents respond to the same customer need.
The practical next step is to test the proposed specialist advantage with buyers who already use the relevant bundle. Which task remains incomplete? What additional approval or workflow would your product require? What can they demonstrate rather than merely prefer? This separates a viable niche from a feature that looks different only in a screenshot.
**What to produce:** a market-boundary statement, evidence under each force and a few investment conditions. For example, proceeding might depend on finding a segment with a repeated unmet task and an affordable route to reach it. Label that as your decision rule, not a universal threshold.
**Where it breaks:** assigning each force “high” or “low” without explaining the mechanism is decoration. Public packaging cannot reveal negotiated discounts, actual switching behavior or vendor margins. Request the missing evidence or express a range; do not turn a framework into a revenue forecast.
## 6. Wardley mapping: connect user needs to build-or-buy choices
Use Wardley mapping when a product decision depends on the components underneath it. Begin with the user’s need, connect the capabilities required to meet it and consider how established or standardized each component is. Simon Wardley’s book is available through Learn Wardley Mapping.
The map combines a dependency view with an evolution axis running from genesis through custom-built and product to commodity or utility. Placement is an argument to investigate. A familiar API does not make an entire business commodity, and a map does not provide a guaranteed schedule for future change.
### Amazon SES: renting delivery leaves product work to do
The Amazon SES documentation, checked October 29, describes sending email through SDKs, SMTP or the API, along with related services for notifications, access control and storage. That is evidence that a team can buy email-sending infrastructure rather than implement every delivery component itself.
Suppose your product must send customers an understandable account-activity digest. An instructional dependency sketch starts with the customer’s need to notice relevant activity. Below it sit event collection, relevance rules, message composition, delivery and failure handling. SES addresses part of that chain. It does not decide which events matter to your customer or whether the finished digest is useful.
That distinction creates a concrete build-or-buy discussion. Compare the cost of maintaining delivery infrastructure with a managed service, while retaining responsibility for permissions, recipient preferences, error handling and the customer-facing experience. Check service limits and operational requirements in the relevant documentation before committing. Availability of a managed component is a starting point, not a complete architecture review.
The competitive question then becomes where your team can create a meaningful difference. If multiple rivals rent similar delivery infrastructure, your advantage may depend on relevance, workflow fit or reliable execution. That remains a hypothesis to test with users and operational evidence. The map helps expose it; it cannot award the advantage on your behalf.
**What to produce:** a dependency map with uncertain placements, build-or-buy options and the tests that would change them. Get engineering and product to challenge different parts. Product checks the user need; engineering checks the actual dependencies and replacement cost.
**Where it breaks:** declaring that every component inevitably moves at the same pace erases constraints. Regulation, reliability, switching cost and specialized requirements matter. Revisit the map when those assumptions change. Other frameworks can also be updated; Wardley mapping’s distinctive contribution is the explicit dependency-and-evolution view.
## Combine methods only when the second changes the decision
A useful sequence might begin with jobs-to-be-done to identify alternatives, use a feature matrix for a defined buyer and finish with SWOT to choose a response. Another project might start with Five Forces and need no feature table at all. Avoid making every research request complete the same six-part obstacle course.
BCG’s growth-share matrix is a separate portfolio tool. Its definition relies on market growth and relative market share. Website traffic, funding totals and the number of customer logos are not interchangeable substitutes. If you lack credible market boundaries and share data, explain the gap rather than labeling a SaaS product a star or cash cow.
For a small team, agree a research budget before gathering material. Separate the time required to obtain evidence from the time spent discussing it. A short workshop can organize existing knowledge; it cannot create buyer research or validate an integration. Stop when the remaining uncertainty no longer changes the decision, or when the decision should wait for a specific test. Mandatory requirements stay unresolved until demonstrated; reaching the research budget cannot turn missing proof into a pass.
A completed analysis should state the choice, the evidence that supports it, the important uncertainty and what would cause reconsideration. Keep the source notes, but let the reader reach the decision without reading your entire research archive. An honest “we cannot distinguish these options yet” is a useful result when it names the missing test.
## When Competitor Tracker & Co. fits
Competitor Tracker & Co. fits when your analysis depends on public competitor promises that keep changing between planning discussions.
- “I need to know whether a rival changed the offer our analysis uses.”
- “I want product and marketing to work from the same dated public evidence.”
- “I need a short explanation of the movement before deciding whether to reopen the analysis.”
- “I want my own AI agent to retrieve the same competitor records.”
We are the wrong fit if you need us to conduct buyer interviews, estimate private market shares or certify a rival’s implementation. Those jobs require other evidence and people responsible for the judgment.
Our [weekly competitor tracking](/) uses AI agents to watch public pricing, product, integration and messaging pages, ignore routine noise and send a Monday dossier of relevant changes. You can read In Person or By Wire; the [agent example](/demo/agent/) and shared [MCP documentation](/docs/mcp/) show the machine-readable path. Your team decides whether a change affects the framework, the evidence inside it or neither.
Choose the framework for the decision, then keep its important assumptions close enough to check.
If your next planning decision depends on current competitor evidence, [see a sample dossier](/demo/) or [start a case](/#engage) with Competitor Tracker & Co.
— C. T. Lucky
---
Source: https://competitortracker.io/blog/competitor-analysis-frameworks/
Updated: 2026-10-29