By Mehdi HassanHow should a SaaS company name its products and features?
A SaaS company should name its products and features with a clear hierarchy: a strong company name at the top, named products only where buyers purchase them separately, plans named by audience or scale, and features named by what they do. Most naming problems in SaaS come from naming too many things, not from naming them badly.
Once the company name is settled, which we cover in our hub on how to name a startup, product naming becomes an ongoing job. Every launch, plan change and new feature raises the question again. Without a framework, each team names its own work, and within a couple of years the pricing page, the product menus and the help center all use different words for the same things.
This guide gives you that framework: a naming architecture, rules for each tier, and a simple test for when a feature deserves a name of its own.
What is a product naming architecture?
A product naming architecture is the set of rules that decides how every product, plan and feature is named, and how those names relate to the company brand. It answers which things get their own name, which use the company name, and which are simply described. Brand strategists usually group architectures into three models.
Model | How it works | Well-known pattern | Fits SaaS when |
|---|---|---|---|
Branded house | Company name plus a descriptor for everything | Google Docs, Google Sheets | One brand, many related products; the default for startups |
Endorsed | Distinct product names backed by the company name | Product name by Company | Acquired products or distinct audiences |
House of brands | Separate brands with little visible link | Large consumer goods portfolios | Rarely; too expensive for most startups |
For almost every startup, the branded house is the right starting point. You're building one brand's recognition, so every product name should borrow strength from it rather than compete with it. Our guide to SaaS branding covers how that company brand is built in the first place.
Which tiers of a SaaS product need names?
A SaaS product has four naming tiers: the company, the products, the plans and the features. Each tier has a different job and a different naming style. Mixing the styles, for example giving a minor feature a flashier name than a whole product, is what makes a product feel incoherent.
Tier | Naming style | The test before naming it |
|---|---|---|
Company | Distinctive, ownable brand name | Can you own and protect it? |
Products | Company name plus a clear descriptor, or a distinct name if sold separately | Do buyers purchase it on its own? |
Plans | Audience or scale words | Does a buyer instantly know which plan is theirs? |
Features | Plain description by default | Will you market it on its own, and is it unique? |
Settings and UI labels | Always plain | Would a new user understand it with no explanation? |
The higher the tier, the more distinctive the name can be. The lower the tier, the more the name should simply describe. If you want a refresher on the trade-off between descriptive and distinctive names, see our guide to the types of brand names.
How should you name SaaS plans?
Name SaaS plans so a buyer can find their plan in seconds, usually by audience (Starter, Team, Business, Enterprise) or by scale. Creative plan names, such as metals, animals or space terms, make buyers stop and decode the ladder, which slows down the decision on your most important page.
- Show the order. Plan names should make the ladder obvious. If you need to read the prices to know which plan is bigger, the names have failed.
- Name for the buyer. Team and Business tell people who the plan is for. Pro and Plus only tell them it's more.
- Keep the free tier honest. Call a free plan Free. Calling it something else makes people wonder what the catch is.
- Match the UI. The plan name in the billing screen, the upgrade prompt and the invoice should match the pricing page exactly.
- Change rarely. Renaming plans confuses existing customers and breaks help docs. Get it right before launch.
Plan names also need to match how sales talks about them. If your sales deck calls the top plan something different from the pricing page, buyers notice. That's one of the most common consistency gaps we see, and it's covered more broadly in our guide to brand consistency.
When should a feature get its own name?
A feature should get its own branded name only when it's a genuine differentiator that you'll market on its own, that buyers will talk about by name, and that will last. Everything else should be described plainly. Each branded name is a small marketing cost: it has to be explained, supported in docs and kept consistent everywhere.
Is it unique?
If competitors offer the same thing, a branded name just hides a common feature behind jargon. Describe it instead.
Will you market it on its own?
If it will have its own launch, feature page or campaign, a name can help. A SaaS feature page for it is a good signal it deserves one.
Will customers say it out loud?
Names that sales, support and customers will actually use earn their place. Names only marketing uses don't.
Will it last?
Experimental or short-lived features should never get branded names. Renaming or retiring them leaves dead words in docs and decks.
Does it pass the plain test?
Even with a name, the feature needs a plain descriptor next to it in the UI, such as a branded name followed by what it does.
If a feature passes all five, name it in a style that fits the company brand, usually suggestive and short, and add it to your naming registry. If it fails any of them, describe it: Bulk export, Shared inboxes, Approval rules. Plain names are easier to find in menus, in search and in your help center.
How should you name AI features?
Name AI features by what they do for the user, not by the fact that they use AI. Labels like AI Assistant, AI Writer and Smart Insights tell users almost nothing and are identical to everyone else's. As more of your product uses AI, a separate AI label on every feature also stops meaning anything.
A better pattern is a plain action name, such as Draft reply, Summarize thread or Suggest categories, with any AI disclosure handled in the interface itself. If you have one flagship AI capability that genuinely sets you apart, that's the one candidate for a branded name. Our guide on how to add AI to a SaaS product covers the product side of that decision.
How do you keep product names consistent across your pricing page and UI?
You keep product names consistent by keeping a single naming registry: one shared document listing every product, plan and named feature, with its exact spelling, capitalization, a one-line description and where it's used. Every new name is added there before it ships, and the pricing page, product UI, docs and decks all follow it.
What a naming registry entry should include
For each name, record the exact name and capitalization, the tier it belongs to, a one-sentence plain description, the words it replaces or should never be confused with, who owns it, and where it appears: pricing page, product UI, help docs, sales deck and emails.
Add a short rules section at the top: when a feature can be named, which naming style to use, and who approves new names. For example, suppose a product manager wants to call a new filter feature something clever. The registry rule says features are described unless they pass the five-question test, so it ships as Saved filters. Keep the registry next to your brand guidelines and design system so designers and writers use it daily.
The registry matters most for complex products, where buyers already have a lot to learn. Our guide to branding complex products goes further into making dense products feel simple, and naming is one of the cheapest ways to get there. Names also shape how buyers place you in a market, which links naming to product category positioning.
When should you rename a product or feature?
Rename a product or feature when the current name actively confuses buyers, conflicts with a trademark, or no longer fits what the thing does. Don't rename because the name has become boring to your team. Customers learn names slowly, and every rename resets that learning and leaves old names scattered across docs, videos and integrations.
When you do rename, do it as a batch: update the registry first, then the product UI, pricing page, help center, sales materials and emails together, and keep the old name searchable in your docs for a while so existing customers can find it. A planned naming cleanup alongside a pricing change or brand refresh is far less disruptive than a string of individual renames.
