A Feature Comparison Prompt for Competitors, Tier by Tier

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

The asymmetry is the problem. A tick is roughly reliable, because a vendor claiming a capability on their own site has committed to it. A blank is unreliable in four different ways at once, and the matrix records all four identically.

The fix is not to work harder at filling the grid. It is to stop using a symbol that cannot carry the distinction, which 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 capability outright. VAGUE means a page gestures at it without saying what it does, which is a real and common state that a tick and a blank both misrepresent. 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. The instruction that matters is making the model state that ABSENT means not in these sources rather than not in the product, because 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.

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

The order matters more here than anywhere else in this library. Defining the rows before comparing anything is what stops two different capabilities being compared under one name, and it is the step that gets skipped because it produces no visible output.

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, and those two documents disagree more often than any other pair a vendor publishes.

We asked whether a real product includes four common sales capabilities, 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 capabilities of that product, and a reviewer checking whether the product does these things would have marked the answer correct. A buyer on the entry plan would have found out otherwise, because the page states all four on Professional and above and states none of them for Starter.

The line that was not on the page

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

This is the version worth guarding against, because it is the one a careful reader will wave through. An invented boundary is more specific than the truth rather than vaguer, and specificity is what people use as a proxy for having checked. The blurry answer gets questioned; the confident structural claim does not.

Everything above is about filling cells honestly. The larger bias in a feature comparison is never in the cells, and it does not survive scrutiny because nobody scrutinises it: it is in which rows exist at all.

A matrix assembled from your own product’s capability list will show you ahead, reliably, whatever the products actually do, because every row is something you decided to build. A matrix assembled from a competitor’s page shows the reverse. Neither is dishonest and both are useless, and 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 capabilities 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, occasionally uncomfortable, and it is the one where a gap costs you something. The rest belongs in an appendix that exists for the one buyer a year who asks for it.

It is worth naming what this does to the document. A matrix built from deal evidence is smaller, has more genuine ties in it, and makes fewer claims. It also survives being read by somebody sceptical, which the ninety-row version does not.

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 distinguishes that row from the others.

The row that changes is rarely a random one. It is the capability a competitor was missing, that you built a differentiator on, and that they therefore prioritised. The gap you lead with is the gap most likely to close, and the first sign is usually a rep reporting that a buyer laughed at a claim in the battlecard.

Flares watches competitor product pages, release notes and changelogs, so a capability appearing where there was previously an ABSENT label reaches you dated rather than anecdotally. Which rows belong in the matrix, and what a closed gap means for your positioning, stay judgement calls.

The honest limit is documentation itself. A vendor that ships quietly and documents late will show up late in any monitoring, which is an argument for treating recent ABSENT labels as provisional rather than for checking more often.