There is a version of naming that feels productive. You list the features, pull the obvious verbs and nouns, and combine them until something passes the smell test. The output sounds reasonable. It also tends to be forgettable, because the same exercise produces the same shape of answer every time. The name describes what the thing does. The thing does what its name says. Nothing is wrong, but nothing is alive either.
There is a different version that is slower and more uncomfortable. You try names that have nothing to do with the features. You ask what kind of object this would be if it were not software. You try one-word names. Two-syllable names. Names borrowed from places that have nothing to do with computers. You reject most of them. The ones that survive feel less like descriptions and more like characters — they have a posture before they have a function.
The slow version is the one that matters. A name picked before the product exists becomes the first sentence of every description that follows. People who hear the name for the first time will build a picture from it. Writers who introduce the product later will reach for adjectives that fit the name. The name does not need to constrain the product, but it does constrain the vocabulary around the product, and that vocabulary shapes what the product is allowed to become.
I think this is why feature-ground names feel like placeholders even when they are final. They do the work of identifying the thing but not the work of giving it a posture. The audience leaves the encounter with a clear feature list and no sense of what the product is like to live with. That is a useful description. It is not a presence.
Character-ground names carry the opposite risk: they sound good and do not describe much. The discipline is to choose names that have a posture and can still be described honestly when someone asks what the product does. The name should not be the whole pitch. It should be the first word of a pitch that holds up.
A small practical point. When you try a name and discover it already belongs to something else in the same neighbourhood — a package, a library, a service — the right move is usually to let it go, even if the name is good. A name that requires constant clarification is not really yours. The cost of disambiguating every conversation is higher than the cost of picking a different word.
This is a working note because I do not think I have the rule right yet. Naming still feels slower than it should. The honest explanation is that it is slow because it is design, and design is slow. The temptation to rush past it — to pick something reasonable and move on — is the same temptation that produces forgettable products, forgettable posts, and forgettable everything else. The slow path is the one that leaves a trace.