SaaS Competitor Analysis With AI: 4 Copy-Paste Prompts | Tomako
Blog content updates automatically
How to Analyze SaaS Competitors with AI: 4 Copy-Paste Prompts
Competitor analysis does not need to start with an expensive platform. Public reviews, pricing pages, release notes, and community discussions can reveal useful questions. These four prompts help you separate repeated signals from one-off complaints, check claims across sources, and turn findings into ideas worth testing.
Use reviews and forum posts to find questions, not to measure the whole market. Keep repeated signals separate from one-off complaints. Check an important finding in another source before you use it in public copy.
One more rule matters: a user's complaint can support a pain point, but it cannot prove that your product solves it.
The four analysis lenses
Lens
Input
What it can help you learn
Review mining
Public customer reviews
Repeated workflow problems and isolated complaints
Pricing analysis
Current pricing pages and plan limits
READY WHEN YOU ARE
YOUR PRODUCT.
READY TO MOVE.
Bring your product context into Tomako, then turn a guide, an idea, or a decision into work you can continue.
Documented gates, usage limits, and comparable price changes
Changelog analysis
Dated release notes and current product claims
What the company chose to announce during the sampled period
Community language
Public questions and problem discussions
How users describe a problem in their own words
These lenses produce signals, not verdicts. Combine them and check where they agree.
1. Find friction in customer reviews
Two-star and three-star reviews can contain useful details from people who have tried the product. They are still a biased discovery sample. They cannot tell you how common a problem is across the full customer base.
Use only material you are allowed to process. Remove names and personal information. Keep the source URL for your own checks, and review the platform's current terms before copying text into an AI tool.
Prompt 1: Review evidence extractor
Markdown
You are analyzing customer reviews for an independent software builder.
Analyze only the text provided below. Do not use outside knowledge about the company or product.
Competitor: [COMPETITOR NAME]
Reviews:
"""
[PASTE 15-25 CONCISE REVIEW EXCERPTS HERE AFTER REMOVING PERSONAL IDENTIFIERS. PASTE REVIEW TEXT, NOT FULL PAGE HTML.]
"""
Rules:
1. Treat an issue as "recurring" only when at least two independent reviews mention the same underlying problem.
2. Label an issue mentioned by only one review as an "isolated signal."
3. Call something a "trigger for seeking an alternative" only when the reviewer explicitly says they looked for, switched to, or considered another product. Otherwise label it "friction only."
4. Attach an exact supporting quote and a review count to every finding.
5. Do not infer user intent, market size, or product impact from missing information.
6. If a section has no supported finding, write "Insufficient evidence in provided text."
Return:
### Recurring friction
For each recurring issue, provide:
- A plain-language description
- Number of independent reviews that mention it
- One or two exact supporting quotes
- The workflow or user context, if stated
### Isolated signals
List useful complaints that appear only once. Do not present them as trends.
### Explicit switching triggers
List only cases in which the reviewer explicitly mentions seeking or choosing an alternative.
### Tasks that feel harder than expected
Identify workflows that reviewers describe as confusing, slow, fragile, or unnecessarily multi-step.
### Evidence limits
State what this sample cannot establish.
Keep the quotes in your research notes. If you use customer language in public copy, paraphrase it unless you have the context and permission needed to reproduce the original wording.
2. Examine pricing without inventing a bargain
Pricing pages can reveal documented restrictions, but they are easy to compare badly. Monthly and annual prices may differ. One plan may charge per seat while another charges by usage. Region and taxes may also change the total.
Record the page date, currency, billing period, unit, and plan limits before asking the model to compare anything.
Prompt 2: Pricing and packaging analyzer
Markdown
You are analyzing the public pricing and packaging of [COMPETITOR NAME].
Use only the information below. Do not assume that an unlisted feature is included or excluded.
Pricing captured on: [DATE]
Currency and region: [CURRENCY / REGION]
Billing basis: [MONTHLY, ANNUAL, PER SEAT, USAGE-BASED, OR OTHER]
Pricing data:
"""
[PASTE THE RELEVANT PRICING TABLE, PLAN LIMITS, AND OVERAGE RULES. DO NOT PASTE FULL PAGE HTML.]
"""
Rules:
1. Compare prices only when the billing periods and units are compatible.
2. When possible, show both the absolute price change and percentage change between comparable plans.
3. Separate flat fees, per-seat charges, usage charges, and overage fees.
4. If a feature or limit is not stated, label it "Unclear from provided pricing data."
5. Do not describe a restriction as unfair, arbitrary, or unsuitable without supporting user evidence.
6. If the data does not support a requested comparison, write "Insufficient comparable data."
Return:
### Documented feature gates
List features that are explicitly restricted to higher plans.
### Comparable price changes
For each valid comparison, show:
- Plans compared
- Billing unit
- Absolute price change
- Percentage change, if calculable
- Additional documented capacity or features
### Possible mismatches to investigate
Identify cases, if any, where access to a functional feature also requires buying team or governance features. Mark each item as a hypothesis until customer evidence confirms it creates a problem.
### Entry-plan limits
Create a table containing only documented limits of the lowest paid plan. Use as many rows as the evidence supports. Do not fill missing rows.
### Evidence limits
State what cannot be concluded from this pricing page alone.
The output may reveal a segment worth investigating. It does not prove that the segment will buy a separate product.
3. Read changelogs as announcements, not resource reports
A public changelog shows what a company chose to announce. It is not a complete record of engineering work, maintenance, or internal priorities.
You can still compare recent announcements with the product's current promises. Keep the conclusion narrow and record the period you sampled.
Prompt 3: Changelog and claims comparison
Markdown
You are comparing the public product claims and release notes of [COMPETITOR NAME].
Analyze only the supplied text. The changelog is a selective public record, not a complete account of engineering work.
Current product claims:
"""
[PASTE 2-4 CURRENT HOMEPAGE OR PRODUCT-PAGE CLAIMS, INCLUDING FEATURE PROMISES OR POSITIONING STATEMENTS]
"""
Changelog sample:
"""
[PASTE DATED CHANGELOG ENTRIES. PASTE THE ENTRY TEXT, NOT FULL PAGE HTML.]
"""
Rules:
1. State the earliest and latest dates covered by the sample.
2. Describe only what was announced during that period.
3. A missing update does not prove that a feature is neglected, unmaintained, or abandoned. Use "Not documented in this sample."
4. Assign each update one primary category and, only when useful, one secondary category.
5. Do not infer team size, engineering effort, roadmap priority, or customer adoption.
6. If the text cannot support a comparison, write "Insufficient evidence in provided text."
Return:
### Sample coverage
Report the number of entries and date range reviewed.
### Announced areas of work
Group the entries by product area or user workflow and count the announcements in this sample.
### Type of update
Classify each entry under one primary category:
- Reliability or bug fix
- Workflow improvement
- Administration or governance
- Integration
- New user-facing capability
### Comparison with current product claims
For each supplied claim, state whether related work is:
- Documented in this sample
- Not documented in this sample
- Too ambiguous to classify
### Evidence limits
Explain what the public changelog cannot establish.
Use the result to form a question, such as whether a workflow remains painful after recent updates. Do not turn it into a claim that the competitor has stopped investing in a feature.
4. Turn community language into positioning hypotheses
Community discussions show how people describe a problem before they encounter your marketing. They are useful for vocabulary and context. Complaint threads alone cannot prove demand or product performance.
Prompt 4: Evidence-bound positioning ideas
Markdown
You are helping an independent software builder turn community research into positioning hypotheses.
Use only the supplied comments. Do not use outside knowledge about the competitor, category, or the builder's product.
Community comments:
"""
[PASTE 5-10 CONCISE PUBLIC COMMENTS OR QUESTIONS AFTER REMOVING PERSONAL IDENTIFIERS. DO NOT PASTE FULL PAGE HTML.]
"""
Optional product evidence:
"""
[PASTE TEST RESULTS, DEMO OBSERVATIONS, OR VERIFIED PRODUCT CAPABILITIES. LEAVE BLANK IF NONE.]
"""
Rules:
1. Separate statements about the user's problem from statements about the builder's product.
2. A comment can support a pain point. It cannot prove that the builder's product solves that pain.
3. Label any unsupported outcome or comparison "Hypothesis to validate."
4. Preserve the user's technical vocabulary, but do not copy distinctive phrases into public copy without permission or adequate context.
5. Return fewer ideas when the comments support fewer ideas.
6. If there is no supported finding, write "Insufficient evidence in provided text."
Return:
### Supported problem statements
List up to three problems supported by the comments. Attach a quote and identify the relevant user or workflow context when stated.
### Candidate headlines
Draft up to three plain-language headlines. For each headline, label it:
- Evidence-bound, if both the pain and promised product result are supported
- Hypothesis to validate, if the product result has not been demonstrated
### Comparison hypotheses
Create a table with these columns:
- User task
- Observed friction
- Possible simpler approach
- Evidence status
### Questions to validate next
List the smallest unanswered questions that would prevent the builder from making a confident public claim.
A short worked example
The following comments are fictional. They show how the method should behave. They are not statements from users of a real product.
text
Review A: "The CSV export times out on our larger workspace."
Review B: "We have to split a full export into batches or it fails."
Review C: "We moved to the higher plan for API access, not for the extra seats."
Review D: "The setup flow took several screens before the first sync."
A careful analysis would produce this result:
Finding
Status
Evidence
What you may say
Large exports may fail or require batching
Recurring signal
Reviews A and B
Two reviews in this sample describe export problems on larger datasets
API access may be bundled with unwanted capacity
Isolated signal
Review C
One reviewer reports upgrading for API access rather than seats
Setup may take too many steps
Isolated signal
Review D
One reviewer describes a long setup flow
The sample supports investigating export reliability. It does not support saying, "Most customers are leaving because exports are broken." It also does not prove that a simpler competitor would win those customers.
Next, look for the same export problem in another source. Speak with affected users. Then test whether your own product handles the relevant dataset reliably. Only after those checks should the finding become a product promise.
Move from signals to an honest position
The four prompts create a research snapshot. Use this sequence to turn it into action:
text
Collect public source material
|
v
Extract source-backed signals
|
v
Separate recurring and isolated findings
|
v
Check promising findings in another source type
|
v
Validate with users or product evidence
|
v
Write a narrow positioning claim
|
v
Help in relevant community discussions
Choose one workflow
Do not build a roadmap from every complaint in the sample. Pick one job that matters to the user you want to serve.
Check the signal elsewhere
Look for the same problem in at least one different source type. A review pattern that also appears in community questions, documentation, or support material deserves closer attention. Agreement across sources makes a hypothesis stronger, but it still does not measure the whole market.
Validate the problem and the solution separately
Ask affected users how often the problem occurs, what they do instead, and what it costs them. Then test whether your product delivers the result you want to promise. Pain evidence and solution evidence are different.
Write the narrowest honest claim
Avoid "better than [competitor]" unless you have a fair, current comparison. Describe the task, the supported result, and the user context instead.
Contribute before you promote
When you join a discussion, answer the question or share a useful workaround first. Mention your product only when it directly helps and the community permits it.
Once the process works, fit it into a small schedule instead of letting research interrupt product development. The 30-minute daily marketing routine offers one way to build that habit.
Where Tomako fits
Manual analysis is useful while you are learning which signals matter. The harder part is keeping the context and turning selected signals into growth work your team can review.
Tomako is the proactive AI CMO for software companies. It turns product context and selected market signals into growth work your team can review, ship, and learn from.
Tomako can help organize selected signals into reviewable opportunities and prepare drafts or follow-up tasks. Your team keeps control of strategy, brand decisions, and important external actions.
Use the prompts in this guide to test the method manually. When the work becomes repetitive, explore Tomako to see how it supports research and preparation.
Final checklist
Before you publish a competitor-based claim, confirm that:
Every finding points back to source text.
Recurring and isolated signals are clearly separated.
The sample size and date range are recorded.
A second source type supports the important hypothesis.
User pain is not presented as proof of your product's performance.
Pricing comparisons use compatible billing units.
Missing changelog entries are not treated as proof of abandonment.
Public copy says no more than the evidence supports.
Competitor analysis should reduce uncertainty. If the evidence is thin, the right output is a better question, not a stronger claim.
Eren is the founder of Tomako, focused on the decisions that shape SaaS and AI products—from defining a problem and building the product to refining the user experience. As a product manager, product designer, and developer, he looks at products through the combined lens of user needs, positioning, interaction design, and implementation. His writing covers product insight, validation, onboarding, positioning, and how to turn complex ideas into useful product experiences.
Eren
