Vocabulary is product strategy

I once sat in a meeting where four people used the word "update" to mean four different things.

For one person, an update was the message you posted in Slack on Friday afternoon. For another, it was the record in the system showing what had changed since last week. For a third, it was the act of refreshing a dashboard. For a fourth, the most senior person in the room, it was the conversation you had with your manager when something was off track.

We had been talking past each other for a month. The roadmap had three "update" features on it, and each one was being designed by someone with a different mental model. We discovered the disagreement on a whiteboard at the end of a long meeting, and we spent the next two hours just renaming things.

Two of the features collapsed into one. One was cut. The third was rebuilt with a clearer scope. The product that came out of that whiteboard was meaningfully better than the one we had been about to build. We had not changed the design yet. We had changed the vocabulary.

Vocabulary is one of the most underrated parts of design work. Words are load-bearing walls. When you change a word, you change what the product is.

The first thing a word does is choose a metaphor, and the metaphor brings affordances with it.

If you call the thing a thread, the user expects it to have replies, expects it to live alongside other threads, expects it to be findable by participant. If you call the same thing a channel, the user expects it to be persistent, broadcast-shaped, joinable. If you call it a room, presence becomes relevant. If you call it a document, editing does.

These are not interchangeable. The thread, the channel, the room, and the document may share a lot of underlying mechanics: text in, text out, timestamps, participants. But they imply different futures. Users will request different features from each. Engineers will architect each differently. The PM will roadmap each differently.

When you pick the word, you have made an enormous number of downstream decisions you may not have realized you were making.

I worked on a product that had something called check-ins: small, recurring moments where a user confirmed how something was going. For six months I treated check-ins as a single feature. They had a single page, a single data model, a single design language.

Then a user said, in passing, "I do my check-ins in three different ways depending on what triggered them."

It turned out that check-ins on a schedule, check-ins prompted by a system signal, and check-ins the user initiated for their own reasons were three different things wearing one name. The data looked similar. The user's posture in each was completely different.

We split the word. Scheduled check-ins kept the name. Signal-prompted check-ins became observations. User-initiated check-ins became something else. Each got its own page, its own data shape, its own design treatment.

After that split, we shipped more useful product than we had in the previous six months. Three distinct things had been frozen inside one word, and the word was the lock.

This happens constantly. A fuzzy term is a junk drawer with a roadmap hidden inside it. Everyone keeps putting different work into the same drawer, and then the team wonders why nobody can find what they need.

The roadmap cannot be built because the team cannot agree what it is. The team cannot agree what it is because the word does too much work. The fix is fewer words doing less work each.

Words also tell the user what kind of person they are while they are using the product.

A task implies someone with a list, ticking through obligations. A goal implies someone with ambition, picking a direction. An objective implies someone in a meeting, accountable to others. A priority implies someone with too much to do, choosing among items.

These are different identities. The product that calls the same artifact a task vs. a goal vs. an objective vs. a priority is a different product, even if every screen, every field, and every flow is identical. The user shows up differently. The product gets used differently. The product sells differently.

Choosing the word is choosing the user.

A working glossary is one of the highest-return design artifacts I make. It is a single page. It lists the dozen or two terms that do the heaviest lifting in the product. Each entry has a definition, an example, and a not-this list: the meanings the word does not carry, with the alternative words that do.

The glossary is the map legend for the product. Without it, everyone is looking at the same terrain and reading it differently.

The glossary is owned by design, but used by everyone. Engineers consult it before naming variables. PMs consult it before writing tickets. AI agents, in my workflow, consult it before writing copy. Stakeholders read it to learn the product. Customer-facing copy uses it.

When the glossary changes, the product changes. A renaming is a real change, even if no pixels move.

The two rules I follow:

No silent synonyms. If two words are doing the same job, one of them is wrong. Pick one, kill the other, update everywhere. Synonyms in a product vocabulary breed disagreement.

No double-duty words. If one word is doing two jobs, both jobs are getting underserved. Find the seam, split the word, name the pieces.

AI makes vocabulary work more important.

When a product starts using language models, agents, retrieval systems, generated copy, or conversational interfaces, the product's vocabulary becomes part of the system's operating environment. The model reads your words and uses them as handles.

If your product has three different meanings for "update," the AI will not magically resolve that ambiguity. It will inherit it. Worse, it may perform the ambiguity back to the user with a tone of confidence that makes the confusion harder to catch.

A fuzzy product vocabulary used to create fuzzy meetings. Now it creates fuzzy model behavior.

The glossary becomes more than a copy artifact. It becomes prompt context, retrieval context, evaluation criteria, tool-routing logic, and a shared contract between the product, the team, and the machine.

If the AI is deciding whether to draft a response, open a form, summarize a record, recommend a next step, or ask a follow-up question, the words in the product shape that decision.

In a traditional interface, bad vocabulary creates friction. In an AI-mediated interface, bad vocabulary creates drift.

The AI may choose the wrong object. It may retrieve the wrong examples. It may generate the right-sounding sentence for the wrong user posture. It may collapse two different workflows because the product gave both of them the same name.

The glossary, in this context, becomes a kind of semantic API. Not an API made of endpoints and payloads, but an API made of meanings. It tells the system: these things are different, these things are the same, this word carries this intent, this word does not.

That difference separates an AI layer that sounds fluent from one that understands the product it is operating inside.

The more AI a product contains, the more dangerous it becomes to treat words as decoration. Language is no longer just the surface. It is the material the system reasons through.

The temptation, when a word feels wrong, is to coin a new one. Sometimes that is right. Most often it is not.

Coined words have to earn their keep. They cost the user a moment of learning every time they are encountered. They cost the team a vocabulary entry, a glossary line, a translation in every external conversation.

The bar for a coined word should be high: no existing word fits, and the new word picks the right metaphor. If a borrowed word is close, borrow it.

The signal that you should coin is that no available word picks the right metaphor without dragging in the wrong affordances. The signal that you should borrow is that the word almost works and the parts that do not work are negotiable.

The reason vocabulary work is undervalued is that it looks like copywriting from the outside. Someone changes a button label. Someone renames a feature. Someone updates the glossary. The diff is small. The artifacts look the same.

But every word in a product is a decision about what the product is. The button label is a strategy document compressed to two words. The feature name is a roadmap compressed to one. In practice, the glossary often becomes the spec for what the team will build next.

Designers who treat vocabulary as a polish step at the end will keep being surprised that the team cannot agree on what they are building. Designers who treat vocabulary as the first move will be surprised by how much less arguing they have to do.

And in AI products, this gets sharper. The product acts through the words that describe it.

Pick them on purpose.