Every product page lists capabilities. Almost none list the things the system is structurally unable to do. An argument for publishing limitations as a design discipline rather than a confession, and what changes in the engineering when you commit to it.
Every product page is a list of yeses
The universal format is a catalogue of capabilities, which is uninformative precisely because it is universal. When every page lists what a thing can do, the list stops distinguishing anything.
It also hides the more interesting difference. Nothing on such a page separates a product whose limits were examined and decided from one whose limits were never looked at — and the second will usually have the longer catalogue, because a team that has not investigated its boundaries has no reason to stop claiming.
A limitation is a costly signal
Stating a limitation loses sales. It constrains the roadmap. Somebody internally argues against every one of them, usually with a good commercial reason.
That cost is the point. Claims that cost nothing to make get made by everyone, honest or otherwise, and therefore carry no information. Claims that cost something are made only by people who decided the cost was worth paying, which is a fact about them worth knowing.
This is why a published limitation tells you more than a page of capabilities. Not because its author is unusually virtuous, but because nobody says it by accident.
What it does to the engineering
This is the part I actually value, and it surprised me.
Writing the sentence forces you to know whether it is true. More than once, drafting a plain statement of what a system could not do exposed that I did not know whether the property held — whether it was guaranteed by construction or merely happened to be the case given how the code currently ran.
That finding is worth more than the sentence that prompted it. A limitation you cannot state precisely is a limitation you have not verified, and a system whose limits you have not verified is one whose behaviour you are describing from memory.
The three kinds of limitation
They are not equivalent, and conflating them is where dishonesty usually enters.
Structural. The system cannot do this by construction. The most valuable kind to publish, because it is a property rather than a status.
Current. Not built. Could be. This is a roadmap statement wearing a capability's clothes.
Chosen. Could be built and deliberately is not, for a reason worth stating — usually because doing it would require holding something the design exists to avoid holding.
The two common deceptions are opposite. Presenting a current limitation as structural avoids work while sounding principled. Presenting a structural one as current keeps a sale alive on a promise that cannot be kept. Both are easier than they should be, because almost nobody labels which kind they mean.
What it protects you from
Self-interest, plainly, because the noble version of this argument is less persuasive and less true.
A user who was told cannot later say they were misled, and that sentence is worth more than it looks when something goes wrong.
A limitation published in advance is a decision. The identical limitation discovered by a user in month four is a failure, and it is the same fact both times — only the sequence changed.
And support load falls, because most of it is the gap between what people expected and what the thing does.
The objection, taken seriously
Competitors will not do this, and beside a page of unqualified strengths, a page listing what you cannot do reads as weakness. That cost is real and I am not going to argue it away.
The answer is about which customers you are selecting for. People who read limitations are people who have been burned by a product that overpromised, and they are disproportionately the ones who stay. A sale made on a misunderstanding is a refund, a complaint, and a public review arriving on a delay.
How I write them
One sentence a non-specialist can check. Not "limited offline capability" but "changes made without a connection are lost when the tab closes".
Labelled by kind. Structural, current, or chosen, said outright, so the reader knows whether to wait for it.
Stated in consequence rather than in the abstract. What it means on a Tuesday, to somebody trying to do a thing.
And revisited when the architecture changes, because a structural claim can quietly stop being true, and a limitation that has become false is worse than one never published — somebody relied on it.
Close
None of this is generosity. It is the cheapest available way to find out what your system actually does, and the cheapest available way to be believed later.