Feature Naming Is a GEO Decision
When you give a feature a name nobody prompts, you make that feature harder to cite for the exact question buyers ask. Feature naming has always been a positioning decision. It is now a discoverability decision too, and product managers own it.
This is the cleanest proof of the book's thesis, because naming is unambiguously a product decision. No marketing team renames a shipped feature on its own.
How engines connect a question to a product
A buyer types "which identity platforms support risk-based authentication for B2B apps." The engine does not search for your brand. It works out the underlying need, then looks for products that are clearly and repeatedly connected to that need across the sources it reads.
That second step is the important one. A Peec AI study of 37,804 responses across five engines found that brand mentions largely held when a prompt was reworded, as long as the rewording kept the same meaning (Peec AI). My reading: engines resolve prompts to needs, then retrieve the entities associated with those needs. Phrasing tricks matter less than whether your product is firmly attached to the need at all.
Your feature names are one of the strongest attachments you control. If the feature that does risk-based authentication is called "Adaptive Shield," and nothing on the page where it lives says "risk-based authentication," you are asking the engine to make the connection on faith. Some will, from third-party coverage. Many will not.
Four naming failures
Invented jargon with no bridge. The feature has a branded name and the functional term appears nowhere near it. This is the most common failure and the easiest to fix.
Legacy names left behind. A feature was renamed two years ago. The docs use the new name, the old blog posts and press releases use the old one, and review sites use whichever the reviewer remembered. The engine now sees two features, or one feature with conflicting descriptions.
Overloaded names. The same word means different things across product lines ("Connect" for SSO in one product and for data sync in another). Engines blend them.
Category invention without anchoring. A company coins a new category name and uses it instead of the existing one buyers search for. Until analysts, reviewers and competitors adopt the new term, engines have little evidence to connect it to anything. A new category name can be a strong long-term bet, but only if it is anchored to the category buyers already ask about.
The brand-plus-function rule
The fix is not to stop branding features. Brand names help with recall, pricing tiers and differentiation. The fix is a simple rule: every branded feature name travels with its functional description, everywhere it appears.
| Instead of | Write |
|---|---|
| Adaptive Shield | Adaptive Shield, our risk-based authentication |
| TrustBridge Connect | TrustBridge Connect (SAML and OIDC single sign-on) |
| Machine Pass | Machine Pass: workload identity using OAuth 2.0 client credentials |
| Insight Engine | Insight Engine, the anomaly detection layer for login events |
The functional half uses the words buyers use, including standard and protocol names. Put the pairing in the places engines weigh most: the page title and first line of the feature's docs page, the pricing page, the changelog entry that announced it, the product's structured data, and partner and marketplace listings.
The examples above are illustrative names, not real products. The pattern is what matters.
The naming map
For products with more than a handful of branded features, publish a naming map: a public page that lists each branded name next to the standard term and a one-sentence description. Think of it as a glossary for your own product.
It does three jobs. It gives engines a single, clean source connecting brand terms to functional terms. It gives support, sales and partners one reference. And it forces the internal conversation about what each feature actually is, which is often where naming problems start.
Renames without amnesia
When you rename a feature, the old name does not disappear from the web. It lives in old articles, reviews, forum threads, analyst notes and the training data of models already in production.
Handle renames as migrations, not announcements:
- Keep "formerly [old name]" on the feature page and in its docs for at least a year
- Redirect old URLs to the new pages rather than deleting them
- Update your own surfaces in one pass so the transition window is short
- Ask the review sites and marketplaces that list you to update their profiles
- Track description accuracy on both names in your prompt set until the old one fades
Vendor names move fast in some categories. Security is a good example: products get renamed after acquisitions and platform consolidations, and buyers keep asking for the old names long after. Writing both names is how you stay findable through the transition.
Making naming part of the product process
If naming is a GEO decision, it needs a place in the product workflow rather than a review after launch.
Add three questions to your feature naming review or PRD template:
- What will buyers type when they need this? Write the top three phrases, from sales calls and support tickets if possible.
- What is the standard term? Name the protocol, standard or category term this feature implements or belongs to.
- Where will the pairing appear? List the surfaces where the brand name and functional description will travel together at launch.
These take ten minutes in a review. Retrofitting them across a product later takes months.
Who owns it
Product managers own feature names, with product marketing as the partner who brings buyer language. SEO and content teams should be consulted, because they can show which terms buyers use. But the decision sits with the people who define the feature. This is the pattern that repeats through the rest of Part Two: the people who can change the signal own it, and the people who can measure it advise.
How to test a naming change
Naming changes are ideal first experiments, because they are cheap, targeted and measurable. Use the loop from Chapter 3: pick a flagged feature, add the brand-plus-function pairing across its surfaces, leave a similar feature untouched as a control, and track mention rate and description accuracy on prompts that use the functional term. If the treated feature moves and the control does not, roll the pattern out.
The question for this chapter: which of your features would a buyer describe in words that never appear on that feature's own page?
Key takeaways
- A branded feature name nobody prompts makes the feature harder to cite for the question buyers actually ask.
- Every branded name should travel with its functional description and standard term, everywhere it appears.
- Publish a naming map, and handle renames as migrations with "formerly" notes and redirects.
- Add three naming questions to the PRD or naming review: buyer phrases, standard term, and launch surfaces.