Product strategy · 13 min read · Updated 1 Aug 2026
Feature Gap Analysis Template (Free Competitive Feature Gap Framework)
A blank feature gap analysis you can fill in today, plus the guidance for what belongs in each field. It exists to decide which gaps to close and which to accept on purpose, because a team that builds every gap a competitor opens has handed them the roadmap.
Copy pastes straight into Google Sheets or Excel with the columns intact. Downloads are free with a work email.
The feature gap analysis template
This is exactly what you get when you copy or download. Blank fields are yours to fill in; each table ships with one example row to show the pattern, which you delete.
Analysis scope
Fill this in first. A feature gap analysis with no named decision becomes a list of everything you do not have, which is infinite.
- Product and segmentThe specific product and buyer segment being compared
- Competitors comparedTwo to four named products you actually lose deals to
- Decision this informsThe roadmap or positioning choice this is meant to unblock
- Where the gaps came fromLost deals, support tickets, sales requests or a feature grid
- OwnerOne named person, not a team
- Date completed and next reviewWhen it was verified, and when it gets refreshed
1. The gaps
First row is an example, delete it. Only capabilities a buyer has actually asked about. For an exhaustive feature-by-feature grid, use the free interactive comparison matrix linked below and bring the differences here.
| Capability, in the buyer's words | What we have today | What the strongest competitor has | Gap or advantage | Evidence (link + date) |
|---|---|---|---|---|
| Example"Can we build our own reports?" | Fixed report set plus CSV export | Drag-and-drop report builder | Gap | Their docs, 12 Mar |
2. Deal impact
First row is an example, delete it. A gap nobody lost a deal over is not a gap, it is a difference. This section is what separates the two.
| Gap | Deals it appeared in | Deals it decided | Segment affected | Evidence |
|---|---|---|---|---|
| ExampleReport builder | 11 of 17 mid-market | 6 lost | Mid-market, ops-led evaluations | Q1 win/loss report |
3. Severity against buyer priority
First row is an example, delete it. Blocker and preference are different problems. Most gaps teams panic about are preferences with a workaround nobody told sales about.
| Gap | How the buyer ranks it | Blocker or preference | Workaround we have today | Severity |
|---|---|---|---|---|
| ExampleReport builder | Top three requirement for ops buyers | Blocker when ops runs the evaluation | Scheduled CSV export into their BI tool | High |
4. Why the gap exists
First row is an example, delete it. The most skipped section, and the one that prevents rebuilding something you deliberately chose not to build two years ago.
| Gap | Why we do not have it | Was it a deliberate choice | Rough effort to close | Confidence in that estimate |
|---|---|---|---|---|
| ExampleReport builder | Chose fixed reports to keep setup fast | Yes, in 2024 | One quarter, two engineers | Low, not scoped properly |
5. Response: build, partner, counter or accept
First row is an example, delete it. Building is one of five options and rarely the best one. Every gap gets an explicit decision, including the ones you choose to live with.
| Gap | Response | Rationale | What sales says in the meantime | Owner |
|---|---|---|---|---|
| ExampleReport builder | Partner | Integration covers it at a fraction of the build cost | "We connect to your BI tool; here's the setup doc" | Sam, Product |
6. Where we lead
First row is an example, delete it. Fill this in before the roadmap conversation. A gap analysis with no advantages column reliably produces a plan to become a slower copy of a competitor.
| Our advantage | Why the buyer cares | Deals it wins | Is it defensible | How we protect it |
|---|---|---|---|---|
| ExampleLive in days, not weeks | They have a board commitment this quarter | Most deals with a hard deadline | Yes, it is architectural | Keep setup time in every release check |
7. Gap movement over time
First row is an example, delete it. A single snapshot cannot tell a closing gap from a widening one, and those need opposite responses.
| Capability | Position last review | Position now | Direction | What it suggests |
|---|---|---|---|---|
| ExampleAlerting relevance | Nobody did it well | Still nobody does it well | Static | Hard problem; an opportunity rather than a gap |
8. Decisions, owners and dates
First row is an example, delete it. Three to five rows. A gap analysis producing fifteen roadmap items has produced a backlog, not a decision.
| Finding | What we will do | Owner | By when | How we will know it worked |
|---|---|---|---|---|
| ExampleReport builder decides 6 mid-market losses | Ship the BI integration and add a reporting proof point to battlecards | Sam, Product | 30 Jun | Reporting appears in under 10% of loss reasons next quarter |
How to fill in your feature gap analysis
How to scope a feature gap analysis
The list of features you do not have is infinite, so an analysis without a boundary produces a document that is technically complete and practically useless. Two fields do the constraining: the decision this informs, and where the gaps came from. Gaps sourced from a competitor's website will fill a page with things no buyer has ever asked for.
Product and segment
Narrow it: "our platform, mid-market SaaS, ops-led evaluations". Gaps that matter in enterprise frequently do not exist as gaps in self-serve, and averaging the two produces a roadmap that fits neither.
Competitors compared
Two to four named products you actually lose deals to. Comparing against the union of every competitor's feature set generates a specification for a product nobody sells and nobody asked for.
Decision this informs
Name it: "what goes in the next two quarters of roadmap?" or "do we reposition around speed rather than depth?". Feature gap analyses commissioned without a decision become ammunition in whichever argument happens next.
Where the gaps came from
The most important field. Gaps from lost deals, support tickets and sales requests are grounded in demand. Gaps read off a competitor's feature page are grounded in their marketing, and treating the two as equivalent is how roadmaps get captured by competitors.
Owner
One named person, usually product marketing or product. Analyses owned by a group are refreshed by nobody, and this one ages quickly because competitors ship.
Date and next review
Quarterly suits most teams. Note the date the claims were verified: a capability gap statement has a short shelf life, and quoting a stale one in a roadmap review is how a team spends a quarter closing a gap that closed itself.
How to fill in the gaps in a feature gap analysis
Keep this to capabilities a buyer has actually asked about, usually eight to fifteen rows. The instinct to be exhaustive produces a grid nobody can act on and buries the two or three differences that decide deals. If you want the complete feature-by-feature comparison, build it in the interactive matrix linked below and bring only the differences here.
Capability, in the buyer's words
Quote how they ask for it: "Can we build our own reports?" rather than "custom reporting module". The buyer's phrasing carries the requirement; your internal feature name carries your architecture, and those are not the same thing.
What we have today
Be precise and honest, including partial coverage: "fixed report set plus CSV export". Partial answers are the most useful rows in the table, because they are where a workaround or a repositioning can close a gap without engineering.
What the strongest competitor has
Compare against the best in the set for that capability, not against each competitor separately. Naming which competitor it is matters, since a gap against one competitor you rarely meet is a different problem from a gap against your main rival.
Gap or advantage
Mark both. Analyses that record only gaps produce roadmaps that chase, and they systematically hide the strengths that are actually winning deals, which then get deprioritised for lack of visibility.
Evidence (link + date)
Their docs, changelog, pricing page or a dated screenshot: "their docs, 12 Mar". Never a sales rep's recollection of a demo. Capability claims decay faster than any other row here, and half of the ones teams believe about competitors were true two releases ago.
How to size the deal impact of each gap
This is the section that turns a feature comparison into a feature gap analysis. A capability difference nobody has lost a deal over is a difference, not a gap. Without this column every row looks equally urgent, and the loudest internal advocate wins the roadmap argument rather than the largest actual cost.
Deals it appeared in
How often it came up: "11 of 17 mid-market". Appearing frequently and deciding rarely is a real and common pattern, and it usually means the gap needs a talk track rather than a build.
Deals it decided
The stricter and more important number: how many were actually lost on it. This is the figure that should drive prioritisation, and it comes from win/loss interviews rather than from CRM close-reason fields, which record what the rep selected rather than what the buyer decided on.
Segment affected
Name it: "mid-market, ops-led evaluations". Gaps concentrate by segment and by who runs the evaluation, and a gap that only bites when a technical buyer leads the process may be a sales-motion problem rather than a product one.
Evidence
Point at the document: "Q1 win/loss report". If you have no win/loss data, say so and mark the sizing as an estimate. An honestly-labelled estimate is usable; a confident number nobody can trace will be challenged in the roadmap review and take the rest of the analysis with it.
Include the no-decision deals
Deals that stalled without a stated winner often stalled on a capability nobody wrote down. They are invisible in competitive loss data and worth checking specifically.
How to fill in severity against buyer priority
Severity is not how big the gap is, it is how much the buyer cares and whether anything works around it. Teams routinely panic about a capability a competitor markets heavily and buyers rank eighth, while ignoring a small gap that blocks evaluations outright. This section separates the two, and the workaround column is what most often changes the answer.
How the buyer ranks it
Use evidence from real evaluations: "top three requirement for ops buyers". Requirement documents, RFP scoring sheets and lost-deal interviews all give you this. A ranking you assumed is a guess in a table that looks like a finding.
Blocker or preference
The single most useful distinction here. A blocker removes you from the shortlist; a preference costs you points you can win back elsewhere. Most gaps are preferences, and treating a preference as a blocker is how a roadmap gets rewritten by one memorable lost deal.
Workaround we have today
Fill this in even when it feels weak: "scheduled CSV export into their BI tool". A surprising number of gaps already have a workaround that sales has never been told about, which makes this the cheapest possible fix in the whole template.
Severity
High, medium or low, derived from the previous columns rather than from feeling. High means it blocks a segment you care about and has no workaround. If a High row has a workaround, one of the two columns is wrong.
Do not rate severity by effort
How hard something is to build belongs in the next section. Mixing the two here produces the classic distortion where easy gaps look urgent and hard ones quietly get downgraded to medium.
How to fill in why the gap exists
This is the most commonly skipped section and the one that prevents the most expensive mistake in the template: rebuilding something the company deliberately chose not to build, without revisiting whether the reasoning still holds. Some gaps are the direct cost of a decision that is still correct, and closing them would undo the advantage in section 6.
Why we do not have it
The actual reason: "chose fixed reports to keep setup fast", "the data model does not support it", "nobody asked until this year". These lead to completely different responses, and the third one is far rarer than teams assume.
Was it a deliberate choice
Yes or no, with a date if yes. A deliberate trade-off deserves a re-examination of the trade-off, not an automatic reversal. If the answer is yes and nobody can now state what was being traded, that is the finding.
Rough effort to close
An order of magnitude is enough at this stage: "one quarter, two engineers". Precise estimates require scoping work that should not happen until the response section says build.
Confidence in that estimate
Be honest, and expect to write Low often: "low, not scoped properly". Unscoped estimates presented without a confidence label are how a one-quarter item becomes a three-quarter item, and the credibility cost lands on this document.
Check whether it is really a feature gap
A meaningful share of reported feature gaps are discovery gaps, onboarding gaps or documentation gaps: the capability exists and nobody could find it. Verify the capability genuinely does not exist before it enters a roadmap conversation.
How to decide the response to each feature gap
Building is one of five responses and it is rarely the best one. A team that closes every gap a competitor opens has outsourced its roadmap to that competitor, and it arrives at parity permanently one release behind. The discipline is that every gap gets an explicit decision, including the ones you accept, because an undecided gap resurfaces in every planning cycle forever.
The five responses
Build it. Partner or integrate so someone else's product covers it. Counter-position, meaning reframe the requirement so the gap stops mattering. Accept it and equip sales to say so plainly. Or disqualify, meaning stop selling into the deals where it decides. All five are legitimate, and the last two are chosen far less often than they should be.
Rationale
One line connecting the response to the impact and effort columns: "integration covers it at a fraction of the build cost". A response with no rationale is a preference, and preferences do not survive a roadmap review.
What sales says in the meantime
Every non-build response needs a talk track, and this is the field teams forget. "We connect to your BI tool; here's the setup doc" turns an accepted gap into a manageable conversation. An accepted gap with no talk track just becomes a lost deal with a confused rep.
Counter-positioning is underused
If a gap is the direct consequence of a choice that gives you a real advantage, say so openly: "we do not have a report builder because we optimised for teams that want to be live this month". Buyers respect a stated trade-off far more than a vague promise that it is on the roadmap.
Owner
A named person per row, agreed before publishing. Build rows go to product, counter-position rows go to product marketing, and accept rows go to enablement. Different responses have different owners, which is exactly why the response column has to come before the owner column.
How to fill in where you lead
Fill this section in before anyone opens the roadmap conversation. A feature gap analysis with no advantages column is a structurally biased document: it lists everything you lack and nothing you have, and it reliably produces a plan to become a slower copy of a competitor. Your advantages are also the raw material for counter-positioning in the previous section.
Our advantage
A capability difference in the buyer's terms: "live in days, not weeks". If you cannot name three, that is a serious finding and it belongs in the decisions block, ahead of any gap.
Why the buyer cares
The pressure it relieves: "they have a board commitment this quarter". An advantage nobody is under pressure to care about is a feature, not an advantage.
Deals it wins
Where it decides, from the same win/loss evidence as section 2: "most deals with a hard deadline". This is what protects the advantage in the next prioritisation round, when someone proposes trading it away for parity.
Is it defensible
Architectural, data-based or relationship-based advantages are durable. A feature a competitor could copy in a quarter is not, and knowing which you have changes how much you should invest in defending it.
How we protect it
The concrete mechanism: "keep setup time in every release check". Advantages erode quietly, usually as a side effect of closing gaps, and nothing in a normal planning process notices until it is gone.
How to track gap movement over time
A single snapshot cannot distinguish a gap that is closing from one that is widening, and those need opposite responses. This section is why the analysis is worth repeating rather than running once. It also surfaces the most valuable finding in the template: capabilities where nobody is good, which are opportunities rather than gaps.
Capability
Track the same capabilities each cycle. Changing the list resets the comparison, which is the most common reason teams have run this analysis three times and cannot say what moved.
Position last review and now
Both, in plain words: "nobody did it well" to "still nobody does it well". Keep the previous version of this document rather than overwriting it.
Direction
Closing, widening or static. A gap you are closing while a competitor stands still needs no further investment; the same gap while they accelerate needs a different plan entirely.
What it suggests
One line of interpretation: "hard problem; an opportunity rather than a gap". A capability nobody delivers well after several years is usually genuinely difficult, and that is a market opening rather than a deficiency. Our study of 500 verified G2 reviews across the four leading competitive intelligence tools found alert relevance criticised in all four, which is precisely this pattern.
Watch for parity convergence
If most of the grid has gone from mixed to universally supported, the category is commoditising on features and the competitive argument has moved somewhere else, usually to price, service or distribution. That is a strategy finding, not a roadmap one.
How to fill in the decisions section of your feature gap analysis
Three to five rows. This template is unusually prone to producing a long list, because every row in section 1 feels like it implies work. It does not: most rows should end in accept, counter-position or partner, and only the few with real deal impact and no workaround should reach the roadmap.
Finding
Sized, and traceable to section 2: "report builder decides 6 mid-market losses". A gap without a number attached will lose the roadmap argument to whichever gap has one, regardless of which matters more.
What we will do
The concrete action from the response column, and usually there are two: something for product and something for sales enablement. Teams routinely do the first and skip the second, then wonder why the loss rate did not move for two quarters.
Owner
A named person, agreed in advance. Roadmap rows owned by "product" are the rows still open at the next review.
By when
For build rows, the date it enters the roadmap rather than the date it ships, so the row can actually be closed. For counter-position and accept rows, the date the talk track reaches reps, which is usually much sooner and worth more.
How we will know it worked
Expressed in win/loss terms: "reporting appears in under 10% of loss reasons next quarter". This is the only way to find out whether closing the gap did what the analysis predicted, and it is what makes the next analysis credible.
Sourcing and upkeep: keeping a feature gap analysis honest
These rules apply to every section above. Feature gap analysis has a specific failure mode that is worth naming plainly: it is the artifact most likely to convert competitive research directly into a roadmap that copies a competitor. The structure here is designed to resist that, but only if these habits come with it.
Source gaps from buyers, not from competitor websites
Gaps drawn from lost deals, requirement documents and support tickets are grounded in demand. Gaps read off a competitor's feature page are grounded in their marketing team's priorities, and a roadmap built from them is a roadmap that competitor wrote.
Verify every competitor capability claim
Their documentation, changelog or a dated screenshot, never a rep's memory of a demo or a claim from a battlecard. A significant share of what teams believe about competitor capabilities was accurate two releases ago, and half of it was never accurate.
Parity is not a strategy
Closing every gap produces a slower copy of a competitor and permanent one-release-behind parity. The purpose of this document is to decide which gaps to accept on purpose, and an analysis where every row ends in build has not done that work.
Always record advantages alongside gaps
A gaps-only document is structurally biased toward chasing and quietly puts your real differentiators at risk in the next prioritisation round, because nothing in the process makes them visible.
Check for discovery gaps before roadmap gaps
Verify the capability genuinely does not exist. A meaningful share of reported feature gaps turn out to be things the product does that buyers could not find, and the fix is documentation or onboarding at a fraction of the cost.
Refresh quarterly and keep the old version
Competitors ship, so these claims go stale faster than anything else in a competitive stack. The comparison between versions is where the movement section gets its data, and movement is more decision-useful than any single snapshot.
Do not present it without the sizing
A feature gap analysis circulated without deal impact numbers becomes a wish list, and it will be prioritised by whoever argues most persuasively rather than by what is actually costing revenue.
How to roll out your feature gap analysis
- 1Copy or download the blank template. Use Copy to paste it straight into Google Sheets or Excel with the columns intact, or download the CSV, Notion or PDF version.
- 2Source the gaps from lost deals, not competitor websites. Gaps from real evaluations are grounded in demand. Gaps read off a competitor's feature page are grounded in their marketing.
- 3Delete the example rows. Each table ships with one example row so the pattern is obvious. Remove it before you share the analysis.
- 4Size each gap by deals it actually decided. Appearing in a deal and deciding one are different numbers. The second is the one that should drive the roadmap.
- 5Separate blockers from preferences, and note the workaround. Most gaps are preferences, and a surprising number already have a workaround that sales was never told about.
- 6Fill in where you lead before the roadmap conversation. A gaps-only document reliably produces a plan to become a slower copy of a competitor.
- 7Give every gap one of five responses. Build, partner, counter-position, accept, or disqualify. Accepting a gap on purpose is a decision, and it needs a talk track for sales.
- 8Finish with three to five owned decisions. Each with a named person, a real date and a win/loss measure, then check next quarter whether the loss reason actually moved.
Feature gap analysis FAQ
What is feature gap analysis?
Feature gap analysis is a structured comparison of what your product does against what competitors do, filtered by what buyers actually ask for, and ending in a decision about each difference. The part that makes it analysis rather than comparison is the decision: every gap gets an explicit response, which may be to build it, partner around it, counter-position, accept it deliberately, or stop selling into the deals where it decides.
What is a feature gap?
A feature gap is a capability a buyer expects, a competitor provides, and your product does not. The qualifier that matters is the first one. A capability a competitor has that no buyer has asked you for is a difference, not a gap, and treating the two as equivalent is how a roadmap ends up being written by a competitor's marketing team.
How do you do a feature gap analysis?
Scope it to one product and segment and name the decision it informs. Collect gaps from lost deals, requirement documents and support tickets rather than from competitor feature pages. Record what you have, what the strongest competitor has, and the evidence. Size each gap by the deals it actually decided, then rate severity by buyer priority and whether a workaround exists. Establish why each gap exists before proposing to close it. Give every gap one of five responses, record where you lead, and finish with three to five owned decisions.
What are the 4 steps of gap analysis?
In its general form: describe the current state, define the desired state, identify and quantify the gap between them, and plan how to close it. That structure is sound and it is what most gap analysis templates implement. Applied to features, it needs one addition, which is where most versions fall down: the desired state is not "whatever competitors have", it is what your buyers actually require. Skipping that filter turns step two into a transcription of a competitor's feature list.
What are the elements of a gap analysis?
Four essential elements: the current state described honestly, the target state defined by a credible source of requirements, the gap between them quantified rather than merely named, and an action plan with owners and dates. A feature gap analysis adds three more that generic templates omit: the deal impact of each gap, whether the gap was a deliberate product choice, and an explicit response decision that is allowed to be "accept this on purpose".
What is an example of a gap analysis?
You find that eleven of seventeen mid-market deals raised custom reporting, and six were lost on it. Your product has fixed reports plus CSV export; the competitor has a drag-and-drop builder. Buyers rank it a top-three requirement when ops runs the evaluation, so it is a blocker in that segment, but a scheduled export into their BI tool covers most of the need and sales did not know that. The response is partner rather than build: ship the BI integration, give sales the talk track, and re-check the loss reason next quarter.
What are the types of gap analysis?
Gap analysis is a general method applied across many domains: product and feature gaps, skills gaps, process gaps, compliance gaps, market gaps and performance gaps. They share the current-state, target-state, plan structure and differ entirely in where the target state comes from. That source is the whole game. For features it is buyer requirements evidenced by real evaluations, which is why this template spends more space on sourcing and sizing than on the comparison itself.
What are the 4 types of gaps in business planning?
The classic business-planning taxonomy lists four: the performance gap, between actual and expected performance; the product or market gap, between actual and budgeted sales; the profit gap, between actual and target profit; and the manpower gap, between the workforce you have and the one you need. Worth noting that none of them is a feature gap. Feature gap analysis is a product and competitive variant of the same method rather than one of the classic four, so pages presenting those four as an answer to a feature question are answering a different question.
What are the 5 gaps in the gaps model?
That refers to the Gaps Model of Service Quality developed by Parasuraman, Zeithaml and Berry, introduced in a 1985 Journal of Marketing article and operationalised as the SERVQUAL instrument in 1988. Its five gaps are the knowledge gap between what managers think customers expect and what they actually expect, the standards gap between those perceptions and the service specifications set, the delivery gap between specifications and actual delivery, the communication gap between what is promised externally and what is delivered, and the customer gap between expectation and perception overall. It is a service quality framework, not a feature framework. The one that transfers directly is the communication gap: promising a capability in marketing that the product delivers differently creates a perceived feature gap out of nothing.
How do you create a gap analysis template?
Start from the four-step structure, then add the columns that make it decidable rather than merely descriptive. At minimum: the capability in the buyer's words, what you have, what the competitor has, evidence with a date, the deals it decided, whether it is a blocker or a preference, whether a workaround exists, and the response decision with an owner. The template on this page is that structure. The columns most often missing elsewhere are deal impact and the response decision, and without those a gap analysis is a comparison table with ambitions.
How do you display or visualise a gap analysis?
For features, a table beats a chart. The two visuals that genuinely help are a simple supported/partial/not-supported grid for the comparison, and a two-axis plot of deal impact against effort to close, which makes the prioritisation argument visible without anyone having to make it. Avoid radar and spider charts: they imply that every axis is equally weighted and equally scaled, which is exactly the assumption a gap analysis exists to challenge.
How do I do a gap analysis in Excel?
Use Copy above to paste this template straight into a sheet with the columns intact, or download the CSV. One tab per section works well, with the gaps tab as the key that the impact, severity and response tabs reference. Conditional formatting on the severity column makes the sheet scannable. The limit is upkeep rather than structure: a spreadsheet will not tell you that a competitor shipped the capability in row four last month, so the comparison is only as fresh as the last time someone re-checked every link.
Can ChatGPT do a gap analysis?
It is genuinely useful for the structuring and synthesis: grouping raw feedback into capability themes, drafting the comparison, and summarising a long requirements document. It is not reliable for the facts. Assistants confidently state competitor capabilities that are outdated or invented, and a fabricated feature claim entering a roadmap decision is expensive in a way a fabricated blog sentence is not. Use it to structure, then verify every competitor cell against their documentation or changelog with a date. Our guide on running competitive analysis with AI covers the verification workflow.
What is the difference between a feature gap analysis and a feature comparison matrix?
A feature comparison matrix records who supports what: it is the grid, and it is deliberately exhaustive. A feature gap analysis takes the differences that matter, sizes them by deals lost, judges severity against buyer priority, establishes why each gap exists, and decides a response for each. The matrix is the input; the analysis is the decision layer. Our free interactive comparison matrix builds the grid for you, and this template is what you do with the result.
Should you build every feature a competitor has?
No, and this is the most consequential judgement in the whole exercise. A team that closes every gap a competitor opens has handed them the roadmap and will sit permanently one release behind parity, while the differentiators that were actually winning deals get deprioritised for lack of anyone defending them. Most gaps should end in partner, counter-position or deliberate acceptance. Reserve building for gaps that are blockers, in a segment you have chosen, with no workaround, and with deal-loss evidence behind them.
How do you prioritise feature gaps?
By deals decided, not by how often the gap is mentioned and not by how loudly it is requested internally. Rank on three inputs together: the number of deals actually lost on it, whether it is a blocker or a preference in the segment you care about, and whether a workaround exists that sales simply has not been given. A frequently-mentioned gap with a workaround usually needs a talk track and a documentation fix, which takes a week rather than a quarter and is the single most under-taken action in this template.
How do you size the revenue impact of a feature gap?
Count the deals it decided in the period and attach their value, then state the sample size alongside it: "six mid-market losses, roughly $340k in ARR, from 17 competitive deals". If you have no win/loss data, say so and mark it as an estimate rather than producing a confident number nobody can trace, which will be challenged in the roadmap review and will discredit the rest of the analysis. Resist multiplying up to a total addressable loss figure; the assumptions compound and the number stops meaning anything.
How often should you run a feature gap analysis?
Quarterly, aligned to your roadmap planning cycle so the output arrives when decisions are actually being made, plus an immediate check after a significant competitor launch. Competitor capability claims go stale faster than anything else in a competitive stack, which is why every row carries a verified date. Keep each version rather than overwriting: the movement between them is more decision-useful than any single snapshot.
Who should own feature gap analysis?
Product marketing usually owns the analysis, because it sits between buyer evidence and product decisions and requires access to both. Product owns the effort estimates and the build decisions, and sales supplies what actually happened in evaluations. The important structural point is that the person who owns the analysis should not be the person who owns the roadmap, since an analysis run by whoever will act on it tends to find the gaps they already wanted to close.
What are the most common mistakes in feature gap analysis?
Five recur. Sourcing gaps from competitor websites rather than from lost deals, which imports their marketing priorities into your roadmap. Listing gaps without sizing them, so prioritisation goes to whoever argues best. Recording no advantages, which biases the whole document toward chasing. Skipping why the gap exists, and so rebuilding something the company deliberately traded away. And ending in a backlog rather than three to five decisions, one of which should usually be to accept a gap on purpose and tell sales exactly what to say about it.
Keep feature gap analysis current, automatically
Flares tracks what competitors ship and change, so your comparison reflects this month rather than last quarter.
Discover Flares14-day free trial · 30-second setup