AI Writing & Creator Studio
How to write a project proposal from competitor research — a step-by-step guide for founders and solo operators who want to convert their competitive
What actually happens to the competitor pricing pages, G2 review patterns, product timelines, and hiring signals a founder has been tracking for two years? Usually: they sit in a Notion page or a spreadsheet, get mentioned in a strategy conversation once a quarter, and never become the explicit foundation for anything formal. That's despite the material telling a genuinely useful story about the market — who's focused where, what customers keep asking for that nobody's building, where competitors have exposed real weaknesses.
The reason it stalls there isn't lack of material — it's an argument problem. The competitive data shows what's happening; a proposal has to argue what you should do about it and why, and that's a different kind of writing. Built rigorously, with the data cited explicitly, dates intact, and interpretation kept separate from evidence, that argument produces a proposal decision-makers can evaluate on its merits rather than on how much they trust 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.
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.
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.
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: [...]
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.
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):
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.
(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:
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
Evidence-grounded; inference explicitly labeled; counter-evidence proactively addressed; all competitive claims date-stamped.
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
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.
For more on this, see Building a Personal Knowledge Base.
More WebSnips articles that pair well with this topic.
How to write a project proposal from a collection of sources — a step-by-step guide for academic researchers and PhD candidates who need to write a
How to write a project proposal from your bookmarks — a step-by-step guide for knowledge workers and consultants who want to convert years of accumulated
How to write a project proposal from your clipped articles — a step-by-step guide for marketers and growth practitioners who want to convert their swipe
How to write a project proposal from your highlights — a step-by-step guide for students and lifelong learners who want to build an evidence-backed
How to write a project proposal from your reading notes — a step-by-step guide for students and lifelong learners who want to turn course reading notes
How to write a product description from a collection of sources — a step-by-step guide for academic researchers and PhD candidates who need to translate