Feature Comparison Prompts for Competitive Intelligence

A feature matrix presents itself as a statement about products. It is a statement about pages. A tick means something you saved said so. A blank means nothing you saved did. Both are much weaker claims than the grid implies, and both are all the evidence supports.

The two are not equally sound, and that is the problem. A tick is roughly reliable, because a vendor claiming a feature on their own site has committed to it. A blank is unreliable in four different ways at once, and the matrix records all four the same way.

The fix is not to work harder at filling the grid. It is to stop using a symbol that cannot carry the difference. That is why every prompt here labels a cell rather than ticking it.

EXPLICIT, VAGUE and ABSENT, and why the third needs a sentence

EXPLICIT means a page names the feature outright. VAGUE means a page waves at it without saying what it does. That is a real and common state, and a tick and a blank both get it wrong. ABSENT means no page you supplied mentions it.

ABSENT is the one that needs its meaning written into the output, not just into your head. Make the model state that ABSENT means not in these sources, rather than not in the product. The matrix will outlive the conversation in which you knew the difference. A label that carries its own caveat survives being forwarded. A blank does not. Comparing like with like across a whole set is competitive benchmarking, and it needs the same labelling discipline one row at a time.

Two files, one decision and one act of honesty about your own product.

Order matters more on this job than on almost any other. Define the rows before you compare anything, and two different features stop being compared under one name. It is also the step that gets skipped, because it produces nothing you can see.

The plan check runs against pricing pages rather than product pages, and that is deliberate. A product page describes what a product can do. A pricing page describes what a customer gets. Those two documents disagree more often than any other pair a vendor publishes. Where the disagreement is about what a tier includes rather than what exists, a pricing comparison is the job that settles it.

We asked whether a real product includes four common sales features, then opened its plan comparison page. All four answers were yes. All four were the wrong answer.

Sequences, call recording, forecasting and custom reporting are all real features of that product. Anyone checking whether the product does these things would have marked the answer correct. A buyer on the entry plan would have found out otherwise. The page states all four on Professional and above, and none of them for Starter.

The plan boundary the page never draws

The answer did not just leave the plan out. It supplied one, splitting the four into core parts of the product and paid-tier extras. On the page all four sit on the same tier, so that split came from somewhere other than the source.

This is the version worth guarding against, because a careful reader waves it through. An invented boundary is more specific than the truth rather than vaguer, and people read detail as a sign that somebody checked. The blurry answer gets questioned. The confident, precise one does not. A cell that reads ABSENT for a year is also the clearest statement of a competitive gap you will get, provided the label carries the date it was checked.

Everything above is about filling cells honestly. The bigger bias in a feature comparison is never in the cells. It is in which rows exist at all, and it survives because nobody checks it.

A matrix built from your own product’s feature list will show you ahead every time, whatever the products actually do, because every row is something you decided to build. A matrix built from a competitor’s page shows the reverse. Neither is dishonest, and both are useless. The tell is the same in both cases: a long tail of rows nobody has ever been asked about in a deal.

Build the row list from deals, not from products

The list worth having comes from evaluations. Which features have appeared in a request for proposal, been raised unprompted on a call, or turned up in a closed-lost reason. That list is usually short, sometimes uncomfortable, and it is where a gap costs you something. It is also the list a pre-sales team gets questioned on in a demo, so every row needs an answer somebody has tested. The rest belongs in an appendix, for the one buyer a year who asks.

It is worth naming what this does to the document. A matrix built from deal evidence is smaller, has more real ties in it, and makes fewer claims. It also survives a sceptical reader, which the ninety-row version does not. A product comparison written for a buyer rather than for an internal review is shorter again.

A feature matrix does not go out of date all at once, which is what makes it dangerous. Most rows stay true for a year. One row changes the week after you published it, and nothing in the document tells that row apart from the others.

The row that changes is rarely a random one. It is the feature a competitor was missing, that you built a differentiator on, and that they therefore put at the front of the queue. A feature gap analysis is where those rows are worth tracking separately, because they are the ones with a date coming. The gap you lead with is the gap most likely to close. You tend to find out when a claim in the battlecard stops surviving contact with a buyer.

Flares watches competitor product pages, release notes and changelogs. A feature appearing where an ABSENT label used to sit then reaches you dated, rather than by word of mouth. Which rows belong in the matrix, and what a closed gap means for your positioning, stay judgement calls.

The honest limit is the documentation itself. A vendor that ships quietly and documents late will show up late in any monitoring. That is an argument for treating recent ABSENT labels as provisional, not for checking more often. Legal technology vendors are the hard case, because contract review and drafting features ship weekly and only the release notes date them. Documentation is not the only surface that lags. Reading a competitor’s website as a structure catches renames the docs have not absorbed yet. Their pricing page moves faster than either, and competitor pricing is where a tier boundary shifts before any document mentions it.