Why IKEA Names Its Bookcases After Men

Set the criteria before the names, and meetings get shorter

I’ve run plenty of workshops as part of GTM strategy work, deciding on product names, plan names, feature names. Even after everyone agreed on what a feature actually did, the meeting would drag on once it came time to pick a name. Adding more candidates didn’t make things wrap up any faster.

Pin 40 candidates to a whiteboard and ask which one is best, and the answers split along personal taste. So I changed the order: before collecting candidates, I got the group to agree on what kind of name we were even looking for. In one of my workshops, that shift narrowed 40 candidates down to 6, and we closed out the decision in 15 minutes.

Reading about IKEA’s product-naming rules brought this experience back to me. IKEA names roughly 2,000-3,000 new products every year. To handle that volume, they’ve settled in advance on categories of products and the word conditions each name has to meet.

The draft looks accurate and complete—no Hangul, no missing numbers, structure matches. Output as-is:

Men’s Names on the Bookshelf, Swedish Places on the Sofa

IKEA’s official explanation is that it uses Swedish-language names for its products. As examples, it cites Swedish place names for sofas, men’s names for bookshelves, and animal- and nature-related names for children’s products.

There are also conditions a name has to meet to become a product name.

• It must be a word that actually exists.
• It must be 4-12 characters long.
• Names containing Å, Ä, or Ö are preferred.
• It has to sound good when spoken.
• Names or surnames that are already trademarked should be avoided.

Here, “men’s names” are distinguished from surnames — they mean individual first names, like Billy. IKEA says it also checks whether a candidate name carries an unwanted meaning in another language, or an inappropriate political or religious connotation.

Services and features, on the other hand, get names that are easy to understand in each country’s own language. The idea is to embed Swedish identity into the products themselves, while prioritizing clear explanation wherever customers need to know how to actually use something. IKEA’s product naming rules

I think this distinction is genuinely useful in practice. Not every name needs to be original. A name meant to make a product memorable and a function name meant to tell you what happens when you press a button — these play different roles.

Once you’ve set your categories, you don’t suddenly find yourself, in the middle of debating bookshelf names, widening the search to nautical terminology or abstract emotional expressions. You still have to hunt for and vet good candidates, but the range of options you’re choosing from is smaller than if you started by considering every word in the language.

The same feature can end up with many different names

Even in studies of how developers name variables and functions, people’s choices rarely line up. Dror Feitelson’s team ran a series of experiments involving 334 participants in total. Across the 47 naming scenarios in the first experiment, the median probability that two people picked the same name was just 6.9%. That figure comes from a specific experimental setup, not a universal agreement rate across all dev teams. How Developers Choose Names

The research team breaks naming down into three separate choices: which concept to capture, which word to express that concept with, and how to combine the words. Even when two people understand a function identically, if they emphasize different concepts or reach for different words, they can still land on different names.

Proposing a different name doesn’t necessarily mean someone misunderstood the feature. Conversely, using the same name doesn’t guarantee everyone means the same thing by it. That’s why I think it’s worth agreeing on what information a name needs to convey before putting candidate names to a vote.

A pricing-tier name, for instance, needs to signal the difference between tiers; a feature name needs to convey what the user can actually do with it. An internal project codename just needs to let the team tell things apart from one another. There’s no reason to judge all three by the same standard.

Kimi’s pricing tiers are named after musical terms

A case that recently caught my eye was Moonshot AI’s Kimi pricing plans. Even in the Korean help documentation, the names appear untranslated, in the original alphabet.

Plan	Monthly billing price
Moderato	$19
Allegretto	$39
Allegro	$99
Vivace	$199

These figures are distinct from the monthly-equivalent price under annual billing. Kimi pricing guide

These names are Italian terms used in sheet music to indicate tempo or character of performance. I liked that the tiers were grouped using words from the same family. Anyone familiar with tempo markings can recognize the progression from a moderate pace to a faster one.

That said, not every customer knows musical terminology. It’s hard to argue that the names alone can substitute for a description of what each tier offers. For someone encountering these plans for the first time, you still need to show price, usage limits, and feature differences side by side. It’s worth separately verifying whether names I find familiar to read are actually familiar to customers.

Sound matters too. Allegretto and Allegro share the same opening syllables. You can tell them apart when reading side by side on a screen, but in a phone consultation or verbal explanation, they could be confused. How much confusion actually occurs is something you’d need to check with real users.

There are other musical terms available, so there’s room to add more tiers under this naming scheme. But how a new tier would be understood by existing customers isn’t something the name alone resolves. In this case, I saw both the benefit of a unified naming rule and the explanation customers still need.

