AI Writing & Creator Studio
How to write an email sequence from competitor research — a step-by-step guide for founders and solo operators who want to turn competitive intelligence
Most founders treat competitive research as a private asset — teardowns filed in Notion, review analysis buried in a spreadsheet, sharp observations about "what's wrong with this category" that surface only in an investor pitch or a sales doc. That's a real use of the work, and a narrow one — the same research that helps you win one deal can, restructured, build the audience that brings you deals you never had to chase.
An email sequence is the format that makes this restructuring possible. Unlike a white paper, which has to sound authoritative and neutral, a founder's email sequence built on competitor research can be personal and opinionated — your actual read on how the category evolved, sent in your own voice.
Done badly, this reads like a thinly-veiled feature comparison. Done well, it reads like a category thesis that happens to be argued by someone building the alternative. WebSnips' email sequence generator is built to help you make that turn deliberately: it takes the teardowns and review analysis you already have and helps shape them into a series that builds the argument before it ever mentions your product.
Most email sequences are built from research, reading, or expertise on a topic the audience is learning about. Competitor research flips this: you're not educating readers about a topic you know better than they do — you're sharing a perspective on the landscape they're already navigating.
This changes the email sequence's job. The reader isn't coming to learn from scratch. They're coming to understand why the category looks the way it does, what the existing solutions are actually getting right and wrong, and whether there's a better frame for thinking about the problem.
| Email sequence from... | Reader's starting state | The sequence's job |
|---|---|---|
| Saved research (805) | Knows little about the topic | Educate and convince |
| Meeting notes (807) | Knows you; wants your research | Share customer discovery findings |
| Collection of sources (808) | Non-specialist; needs translation | Translate academic findings |
| Competitor research (810) | Already evaluating options in category | Reframe the category; share analysis |
The competitor research email sequence is less about teaching and more about perspective-sharing and category positioning. It says: "Here's what I've observed about this space, here's what I think the conventional wisdom gets wrong, here's what a better approach looks like."
What it is: A systematic walk through the problems with how the current category of solutions approaches the core problem. One problem per email, building a cumulative case that the category is solving for the wrong thing.
When it works: When there's a genuinely wrong assumption baked into most category solutions — something that becomes obvious once you've done enough competitive research to see the pattern.
Structure:
EMAIL 1: The category's founding assumption and why it was reasonable
EMAIL 2: The first way that assumption breaks down in practice
EMAIL 3: The second failure mode — what the assumption makes companies optimize for
EMAIL 4: What customers actually complain about (customer review analysis)
EMAIL 5: What a different assumption would produce (implicit product position)
This format is powerful because it builds the category argument before it implies the product argument. The reader arrives at the conclusion themselves.
What it is: A personal, observation-driven series where you share what you've learned watching the category evolve — your competitive intelligence framed as informed observation rather than objective analysis.
When it works: When you have genuine longitudinal insight — you've been watching this space for years, and you've seen what changed and why.
Structure:
EMAIL 1: What this category looked like when I started watching it
EMAIL 2: The thing that changed — and what it revealed about the category
EMAIL 3: What the leading solutions are getting right (genuinely)
EMAIL 4: What the leading solutions are getting wrong (specifically)
EMAIL 5: Where I think this goes — and what that means for the reader
The founder's perspective format works because it requires the reader to take you seriously as an observer before it asks them to take you seriously as a builder.
What it is: Each email identifies one customer problem that the current category fails to solve, drawing on customer reviews, forum posts, and complaint patterns as the evidence.
When it works: When you have rich customer research data from competitor reviews — a collection of Trustpilot, G2, Capterra, Reddit, or support forum content that systematically surfaces what customers wish was different.
Structure:
EMAIL 1: The problem everyone knows about and nobody's solved
EMAIL 2: The problem that's hidden in the support tickets (the workaround signal)
EMAIL 3: The problem that's specific to [segment/use case your product targets]
EMAIL 4: The problem that competitor feature releases keep trying and failing to fix
EMAIL 5: What solving all four problems at once actually requires
Before choosing a format, take stock of what your competitor research actually contains:
COMPETITIVE RESEARCH ASSET AUDIT
Teardowns and analysis:
□ Product teardowns (screenshots, feature analysis, pricing research)
Sources: [List]
Date range: [When was this research done?]
□ Messaging and positioning analysis (competitor copy, value props, ads)
Sources: [List]
□ Customer review analysis (Trustpilot, G2, Capterra, Reddit, forums)
Sources: [Platform + date + how many reviews analyzed]
□ Founder/exec public statements (podcasts, interviews, blog posts)
Sources: [List]
□ Market research or category reports (third-party analysis)
Sources: [Reports, dates, authors]
□ Win/loss research (your own customer conversations comparing options)
Sources: [Internal — how many conversations?]
Format recommendation:
Strong on customer reviews → Customer Problem Series
Strong on product/messaging analysis → Category Audit Series
Strong on longitudinal observation → Founder's Perspective Series
The most common mistake in competitor research email sequences: jumping to "what our product does better" before establishing "what the category gets wrong." Readers who haven't bought the category argument will read the product argument as marketing.
The category argument must come first and be independently compelling. This means:
The problem is specific enough to be recognizable. "Enterprise PM tools are too complex" is vague. "Enterprise PM tools are built for project tracking, not project coordination — and those are two different things" is specific.
The evidence is real and cited. Customer reviews, specific competitor decisions, specific product limitations — not vague characterizations.
You acknowledge what competitors do well. A competitor analysis that only identifies weaknesses reads as a hit piece. Identifying genuine strengths — and then explaining why those strengths still don't solve the problem — is more credible and more intellectually honest.
The category argument implies the product argument without stating it. If your argument is that "most password managers optimize for security but sacrifice usability, and the data shows users turn off or bypass security features when they're too inconvenient" — you don't need to say "and that's why our product is more usable." The reader already arrives there.
Competitor research becomes outdated rapidly. A feature gap you identified 8 months ago may have been shipped. A pricing observation may no longer be accurate. A claim about a competitor's positioning may have changed after a rebrand.
Rules for date-sensitive claims in email sequences:
DATE-STAMP REQUIREMENTS
For any claim about a competitor's product, pricing, or positioning:
State when the research was conducted:
"As of [Month Year], [Competitor] priced [Product] at..."
"Based on [Competitor]'s [Date] pricing page..."
"At the time of this writing, [Competitor] does not offer..."
For customer review evidence:
State the date range and sample:
"Based on [N] reviews from [Platform] collected in [Month-Month Year]..."
For competitor strategy observations:
Acknowledge change possibility:
"Historically, [Competitor] has positioned around [X] — this may have evolved..."
For win/loss research:
State the period and sample:
"In [N] competitive conversations in [Year], [Competitor] came up in [N]% as..."
A well-dated email sequence actually gains credibility from the date-stamping: it signals that the author is rigorous about when the research was done, and readers know how to calibrate the information's current accuracy.
An email sequence built on competitor research faces a specific question that white papers and research reports don't: do you name competitors directly?
Three approaches:
Approach 1: Name them directly. Works best for: public information that's provably accurate; mature categories where the competitive landscape is widely known; when the critique is fair and the evidence is solid. Risk: Looks like a hit piece if the analysis isn't balanced; updates require email correction if competitor changes.
Approach 2: Use category descriptions. "The category of [type of tool] typically approaches this by..." — describes competitor behavior without naming specific products. Works best for: situations where multiple competitors exhibit the same pattern; when you want to critique the category, not a specific player.
Approach 3: Use comparative positioning without naming. "Many [type of tool] tools use [approach] — here's what that costs users..." — makes the point without naming. Works best for: early-stage founders who don't want to signal competitive threat to well-funded competitors.
The safest approach for most founders: name where the evidence is public and well-documented (pricing, features, public customer reviews); describe without naming where the evidence is from internal competitive conversations.
Competitive email sequences that don't cite evidence read as founder ego or sour grapes. Ones that do cite evidence read as informed analysis. The difference is whether each claim is anchored to something verifiable.
DRAFTING BRIEF FOR EMAIL [N]
Email theme: [The specific problem or observation this email addresses]
Sequence type: [Category Audit / Founder's Perspective / Customer Problem]
Evidence for this email:
Source 1: "[Specific quote, data point, or observation]"
Origin: [Customer review from G2, 2024 / Competitor pricing page, checked Month Year /
Product teardown notes, Date / Win/loss conversation, Month Year]
Will I name the source directly? [Yes / No — use category description]
Source 2: "[Evidence]"
Origin: [Attribution]
Will I name: [Yes / No]
Balancing claims:
What does this competitor or approach get RIGHT? [Brief acknowledgment]
What is the legitimate counterargument? [What a supporter of the current approach would say]
Category argument this email builds:
[The one thing a reader should understand about the category after reading this email]
Context: Founder of a developer documentation tool that generates API docs from code comments. She has done 6 months of competitive research: feature teardowns of 4 competitors (Readme.io, Stoplight, Swagger, Mintlify), analysis of 200 G2 reviews from competitor products, and 25 win/loss conversations with prospects who were also evaluating competitors.
Series format chosen: Customer Problem Series — she has strong customer review data from competitor G2 pages.
Top 4 problems from customer review analysis:
Problem 1 (20% of negative reviews across competitors): "Setup takes days, not hours." Documentation tools require extensive configuration before anything works — developers start, hit configuration walls, and abandon before seeing value.
Problem 2 (17% of reviews): "Looks great in a demo, broken after 6 months." Docs go out of sync with the API as code changes. No mechanism for detecting drift. Teams produce documentation that's accurate at launch and wrong 6 months later.
Problem 3 (14% of reviews): "Built for technical writers, not developers." Interface and workflow optimized for documentation professionals rather than the developers who maintain the code the docs describe.
Problem 4 (12% of reviews): "Great for REST APIs; we don't have a REST API." Products assume REST architecture; teams using GraphQL, gRPC, or WebSockets encounter significant gaps.
Before (competitor comparison email — what most founders write):
Subject: Why we built [Our Product] instead of using [Competitor A]
Hi,
Like many of you, we evaluated the major documentation tools when we started our company. We looked at [Competitor A], [Competitor B], and [Competitor C].
Each had strengths. But none solved our specific problem: documentation that stays accurate as the code changes.
[Our Product] is different. It generates docs from your code, so it's always in sync. Try it free at [link].
Generic, about the founder's experience, not the reader's problem, reads as a product pitch.
After (Email 1 of Customer Problem Series):
Subject: The 48-hour setup problem — why 60% of developer docs projects never ship
I've been analyzing G2 reviews for the four most commonly used developer documentation tools for the past few months. One pattern keeps appearing in the negative reviews, across all four products, regardless of their price point.
People try to set up documentation, hit a wall in the first 48 hours, and abandon the project. The documentation initiative then goes back to being "something we'll do later."
Here's what that looks like in practice (these are paraphrased from real reviews I collected in Q3 2024):
"Spent two days trying to get the basic configuration right before giving up."
"Beautiful product in the demo. Took a week to set up for our tech stack and I still can't get the authentication sidebar to display correctly."
"Evaluated this for 3 days, couldn't get it to pull from our repo structure. Support was helpful but it's just not set up for monorepos."
This isn't a criticism of any specific product — it's a category pattern. API documentation tools are generally built for the demo, not for the first 48 hours of real use. The demo shows clean, pre-configured documentation. The actual setup requires fitting your existing code structure into the tool's expected structure.
The cost of this isn't just churn. It's the documentation that never gets written at all. Every developer team that abandons a documentation tool in the first week either doesn't document at all or documents manually — which means the documentation immediately starts going out of sync.
Next week: the second pattern I keep seeing — what happens to the documentation that does get published, 6 months after launch.
— [Name]
Data source: Analysis of 200 G2 reviews for API documentation tools, Q3 2024.
Specific evidence, specific pattern, fair to the category, no premature product pitch, compelling tease.
I'm writing a [N]-email series using competitor research for [audience]
in the [category] space.
Series format: [Category Audit / Founder's Perspective / Customer Problem]
Series premise: [The category argument this series builds over 5 emails]
Email [N] — [Theme]:
Evidence:
Customer review analysis: "[Pattern quote or finding]" — [Platform, N reviews, Date]
Competitor product observation: "[Specific observation]" — [Source, Date]
Win/loss research: "[Finding]" — [N conversations, Date period]
Balancing claim: [What this competitor or approach does right]
What I won't name directly: [Describe category pattern vs. name specific competitor]
Draft:
Subject: [Category problem stated specifically — evidence hook, not product pitch]
Opening: [The pattern in evidence — "I've been analyzing..." not "We built [Product] because..."]
Evidence body: [Attributed, dated customer review patterns or observations]
Fair characterization: [What the current approach gets right]
Category argument: [The one thing to understand about why this pattern exists]
Tease: [Next problem email preview]
Evidence attribution: [Source + date for all claims]
Rules:
- Category argument before product argument — never name your product in emails 1-4
- Date-stamp all competitive claims
- Cite customer reviews as aggregated patterns, not anecdotal quotes
- Balance acknowledgment: something the category does right per email
An email sequence from competitor research converts your competitive intelligence into content that shapes category perception before it asks for anything. The format works because it's personal and serial — one observation at a time, over 5 emails, building a case through accumulated evidence. The discipline is in building the category argument first and letting readers arrive at the product implication themselves. Cite your evidence, date-stamp competitive claims, acknowledge what competitors do well, and save the product pitch for the end — or leave it out entirely and let the category argument do its work.
For more on this, see The Personal Knowledge Management Guide.
More WebSnips articles that pair well with this topic.
How to write an email sequence from a collection of sources — a step-by-step guide for academic researchers and PhD candidates who want to translate a
How to write an email sequence from your highlights — a step-by-step guide for students and lifelong learners who want to turn book or paper highlights
How to write an email sequence from your knowledge base — a step-by-step guide for remote team leads and ops people who want to turn institutional
How to write an email sequence from your meeting notes — a step-by-step guide for product managers and strategists who want to turn customer discovery
How to write an email sequence from your saved research — a step-by-step guide for writers and content creators who want to turn a research collection
How to write an email sequence from your web clippings — a step-by-step guide for knowledge workers and consultants who want to turn an accumulated set of