TL;DR
- I rewrote a product's differentiators after noticing four of five were claims any competitor could paste onto their own page word-for-word.
- The test: could a rival put this exact sentence on their site and have it be just as true? If yes, it's a category description, not a difference.
- Keep only claims rooted in how the thing was built — structural facts a rival can't retrofit.
- Same discipline for diagrams: if the reader has to decode it, redraw it so it states the argument literally.
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 (dacing) 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.
Top comments (1)
Nice write-up! For devs who deal with messy copied text, TextStow might help — it's a Mac menu bar tool combining clipboard history with prompt templates and text cleanup. Free: textstow.com