How to build a naming system for multiple products

Decide what the parent brand is for

Everything else follows from this, so make it explicit before naming anything. There are four structures, and most confusion comes from a company drifting between two of them without noticing.

That last row is where more companies belong than choose it. The instinct once a product grows is to brand its major features, and most of the time those features are not things a customer needs to recognise independently. A capability with a name is a thing to learn; a capability described plainly is a thing to use.

Choose a consistent level of description

Within a family, the names should sit at roughly the same distance from what they do. One literal name beside one abstract invented one reads as an accident, because it is.

So pick a register and stay in it. Either everything is plainly descriptive — Invoices, Payroll, Reports — or everything is a distinct word at a similar remove — Ledger, Pulse, Beacon. What you cannot do is mix Invoices with Zephyr and expect a customer to work out how the two relate.

Consistency does not mean the names look alike. It means somebody encountering the third one can tell it belongs to the same family as the first two.

Create a pattern loose enough to survive

Patterns are what make a portfolio legible: a shared prefix, a shared ending, a theme the names are drawn from, a consistent grammatical shape.

The trap is a pattern too tight to extend. A theme with a small vocabulary runs out — a company that named three products after birds will name the eighth one after something that is technically a bird — and every forced name afterwards advertises that the system broke. Before adopting a pattern, generate the next five names inside it and see whether they are still good. If the fifth one is a stretch, the pattern is too narrow.

A shared grammatical shape ages better than a shared vocabulary. 'Two syllables, ends in a vowel' will never run out; 'named after Greek gods' has a hard limit and a tone you may not want in four years.

Test names together, never alone

This is the test that only exists for portfolios, and it is the one that catches most problems. A name that works in isolation can be unusable beside its siblings.

Put the whole set into the places it will actually appear:

• A pricing page, in a row — where similar-length names with similar endings turn into a blur.
• A navigation menu, where they compete for a glance.
• A sales slide, read aloud in order.
• A support conversation: 'that is in Pulse, not Pace' is a sentence somebody will say a thousand times.
• A dropdown or a settings screen, alphabetised, where accidental adjacency appears.

Read the full set out loud in one breath. Two products whose names share a first syllable, or rhyme, or differ by one vowel, will be confused by customers and by your own staff — and that cost is paid on every support call rather than once.

Protect distinguishability by sound

Customers discuss several of your products in one meeting. Each one has to be identifiable by ear, which is a stricter requirement than being individually pronounceable.

Two practical rules. Vary the stressed syllable and the vowel shape across the family rather than only the consonants, because consonants are what get lost on a phone call. And avoid names that differ by a single sound in the same position — those are not two names, they are one name with a coin flip.

The individual tests still apply to each name: a stranger should be able to say it from the spelling and spell it from the sound. What makes an invented name easy to say and spell covers those, and in a portfolio the failures compound rather than adding up.

Decide the domain architecture before you need it

Products can live on paths, on subdomains, or on their own domains, and the choice should follow the brand structure rather than whatever was available on the afternoon of the second launch.

Two things worth deciding early rather than discovering. Whether a product needs its own domain is a question about audience, not about whether the domain happens to be free. And every separate domain is a permanent operating cost plus a place where your brand can drift — which is why the default should be paths, and each exception should have a reason somebody wrote down.

If a product does earn its own domain, it earns the whole naming process too, including the availability constraint. Reserve the obvious ones early, while the pattern still has room: it is much cheaper than discovering at launch four that your naming system produces names whose domains are all gone.

Do not brand every feature

Every branded term is a word customers have to learn, and the budget for that is much smaller than it feels from inside the company. A portfolio of nine proper nouns is a vocabulary test attached to a product.

The test for whether something deserves a name: does a customer need to refer to this independently — in a purchase decision, a support request, or a conversation with a colleague? If it is only ever encountered inside the product, describe it and move on.

Reversing this later is possible and unpleasant, because retiring a name you taught people is a small rebrand each time. Adding names later is easy; removing them is not.

Research conflicts at both levels

A clear parent brand does not make every sub-brand clear. Each product name that customers will encounter independently needs its own search: existing companies and products, app stores, and the trademark registers for the classes and markets it will trade in.

This is where a naming pattern can create a specific hazard. A system that reliably generates one kind of word will reliably generate collisions with everybody else using the same convention, and the fifth product in a themed family is the most likely to land on something taken. How to check whether a name is already being used covers the searches.

Write it down

A system that lives in one person's head is not a system. Two pages is enough, and it should be specific enough that somebody who was not in these conversations can name the next product without asking.

The last two matter more than they look. A documented decision-maker is what stops the argument recurring, and a required research step is what stops a launch discovering a conflict in its final week.

Expect to revise it once

A naming system written before the second product is a hypothesis. Around the fourth or fifth, you will find that the pattern is tighter than it needed to be, or that two names are being confused, or that a branded feature should never have been branded.

Revise the rules then, deliberately, rather than quietly making exceptions to them. A system with three documented amendments is still a system; a system with three undocumented exceptions is back to improvising, and nobody will be able to tell which of the two you have.