The differentiator test: if a rival can copy the claim, it isn't one
DEV Community

The differentiator test: if a rival can copy the claim, it isn't one

The problem with a "differentiators" section

I was reworking a product landing page and stared at the differentiators block. Five confident claims. Then I ran each through one question: could a competitor put this exact sentence on their own page?

Claim Rival can copy it?
On-prem, sovereign, your infrastructure Yes
One line of accountability, one throat to choke Yes
Governance-first architecture Yes
Adopt at your pace, grows with you Yes
Priced per deployment, not per seat No

Four of five failed. Not because they're untrue - because they describe the category, not the product. Every serious vendor in the space says "governance-first" and "sovereign." A claim your rival can echo verbatim isn't a differentiator; it's table stakes wearing a badge.

Keep only what's structural

The fix isn't better adjectives. It's finding claims that come from how the thing was actually built - facts a competitor would have to rebuild their company to match.

What survived:

  • Designed as one, not assembled from acquisitions. Most enterprise suites are bolted together from bought products, each with its own data model and directory, and seams nobody removes. "Built by one team as one system" is checkable and structural - you can't retrofit the absence of acquisitions.
  • The whole suite runs inside your perimeter. Sharpened from generic "on-prem" to "air-gappable in full" - not one self-hostable module while the rest phones home.
  • Products that stand on their own. Several products built inside the suite ship live under their own brands. That's proof, not a promise - and it answers the lock-in fear without having to name it.
  • Priced per deployment. The one that already passed.

The pattern: a good differentiator is a fact about your construction, phrased so a reader can check it. If it's an adjective anyone can claim, cut it.

Make the diagram say it out loud

Same day, same lesson on the visuals. Two diagrams were technically correct and practically useless.

One was drawn as a funnel - but the content was a sequence (order flowing through stages), not a filter narrowing down. Readers auto-read "funnel" as "we lose people at each step." Relabeled and redrawn to show order, not attrition.

The other was a balance scale meant to convey per-deployment pricing. Too abstract - you had to stare to work out what it argued. I replaced it with a cost-vs-headcount line chart:

cost
 โ”‚    โ•ฑ per seat (rises with headcount)
 โ”‚   โ•ฑ
 โ”‚  โ•ฑ
 โ”‚โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ per deployment (flat)
 โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ–บ users

The flat line and the crossover state the argument literally: the same fee whether ten people use it or ten thousand. No decoding required.

Takeaway

Two versions of one rule. For copy: if a rival can say it too, it isn't a differentiator - keep only the structural, checkable claims. For diagrams: if the reader has to decode the metaphor, it's failing - redraw until the shape is the argument. Both come down to the same thing: say the true, specific thing, and let it stand without decoration.

Comments

No comments yet. Start the discussion.