# Feature naming and product nomenclature > Rules for naming features, tiers and modules so a multi product SaaS stays legible, plus the nomenclature system and the rename migration checklist. Source: https://saas-marketing.net/guides/feature-naming-and-nomenclature/ Topic: SaaS Branding Type: guide Published: 2026-09-11 Last updated: 2026-09-11 Publisher: SaaS Marketing (saas-marketing.net) License: CC BY 4.0. Quote or republish with attribution and a link to https://saas-marketing.net/guides/feature-naming-and-nomenclature/ ## Short answer Feature naming works best on a three tier nomenclature: the company name, a small number of product names, and feature names that describe rather than brand. A feature earns a capital letter only when it is separately purchasable, separately documented, or has a competitor set of its own. Descriptive names inherit existing category search demand, while invented names require paid education. Every branded name added is a permanent tax on docs, support and sales. ## Key takeaways - Capitalise nothing you would not put on a price sheet. That single rule prevents most nomenclature rot. - Descriptive feature names inherit category search volume; invented names start at zero and need paid education. - Every branded name adds permanent cost to docs, onboarding, support macros and sales training. - Invented tier names raise support contacts because customers cannot tell which tier is higher. - A rename touches at least fourteen surfaces, and in-app strings are the ones teams forget. - Atlassian, HubSpot and Salesforce each solved the multi product naming problem differently, with different costs. --- Open your own product and count the capitalised nouns in the left navigation. Then count how many of them appear on your pricing page. In most SaaS companies past Series B the first number is three or four times the second, and every one of those extra proper nouns is a word customers have to learn for no commercial return. That gap is the whole subject of this page. ## The three tier nomenclature model There are exactly three levels a customer should ever have to hold in their head: the company, the products, and the features. Everything else is internal. **Company name.** One. Stable. It does not change without a board conversation. **Product names.** Few, and each one earns its place by being separately purchasable, separately marketed, and separately staffed. Atlassian runs Jira, Confluence and a small handful more. Each has its own pricing, its own competitor set and its own documentation tree. That is what a product name is for. **Feature names.** Descriptive by default. Lower case in prose. "The approval workflow", "custom fields", "the activity log". These are not weaker than invented names, they are cheaper, and they arrive pre-loaded with the meaning the buyer already has. The rule that enforces all of this fits on one line: capitalise nothing you would not put on a price sheet. If it does not have a price, a competitor set or a docs tree of its own, it is a description, and it gets a lower case letter. Nobody decides to have forty branded features. What happens is that engineering ships a project called Lighthouse, the codename appears in the release notes because nobody supplied a better word, marketing writes a launch post using it, and eighteen months later it is in the navigation, in three hundred support tickets and in the API. The name was never chosen. It was just never removed. ## A decision tree for when a feature earns a capital letter Run each proposed name through these four gates. It has to pass at least one. **The capital letter test** The second gate is the one people underuse. Notion AI is a good branded name precisely because buyers are shopping for AI features across tools and a name makes it findable and comparable. A branded name for your export dialogue would be absurd for exactly the opposite reason. ## Tier naming, and the real cost of cute plan names Pricing tiers are where naming decisions become measurable fastest, because you can watch the pricing page. Invented tier names fail in a specific and predictable way. A prospect lands on your pricing page with a comparison tab open, needs to know within four seconds which plan is more expensive than which, and cannot tell whether Forge outranks Atlas. Support then absorbs the confusion forever, because every upgrade conversation starts with a translation step. There is a related trap on the [feature gating](/glossary/feature-gating/) side: if your tier names are opaque and your gated features are branded, a customer reading "Sentinel is available on Atlas and above" has to decode two invented words to answer one question. Pick plain on at least one axis. ## Naming and search demand, which is the part most brand teams ignore A descriptive feature name inherits the search volume of the category it describes. An invented one starts at zero and stays there until you pay to teach the market the word. This is not an argument against ever branding. It is an argument for knowing the bill. If you name a capability "approval workflows", people searching for approval workflow software can find your page. If you name it Sentinel, the only people who will ever search that word are customers who already have it, and you have converted a demand capture asset into a support page. **0** Monthly search volume an invented feature name has on the day you launch it, and usually for a long while after The practical compromise most mature products use: brand the product, describe the features, and write page titles that carry both. "Sentinel: approval workflows for regulated teams" does the branding work in the H1 and the demand capture work in the same line. That pattern sits underneath most of what is covered in [SaaS brand architecture](/guides/saas-brand-architecture/), and the earlier decisions about company and product level naming are in [SaaS product and company naming](/guides/saas-product-naming/). ## Four systems, four different bills Worth studying these side by side, because each traded something away deliberately. **Atlassian** keeps strong, memorable product names and describes features plainly inside them. The cost is that the products feel like separate companies, which is why cross-sell needed a bundle name to sit above them. **HubSpot Hubs** groups by buyer function: Marketing Hub, Sales Hub, Service Hub. The naming is almost entirely descriptive with one branded suffix doing the work of holding the system together. It scales cleanly, and a new function becomes a new Hub without a naming debate. The cost is that "Hub" carries no meaning to a first-time visitor and has to be explained. **Salesforce Clouds** did the same trick earlier and then kept adding, and the result is a taxonomy that insiders navigate fluently and outsiders find genuinely hard. This is the endpoint of a system with no removal mechanism. **Notion** brands almost nothing, with Notion AI as the notable exception. Databases, pages, blocks: all lower case, all described. The cost is that nothing in the product has a name you can shout about. The benefit is that a new user can guess what everything does. Take a new hire in sales on day three and ask them to explain your product hierarchy to a customer without notes. If they cannot, the nomenclature is broken regardless of how elegant it looked in the brand deck. Prospects get less context and less time than that new hire. ## Writing the policy so it survives the next launch A nomenclature policy is one page and needs four things: the three tier model, the capital letter test, a named approver, and a rule that launch copy cannot ship without the name being approved. Fold the approval step into your [product launch playbook](/playbooks/b2b-saas-product-launch/) so it happens at brief time rather than the week of launch, when nobody will accept a change. The approver matters more than the policy. Policies without an owner get ignored at exactly the moment they are needed, which is the Thursday before a launch when the name is already in the deck the CEO has seen. Give one person in product marketing a veto and make it known. Tie it to your [launch tiering](/playbooks/saas-feature-launch-tiers/) so a tier three feature never gets a branded name by accident, and add the name approval line to the [product launch checklist](/checklists/saas-product-launch-checklist/) where it will be seen. Use a written brief for anything you do decide to brand. The [naming brief and scorecard](/templates/saas-naming-brief/) exists so the debate happens against criteria rather than against taste, which is the difference between a forty minute decision and a three week one. ## The rename migration checklist Sometimes you inherit a bad name and it has to go. Renaming is not a copy change, it is a coordinated migration, and the item teams forget is in-app strings. **Rename migration, run in this order** That last check is the honest failure mode. Internal teams keep using the old word for years, and every time a rep says it on a call the customer learns that the rename did not really happen. Renames are expensive and they are never fully complete, which is the strongest argument for getting the name right the first time. ## What to do next Run the capital letter test against every proper noun in your product navigation this week. Most teams find two or three that fail all four gates. Demote them to lower case descriptions in documentation first, which costs nothing and reveals whether anyone actually cared about the name. Then write the one page policy and name the approver, before the next launch adds another one. The rest of the system sits inside your broader [SaaS branding](/saas-branding/) work, but this is the piece that decays fastest if nobody is holding the line. ## Frequently asked questions ### When should a software feature get its own brand name? When it is separately purchasable, has its own competitor set, or is substantial enough to carry its own documentation tree and pricing line. If none of those are true, describe it instead. A branded name for a feature that ships inside every plan creates a word your customers have to learn for no commercial return. ### Are descriptive feature names bad for differentiation? No, and the fear is usually backwards. Buyers compare on capability, and a descriptive name lets them find you when they search for the capability. Differentiation comes from what the feature does and how well, not from the noun on the button. Save the invented names for the small number of things you want people to ask for by name. ### Should SaaS pricing tiers have invented names? Almost never. Free, Pro, Business and Enterprise are boring and instantly legible, which is exactly what a pricing page needs. Invented tier names force every prospect and support agent to learn an internal ordering, and the cost shows up as pricing page drop-off and repeated 'which plan am I on' tickets. ### How do you name features in a multi product SaaS? Use three levels: company, product, feature. Keep product names few and stable, since each one carries a website section, a pricing line and a sales motion. Name features descriptively inside each product. HubSpot's Hubs and Salesforce's Clouds are product-level names, and both companies still describe most features in plain language underneath. ### What does renaming a feature actually cost? More than teams estimate. A rename touches in-app strings, documentation, help centre articles, the changelog, sales decks, onboarding emails, support macros, API field names, pricing page copy, and any URLs that need redirecting. For a widely used feature, plan four to six weeks of coordinated work and expect a support volume bump for about a month. ### Should feature names be capitalised in documentation? Only branded ones. Write 'the reporting dashboard' in lower case and 'Notion AI' capitalised, and be consistent everywhere. Mixed capitalisation is the visible symptom of an unwritten nomenclature policy, and it makes a product sound like several companies wrote it, which is usually literally what happened. ### Who should own feature naming decisions? Product marketing, with a written policy and a named approver. Engineering should not name customer-facing features, because internal project codenames leak into the UI and become permanent. A one page policy plus a single approver catches the majority of bad names before launch at almost no process cost.