When you make a rule, plan for additions and replacements too

Even a solid naming rule can run into trouble as scale grows or usage patterns shift. The World Meteorological Organization’s (WMO) naming system for Atlantic tropical storms is a case in point.

In 2005 and 2020, when the main list of names ran out, the WMO turned to the Greek alphabet for extra names. But in March 2021, the committee scrapped this approach. The Greek letters themselves ended up drawing more attention than the storm warnings did, switching languages mid-list caused confusion, and similar-sounding names like Zeta, Eta, and Theta could exist as active storms at the same time.

There was also no procedure in place for what to do when a Greek-lettered storm caused major damage and its name needed to be retired. The committee retired Eta and Iota, and created a supplementary list that would allow individual names to be swapped out. This wasn’t about erasing the Greek alphabet from the world — it was about needing a way to remove a problem name from the naming system and slot in the next one. WMO’s 2021 decision

In 2019, Google switched Android’s public version names from desserts to numbers. The reasons it gave: some languages don’t distinguish well between the sounds “L” and “R,” and if you’re not familiar with dessert names, it’s hard to tell which version comes after which. The next version was simply called Android 10. Google’s explanation of the name change

Both cases show that it’s not enough for names to merely follow internal rules. You also need to ask: are they distinguishable from one another, can new names be added, and can a problem name be replaced?

Some names are better left unchanged

There are also cases where changing a name creates problems of its own. Unicode follows a policy of never changing the official name it has assigned to a character. That’s because existing software uses that name as an identifier. Even if a name has a typo, Unicode adds a corrective alias rather than deleting the original name. Unicode Stability Policy

I don’t think we should read this as a case of naming failure followed by total paralysis. It’s a choice that prioritizes compatibility with programs and data already in use over the convenience of fixing an error.

Product names can run into a similar problem. Changing the name shown on screen looks easy, but the old name lingers in contracts, invoices, help documents, and customers’ search histories. If the name is also used as an API name that developers rely on, the scope of the fix can grow even larger.

So it helps to distinguish, when naming something, what can be changed and what should stay fixed. One approach is to let the display name shown to customers change, while keeping the internal value that identifies the target stable. You also need to decide how to guide people who come looking under the old name after it’s been changed.

Oswarld’s Lens

The meetings in my workshop got shorter not because a more brilliant candidate suddenly appeared, but because we agreed on the evaluation criteria first. Instead of each person trying to sell their own taste, we could compare whether a given name fit the role and conditions we’d already set.

When I make rules, I try to settle the following first.

What to decide first	Sample question
Who uses it, and where	Is this customer-facing, or for internal meetings?
What information the name should convey	Function, tier, or brand character?
What expressions are allowed	A descriptive word, or a name drawn from a particular theme?
How to distinguish it	Is it distinct from other names even when spoken aloud?
How to change it	If a name is added or retired, how do we notify existing customers?

You can’t apply the rules for naming a function directly to a meeting about picking a brand name. Nor do you need to carry over the convention of naming bookshelves after men when naming a pricing plan. What’s worth borrowing is the practice of agreeing on conditions first to narrow the range of choices.

In a previous issue, when I discussed URLs, I wrote that you should be careful about putting information that’s likely to change into an address meant to last a long time. Names are similar. Once you think about where a name will be used and for how long, certain candidates get eliminated from the start.

Even if AI generates plenty of candidates, this decision still remains ours. Before asking which word sounds cooler, we have to decide what our customers should understand the moment they see the name. We can ask AI to generate candidates that fit those conditions, and to flag names that sound too similar to existing ones or expressions that are hard to explain. Trademark issues and meanings in other languages still need to be checked separately.

Pick 3 things your team, Reader, names often. It helps to jot down, in one line each, what role the name needs to play and what kind of expression is allowed. That short set of criteria may prove more useful in your next meeting than any list of candidates.

💬 Was there a product name or pricing-plan name that was especially easy to understand? Conversely, do you have a story about a name that became too widely used to change?

References & Further Reading

• IKEA’s product naming rules.
• Feitelson et al., How Developers Choose Names.
• Kimi membership pricing guide.
• WMO’s decision to retire the Greek alphabet, March 17, 2021.
• Google’s explanation of Android 10 naming, August 22, 2019.
• Unicode’s name stability policy.

Worth reading alongside this issue

• The problem with designing URLs and links meant to last
• The gap between people who build AI products and people who use them

The author is Oswarld (Kwangseob Ahn). Current roles: Adjunct Professor at Sejong University, Strategy Consultant at INLEVEL9. Career, research, books, and recent work are kept current on the About page. Latest · July 2026: HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI.