From Intelligence to Argument
Founders and solo operators who run regular competitive intelligence reviews often accumulate rich material: competitor pricing pages, G2 review patterns, product announcement timelines, positioning language, hiring signals. This material tells a story about the market — who's focused where, what customers want that they're not getting, where competitors have exposed weaknesses.
Most competitive intelligence stays in a Notion page or a spreadsheet. It gets referenced in strategy conversations. It's rarely the explicit foundation for a formal project proposal.
The gap between intelligence and proposal is largely an argument problem. The competitive data shows what's happening; the proposal argues what you should do about it and why. Building that argument rigorously — with the competitive data cited explicitly, the date-stamps intact, and the interpretation separated from the data — produces proposals that decision-makers can evaluate on their merits rather than on trust in the proposer's read of the market.
This guide covers three types of project proposals you can build from competitor research, and how to construct the argument for each.
Three Types of Competitor-Research-Based Proposals
Type 1: Whitespace Proposal
Your competitors are all competing in the same space, serving the same customers with similar approaches. The competitive research reveals what they're collectively NOT doing. The proposal argues for building in that whitespace.
Example: All major project management tools are optimizing for large teams (features, pricing, onboarding). A whitespace proposal argues for targeting solo founders, citing G2 complaints from small teams about unnecessary complexity, pricing tiers that don't fit single users, and the absence of solo-focused competitors in the space.
Type 2: Feature Gap Proposal
Customers of a competing product consistently complain about a specific missing feature or capability. The proposal argues for building that capability — either as a differentiator when they're evaluating you, or as a conversion path for their dissatisfied customers.
Example: 40% of G2 reviews for Competitor X cite "no bulk export" as a frustration. The feature gap proposal argues for building bulk export as a customer acquisition tool targeting Competitor X users who would switch for this capability.
Type 3: Segment Repositioning Proposal
A competitor is struggling in a specific customer segment — visible through their reviews, churn signals, or positioning language. The proposal argues for focusing resources on that segment rather than competing for the segments competitors are defending well.
Example: Competitor Y launched into enterprise in Q3 and their G2 reviews show significant enterprise customer dissatisfaction with their support and implementation. The segment proposal argues for staying focused on mid-market where Competitor Y was stronger before the enterprise pivot.
The Critical Discipline: Evidence vs. Inference
Competitive proposals have a fundamental attribution challenge that must be handled explicitly:
What the research shows: What you can see in competitor pricing pages, job postings, G2 reviews, or product announcements. These are facts (with date-stamps).
What you infer from the research: What you believe the research means — that a pricing change signals a strategic shift, that a hiring pattern signals a product direction, that a complaint pattern represents a conversion opportunity.
What you believe about the market: Your overall interpretation of what the research collectively suggests. This is your judgment, which is informed by the research but not determined by it.
In a competitor-research-based proposal, all three must be present — and clearly labeled:
EVIDENCE VS. INFERENCE DISTINCTION
Research fact: "Competitor X's G2 reviews (Q3 2024, 47 reviews) show 'poor onboarding' as
the top negative theme in 23 of 47 reviews." — Source: G2.com, as of [Date]
Our inference: "This suggests Competitor X's customer success team is stretched —
possibly a growth-without-scale issue where they're adding customers faster than
support capacity."
Our judgment: "We believe this represents a conversion opportunity: customers currently
in Competitor X's onboarding who hit friction are evaluable switches during months 1-3."
The proposal reader should always be able to identify which category each claim falls into.
Step 1: Organize Research by Proposal Type and Evidence Quality
Before writing, organize what your competitive research shows and at what confidence level:
COMPETITIVE PROPOSAL EVIDENCE MAP
Proposal type: [Whitespace / Feature Gap / Segment Repositioning]
Proposed project: [Brief description]
Evidence category: High confidence (directly observable)
1. [Competitive finding] — Source: [URL/source] — As of: [Date]
Type: [Pricing page / G2 reviews / Job posting / Product announcement / Messaging change]
Evidence category: Medium confidence (requires inference)
1. [What you observe] — Source: [...]
Inference: [What you believe this means]
Confidence basis: [Why this inference is reasonable]
Evidence category: Low confidence (speculative)
1. [What you believe without direct evidence]
How I'll present it: [As a working hypothesis / As an assumption to be tested, not a fact]
Counter-evidence (what might disprove the proposal's argument):
1. [Evidence that might suggest the opportunity isn't there]
Why I still believe the proposal is sound: [...]
Step 2: Build the Competitive Argument
The competitive proposal's core argument has three parts:
Part 1: What the competitive research shows (facts, cited and date-stamped)
"Competitors A, B, and C are positioned as [X]. Their pricing, feature sets, and messaging all converge around [Y]. Their customers' reviews show consistent complaints about [Z]."
Part 2: What this means for the opportunity (inference, labeled as such)
"In our read of this landscape, the gap is [specific gap]. Customers who want [capability] currently have no good option. The complaint patterns in Competitor X and Y's reviews confirm this demand is present."
Part 3: What we propose to do about it (proposal)
"We propose [specific project] to address [the gap]. This is differentiated from Competitor A because [specific way]; it addresses the complaint pattern from Competitor B's reviews because [how]."
The key: don't skip Part 1 to get to Part 3. Decision-makers can't evaluate the proposal if the evidence is implicit.
Before/After Worked Example
Context: Maya is a co-founder of a B2B SaaS tool for freelance writers and editorial assistants. She wants to propose a major new feature: a client brief management system — a structured way to intake, organize, and reference client briefs within the writing tool. She has competitive research suggesting that freelancers using current tools are managing client briefs manually (in email, in Google Docs, in separate note tools).
Competitive research gathered:
G2 reviews for 4 main competitors (Notion, Coda, Craft, Obsidian — all used by freelance writers for editorial workflow):
- Notion: 312 reviews; 18% cite "using external email/docs for client stuff alongside Notion" as a workflow friction
- Coda: 89 reviews; 12% mention keeping client briefs in separate tools
- Craft: 71 reviews; 7% cite difficulty separating "client work" from "personal notes"
- Obsidian: 143 reviews; 2% mention client workflow (Obsidian is primarily personal knowledge management)
Hiring: Notion's open roles include 2 enterprise-focused account management roles (no creative/freelancer roles). Craft's recent blog posts are about team collaboration, not individual creative work.
Messaging review: All four tools' main marketing is positioned toward "team" use or general productivity, not specifically editorial workflow for client-based freelancers.
Before (competitive research as assertion):
I've done a lot of research on the competition and there's clearly a gap in the market for client brief management in writing tools. None of the major tools do this well. Freelancers are managing their client stuff manually. We should build a client brief management feature.
No citations; "clearly a gap" is the proposer's assertion; no specific evidence; no distinction between data and inference.
After (evidence-grounded competitive proposal):
Feature Proposal: Client Brief Management
EXECUTIVE SUMMARY
We propose building a dedicated client brief management system into [Product] as the first tool in the market specifically designed for how client-based freelancers actually work: with client briefs that need to be organized, referenced during writing, and tracked across multiple projects simultaneously.
WHAT THE COMPETITIVE RESEARCH SHOWS
Current tools used by freelance writers and editorial assistants (Notion, Coda, Craft, Obsidian) share a pattern in their customer reviews: users manage client-related work with a separate layer of tooling alongside their primary note/writing tool.
- Notion G2 reviews (Q3 2024, 312 reviews): 18% of reviewers cite "using external email or Google Docs for client briefs alongside Notion" as a workflow friction — despite Notion's broad flexibility, freelancers appear not to be configuring it for client brief workflows.
- Coda G2 reviews (Q3 2024, 89 reviews): 12% of reviewers reference keeping client-facing work in separate tools from Coda.
- Craft G2 reviews (Q3 2024, 71 reviews): 7% cite difficulty separating client work from personal notes.
- Obsidian is primarily personal knowledge management; client workflow complaints are minimal (2%) because freelancer clients aren't Obsidian's intended use case.
(All review data from G2.com, accessed [Date])
OUR INFERENCE (labeled as inference, not research finding)
The consistent pattern across independent tools — users adding a separate layer for client-related work — suggests this isn't a Notion or Coda failure. It's a category gap: no existing writing/notes tool is designed around the client-brief intake and reference workflow that characterizes client-based freelance writing. The tools are built for personal productivity or team collaboration; client-based freelance work has a third-party structure (the client) that neither category serves well.
Supporting signal: Notion's recent hiring (2 enterprise account management roles, no freelance/creative focus) and Craft's recent blog content (team collaboration features) suggest these tools are orienting toward team and enterprise use, not freelance client workflows.
WHAT WE PROPOSE
A client brief management system purpose-built for our audience: structured brief intake (from email or pasted text), organized by client and project, referenced contextually while writing. This is differentiated because:
- Notion/Coda/Craft require freelancers to build their own client structure; we provide it out of the box
- We position around the specific workflow (client brief → writing → client delivery) rather than generic notes
COUNTER-EVIDENCE WE CONSIDERED
The low complaint rate in Obsidian (2%) might suggest the demand isn't large. Our read: Obsidian's audience is personal PKM users, not client-based freelancers — the sample is self-selected away from our audience. The 18% rate in Notion (a general-purpose tool used by freelancers) is more relevant.
SUCCESS METRICS
Primary: Feature adoption rate among existing users who identified as freelancers at signup
Secondary: Conversion rate improvement in demos where brief management is shown
SOURCES
- G2.com — Notion reviews (Q3 2024, 312 reviews)
- G2.com — Coda reviews (Q3 2024, 89 reviews)
- G2.com — Craft reviews (Q3 2024, 71 reviews)
- LinkedIn — Notion open roles (accessed [Date])
- Craft blog — Recent posts on team collaboration (accessed [Date])
Evidence-grounded; inference explicitly labeled; counter-evidence proactively addressed; all competitive claims date-stamped.
Prompts to Reuse
Project Proposal From Competitor Research
I'm writing a project proposal for [Project title and description].
Proposal type: [Whitespace / Feature Gap / Segment Repositioning]
Audience: [Decision-maker(s) — co-founder / investor / board / internal team]
Competitive research inventory:
High-confidence evidence (directly observable, date-stamped):
1. [Finding] — Source: [URL/type] — As of: [Date]
Medium-confidence evidence (requires inference):
1. [What observed] — Inference: [What I believe it means] — Confidence basis: [Why]
Counter-evidence (what might disprove the proposal):
1. [Counter] — Why I still think proposal is sound: [...]
The argument:
Part 1 — What the research shows (facts): [Summary of high-confidence evidence]
Part 2 — What this means (inference, labeled): [Our read of the competitive landscape]
Part 3 — What we propose (the project): [Specific proposal with differentiation rationale]
Draft a project proposal that:
1. Opens with executive summary (opportunity + proposed approach + differentiation)
2. Section "What the research shows": directly observable competitive evidence, cited, date-stamped
3. Section "Our inference" or "Our read": explicitly labeled as inference, reasoned from evidence
4. Section "What we propose": specific project with connection to competitive gap
5. Section "Counter-evidence we considered": proactive objection handling
6. Success metrics connected to the competitive opportunity (not generic)
7. Full citation list with dates
Attribution rules:
"[Competitor X]'s [source] (as of [Date]) shows..." = observable competitive fact
"In our read of this landscape..." = inference (labeled)
"We believe..." = judgment/hypothesis
Never: presenting competitive inference as competitive fact
Never: omitting date-stamps on competitive claims
Key Takeaways
- Three types of competitive proposals: whitespace (what competitors collectively don't do), feature gap (what their customers want that they don't provide), segment repositioning (where a competitor is underperforming) — identify which type fits your research.
- Explicitly separate evidence from inference: what the data shows vs. what you believe the data means — both belong in the proposal, clearly labeled.
- Date-stamp all competitive claims: competitive information decays; a pricing observation from last year may not be accurate today.
- Address counter-evidence proactively: the strongest objection to a competitive proposal is often a data point that could argue against it — address it before the decision-maker raises it.
- Don't propose copying — propose countering: a project proposal based on competitor research should argue for differentiation, not imitation; the evidence shows the gap, but the proposal argues for how you'll fill it differently.
Conclusion
A project proposal from competitor research converts your competitive intelligence from background knowledge into a persuasive argument that decision-makers can evaluate on its evidence. The key discipline is the explicit separation of what you observe (date-stamped competitive data), what you infer (your interpretation of what the data means), and what you propose (the specific project). That separation makes the proposal honest, and honesty in competitive proposals builds credibility — it shows you're arguing from evidence, not from wishful thinking about what the market wants.
Try WebSnips free — save competitor pricing pages, G2 reviews, product announcements, and job postings as organized text extracts tagged by competitor and proposal topic, so your next project proposal can pull the relevant competitive evidence directly into the argument rather than hunting for the data that supports the case.