Every product you ship either borrows a name's meaning or starts earning its own. This chapter is the ledger for that decision — from P&G's firewall of brands to the tech industry's naming chaos.
Here's the whole chapter in one line: a brand name is stored meaning, and every launch either draws on an existing account or opens a new one — both are loans, and both charge interest. Everything below is the bookkeeping.
Sooner or later every company that ships more than one thing faces the same question: does the new thing carry the name we already have, or a name of its own? Put one name across everything and every launch deposits into — and withdraws from — a single account of meaning. Keep a stable of names and each one earns slowly, alone, but a failure in one can't reach the others.
This is the most expensive naming decision a company makes, and here is the strange part: it's usually made by accident. Nobody convenes a meeting titled "what is our brand architecture?" Instead, a product team needs a name by Thursday, borrows the big one because it's free, and ships. Then another team does. Ten launches later the company has an architecture — the way a city that never zoned anything has a skyline.
Programmer's version: your brand portfolio is a public namespace, and without a review process, every team mints symbols into it. No single commit looks wrong. The mess is only visible in aggregate, years later, when nobody — including your customers — can say what the main name refers to anymore.
So this chapter treats the question the way an architect would: what are the possible structures, what does each cost, when does borrowing a name genuinely pay, and what happens when you delete one. The running theme from Chapter 6 comes back load-bearing: names are memory keys, and the ledger is written in recall.
David Aaker gave the options their standard names, and they sit on a spectrum from one name everywhere to a name per product:
Programmer's version: branded house is a monorepo, house of brands is microservices. The monorepo gives you shared equity, one deploy pipeline, and one blast radius — a scandal in any division ships to all of them. Microservices give you failure isolation and independent scaling, and in exchange every service pays its own infrastructure bill: separate awareness, separate ad budgets, separate memory keys built from zero.
When does each win? Share the name when the products share a promise and the buyers overlap — the deposit compounds. Separate the names when the promises differ, when a failure in one product must not infect the rest, or when price tiers sit far enough apart that one name can't credibly span them. A luxury badge on a discount line doesn't lift the discount line; it re-prices the badge.
Walk the tree yourself — four questions is all it takes.
Chapter 1 flagged line extension as a trap. Now, with the architecture lens, we can do the actual accounting. An extension borrows equity: the new product launches with instant awareness, instant distribution leverage, instant trust — none of which it earned. Cheap and fast. It is also, precisely, a loan taken out against the masterbrand's meaning, and the collateral is the thing that made the name valuable: what it stands for.
Sometimes the loan is genuinely right. The test is the one Chapter 4 gave us for any strategy decision, applied to the name: same job, same promise, same buyers. A premium coffee brand selling espresso machines is still hiring for the same job (great coffee at home), making the same promise (craft, quality), to the same people. The name doesn't stretch — it points at more evidence for the same claim. That extension strengthens the key.
The trap is the other case: a different job wearing a familiar name. The same coffee brand launching an energy drink is asking one word to mean craft ritual and caffeine delivery — Chapter 1's hook, bent toward two different shelves. Each individual extension looks reasonable in its launch deck. The blur only shows up in aggregate, later, in someone else's quarter.
Programmer's version: every extension adds an overload to the name. One or two overloads with the same signature — fine, the compiler and the customer both resolve them. Overloads with different semantics under one symbol is how codebases and brands alike become unreadable.
Before a name can be architected, it has to function. Four properties do almost all the work:
These four push in the same direction, and it's the direction intuition resists: an empty vessel beats a descriptive label. A coined word — Kodak, Xerox, Accenture, Häagen-Dazs (invented in a Bronx kitchen to sound Danish) — starts with zero meaning, which feels like a marketing burden. But zero meaning is ownable meaning: everything the name comes to stand for, you put there, and the law and the search index both protect it. A descriptive name saves you one year of explanation and costs you every year after that.
Programmer's version: a name is a primary key. You want it unique, stable, and meaningless-by-default — semantic keys feel convenient right up until the semantics change. And a descriptive name is a reserved word used as an identifier: legal in some contexts, a collision generator forever.
Chapter 6 called the Tropicana redesign a cache flush: delete the visual keys, and shoppers' lookups come back empty. A rename is that, made structural. The name is the primary key every other memory key resolves through — decades of ads, mentions, recommendations, and habits are indexed under it. Rename, and you delete the index. A rename is a breaking API change for human memory — and unlike an API, you can't force your callers to upgrade. They just stop calling.
So when is the flush rational? Three cases survive scrutiny. A genuine pivot: the company became something the old name actively misdescribes — though note that Google's 2015 restructuring got this right by inverting it: Alphabet is a holding wrapper that left the Google key, where all the equity lived, completely untouched. Toxic equity: the name now retrieves something you need it not to. M&A dedup: two names, one company, and carrying both means paying rent on two memory keys forever — Accenture is the canon case of doing this under duress and with discipline, and we'll meet it in the card below.
And then there's the case every rebrand deck now argues against. In 2023, Twitter became X: a name that was a global verb — the strongest kind of memory key a brand can hold, one that fires without the brand even present — deleted overnight, product unchanged, no migration period. Whatever the strategic intent, as brand accounting it was unambiguous: equity destruction as a choice. Years later, news outlets still write "X, formerly Twitter" — the market forcing the co-brand the company skipped.
If the architectures are so well understood, why is the tech industry — the richest, most instrumented industry in history — so bad at this? Because architecture isn't decided; it decays. Every team ships a name the way every team ships a service, and nobody owns the namespace.
The canon example is Google's messaging portfolio: Talk, Hangouts, Allo, Duo, Meet, Chat — four-plus apps for one job, launched, renamed, merged, and killed in overlapping waves, until "which one do I use to call you?" became a genuine research question. Each name made sense in its launch meeting. The portfolio, assembled one reasonable decision at a time, was a puzzle no user asked to solve.
The current rerun is happening around AI: one model name stretched across a chatbot, an IDE plug-in, a browser sidebar, a phone assistant, and a page of cloud SKUs with version-suffixed variants. One word, asked to mean a model, a product, a feature, and a platform at once — Chapter 1's blurred hook, at industrial scale. When everything is called the same thing, the name stops routing anyone anywhere.
The counterexample sits one campus over. Apple runs a tight naming grammar: a handful of master keys (Mac, iPhone, iPad, AirPods, Watch) plus a tiny set of shared descriptors (Air, Pro, Max, mini). New products don't get new names; they get composed from the grammar. Buyers can parse a product they've never seen — iPad mini is self-describing to anyone who knows the system — and the portfolio stays legible across hundreds of SKUs.
The lesson is unglamorous: governance beats taste. A mediocre naming system enforced beats brilliant names minted ad hoc, for the same reason a mediocre style guide enforced beats a repo full of beautiful, inconsistent code. The architecture never fails in a single launch. It fails one launch at a time, and only a standing review — someone empowered to say "this doesn't get the master name" — stops the decay.
Time for the honest audit. Brand architecture generates strong opinions and glossy frameworks — what does the data actually support?
Extensions: the ~50% base rate is real, and fit predicts the flips. The experimental literature that began with Aaker & Keller has been replicated across markets: extension evaluations rise with perceived fit between the parent's promise and the new product, and crash when the parent's associations are contradicted. Field studies of launch survival tell the same story from the other end. The Chapter 4 test — same job, same promise, same buyers — is the practitioner's version of the variable the models keep finding.
Equity transfer is measurable. Chapter 6's methods extend to names: show buyers the name (or the endorsement lockup) and measure attribution and recall, before and after. Endorsed launches measurably inherit trust from the parent's key; the same instruments detect the reverse flow — when a bad extension starts contaminating what the parent name retrieves.
Renames dip long, and discipline is what predicts recovery. The case-study pattern is consistent: after a rename, search volume, direct traffic, and unaided recall drop — and stay depressed far longer than launch decks assume, often years. What separates the recoveries isn't budget; it's migration engineering: redirects that preserve the old key's routes, a real co-branding period ("NewName, formerly OldName"), and retention of the non-name assets — colors, shapes, sounds — so the cache is flushed one key at a time, never all at once.
Part II closes here, so let's compress the chapter into the artifact you'd actually use — three checklists, run in order.
1 · Choose the architecture. Walk the four questions from the chooser: Same buyers? Same promise? Is failure contagion tolerable — can a crisis in the new thing be allowed to reach the old? Do the price tiers collide? All-shared walks you to a branded house; each split walks you one step toward firewalls — sub-brand, then endorsed, then a separate name that never mentions the parent.
2 · Test the extension. If the plan borrows an existing name: same job, same promise, same buyers — all three, not two of three. Two of three is exactly the profile of the coin flips that land wrong. And write down what the loan is secured against: which meaning of the masterbrand this launch puts at risk, and who is watching that number.
3 · Clear the name. New name or old, it must be distinctive (attributable to you alone), legally ownable (mind the trademark cliff), sayable, and retrievable — unique in a search box and stable in an AI's answer. And if the decision is a rename: no flush without a migration plan. Redirects, a co-brand period measured in years, and the non-name assets kept alive to carry recognition across the gap.
That's the strategy part of the atlas: minds (Part I), and the structures you build in them (Part II). Part III changes the register — from architecture to craft. Next: the six levers of persuasion, and what the feed did to them.