This article walks you through a proven method for developing a sound, product categorisation framework to help potential customers make sense of your product suite. It also compares the naming schemes employed by Amazon, Google and Microsoft to illustrate some of the recommended frameworks in action.

Nothing is more subjective than picking a name — whether it be for a baby, a pet, a band or a new software feature. When it comes to naming a product, there’s a tension between striving for that elusive sense of ‘coolness’, and the desire to achieve clarity and consistency.

If you’re part of a cross-functional team, where every stakeholder has equal accountability for how that product performs, a product name can be a difficult thing to negotiate. Developers favour mythic, epic or supernatural themes. Product Managers want to communicate the product function. Marketing wants a naming scheme that’s consistent and accessible to the end customer. How do you lead this diverse set of stakeholders toward the best outcome for the business?

This article outlines key factors to consider before naming a new product. It guides the reader through two sample categorisation frameworks that bring consistency and logic to multi-product platforms, and compares the naming schemes employed by Amazon, Google and Microsoft to illustrate these frameworks in action.

Key Concepts

• Entry point: the environment in which people first discover your product — and how they arrive there;
• Product categorisation: a way of grouping products and features by theme, function or use case;
• Trade-offs: what you’re giving up, depending on how you decide to name your product.

Entry Points: How do Customers Discover Your Product?

An entry point is the place where a user is exposed to your product for the first time. Listing the discovery channels for your product gives you and your team the opportunity to reflect on how much space and time your product has to make an impression, communicate function and drive consideration at the point of discovery.

For example, common entry points for a digital or software product include:

• The user interface (UI) of your existing platform. This is usually the first environment where existing customers will be exposed to a new product — whether through a recommendation engine, notification or navigation update to the platform’s UI;
• A search engine: a potential customer searches a term related to your brand and your product appears in the search results;
• First or Third Party Content: a potential customer reads a review, explainer or tutorial about your product;
• Email: an existing customer gets a marketing email from you promoting your new product launch, opens, reads and clicks out;
• Social: an existing or potential customer is exposed to a product launch announcement post via your owned social channels (or via others who have amplified your post);
• Word of mouth: a product is recommended to a potential customer by family, friends or colleagues.

Each one of these entry points is an opportunity to sell your product. Many of them — social, email and search — restrict the amount of text you can use to communicate with, and facilitate lightning fast scrolling or clicking. That means your marketing window is incredibly short.

Text is limited, duration is limited, and the target customer will make their decision to click, or not to click, in a matter of seconds. There’s quite literally very little time and space to convince a potential customer, at the point of discovery, to catch the eye, convince the person that your product is relevant and persuade them to click or engage.

Picture your product name in this environment. Does it communicate its function and value in a matter of seconds? Could a potential customer scrolling through search results see yours, and understand what your product is and does in that moment?

Things like word of mouth or referral traffic from other sources are harder to influence, but the principles of clarity still apply here. How easy would it be for someone, without an intimate knowledge of your product, to describe it and explain its benefits to someone else?

Cool vs Clarity: Important Trade-offs to Consider

Is it better to be clear and literal, or intriguing and memorable? Can you do both? Does it matter if you’re memorable, as long as you’re clear? No matter which approach you choose, there are trade-offs to be made:

If the name is more unexpected, cool, vague and unrelated to the product function, it may be more sticky in the mind of the consumer and increase your chances of achieving a level of virality or word of mouth. On the other hand, virality is elusive and unpredictable.

This aside, if the name significantly obscures the product function, will that make it harder to sell? Will you need more time and more characters to pitch to potential customers, at a higher frequency to achieve salience? Will it be difficult for you to achieve visibility on relevant, competitive search terms?

If a product name is so distinct from the master brand, should it have its own? How important is it for users to feel that they’re interacting with ‘Your Brand’, no matter which product they’re using?

Useful Categorisation Frameworks for Multi Product Offerings

The answer to these questions are: “it depends”. Personally, I’m a fan of literal product naming. That’s because I’m the custodian of Customer Voice for my products. I want every user interaction with my products to be frictionless, to be joyous — and most of all, to be clear.

I want to ensure that it’s as easy as possible for a potential customer to discover, use, comprehend the benefit and buy. For that reason, I like our customers to know that they’re always interacting with our brand, no matter which product or feature they’re using. And I like our products and features to reference the product function, or Job To Be Done, as closely as possible.

When you cross the threshold from ‘single product platform’ into ‘multi product platform’, the challenge becomes more complex. You have a platform, hero products, their associated features and add-ons. All of them need to make sense together to the end user. They need to be easy and logical to comprehend, browse, activate and buy. Having your team agree on a categorisation or scheme can help you unify your products and maintain consistency.

Here are two examples you might find helpful.

Framework A

Products and features are grouped into ‘categories’ and adhere to a strict ‘Branded House’ model, where the masterbrand is carried through across all product names:

Masterbrand
Product Category 1
Product A
> free > 'Master brand' Standard
> paid > 'Master brand' Premium
> Feature A Product B
> free > 'Master brand' Standard
> paid > 'Master brand' Premium
> Feature B Product Category 2
Product C
> free > 'Master brand']Standard
> paid > 'Master brand' Premium
> Feature C

Framework B

Large brands with a large existing customer base and strong brand salience can afford to adopt a into a ‘House of Brands’ model, where each individual product has its own distinct brand:

Product A (brand A)
> free > 'Product A Standard'
> paid > 'Product A Premium'
> feature A Product B (brand B)
> free > 'Product B Standard'
> paid > 'Product B Premium'
> feature BProduct C (brand C)
> free > 'Product C Standard'
> paid > 'Product C Premium'
> feature C

Which categorisation framework is right for you? Let’s take a rapid-fire look at how some of the largest technology brands approach product naming.

Industry Comparisons

AWS can be inconsistent, routinely interchanging ‘AWS’ and ‘Amazon’ from one product to the next. But some product categories like ‘Developer Tools’ display a very rational approach. They employ names that closely reference the product function to make selection easier for the end user.

In contrast to AWS’ Developer Tools, Google takes a ‘House of Brands’ approach to its developer products. Where Android, TensorFlow, Firebase and Flutter each have distinct brands and contain little-to-no reference to the product function, YouTube, Cloud Platform, Maps Platform and Web are quite literal.

Within Google Cloud Platform, there is variation. GCP’s developer suite contains a range of products, with names that closely reference their product function. Yet, Anthos has been given a distinct name and brand. This may have been a deliberate attempt to differentiate this product from Kubernetes; a similar product in the Google family that is open source.

For Azure, Microsoft employs a strong ‘Branded House’ approach to product naming. Though Azure is technically a brand itself, the Microsoft brand is completely dominant. Every Azure product is very literally named, and is unmistakably Microsoft.

Leading your team through a product naming exercise to agree on a common product categorisation framework can help bring consistency and clarity to product naming and drive alignment among the engineers, product managers and product marketers tasked with making each new product a success story.