Feature Naming Is a Testable Decision, Not a Team Vote
A product or product-marketing leader choosing which candidate feature name to ship should run a controlled comparison against a defined buyer population before the name locks into the UI, docs, and sales decks. The name that wins should be the one that changes correct identification of the feature, not the one the team likes best in a planning meeting.
Why the decision matters
A feature name lives in the UI, the changelog, the sales deck, the help center, and the customer's own conversations about the product. Once it ships, it is expensive to change: docs reference it, onboarding explains it, sales has pitched it, and customers have built a mental model around it. A name that new users misread on first contact produces months of support tickets, onboarding friction, and confused sales conversations.
Teams skip proper naming research for a structural reason: recruiting real customers for comprehension interviews takes time and money, and feedback usually arrives after engineering has already committed the name to the codebase. So the decision defaults to whichever name a handful of people in a meeting happen to like.
What causes the outcome
Internal teams suffer from the curse of knowledge. A name that feels obviously clear to the people who wrote the feature spec is not the same name a customer encounters cold, with no tooltip or onboarding, just a word in a navigation bar. Structured concept testing exists to separate what a team already understands from what a first-time viewer infers from the name alone (UX Army, Concept Testing In Market Research & UX).
Naming quality is a four-axis decision, and most internal debates collapse all four into "which name sounds best":
| Axis | What it measures | Failure mode if ignored |
|---|---|---|
| Comprehension | Whether a new user can correctly guess what the feature does from the name alone | Support tickets asking what the feature is for |
| Category-fit | Whether the name signals the right mental category (a "Reports" name versus an "Insights" name) | Users expect the wrong kind of feature |
| Differentiation | Whether the name is distinguishable from similar-sounding features already in the product | Confusion between adjacent features in the nav |
| Memorability | Whether a customer can recall the name later, in conversation or in a support ticket | Customers can't find or reference the feature again |
A name can win on memorability and lose badly on comprehension, a tradeoff a single popularity vote hides.
Evidence
A sound naming process separates candidate generation from evaluation: brainstorm broadly first, then test the surviving candidates against a defined audience rather than judging them as they're written (SmashBrand, How To Create An Effective Product Naming Framework).
A structured comprehension test on candidate names for a given feature typically shows: a metaphorical name driven mostly by internal appeal scores well below a plainer, descriptive alternative on correct-guess rate and confidence, because new users read the metaphor as unrelated to the feature's actual function. This is a historical planning example of the pattern naming research catches, not a current Subconscious benchmark figure.
Comprehension variance, not average preference, best predicts which name will need a tooltip or onboarding tour. A name that different testers guess differently ("could be reporting, or maybe an alert system") should be eliminated even when its average preference score looks fine.
A name that is clear and inoffensive in one language can fail category-fit, or, less obviously, translate cleanly but lose its category signal in another market.
Options and comparison
| Approach | What it tests | Where it's weak |
|---|---|---|
| Internal team vote | Whether the team likes the name | Blind to the curse of knowledge; no comprehension signal from an outside perspective |
| Recruited customer interviews | Comprehension, category-fit, and emotional resonance from real customers | Expensive per session; feedback often arrives after the name has already shipped into code |
| A/B testing a shipped name | Real usage and behavior once live | Learns the answer only after the cost of a wrong name has already been paid |
| Controlled experiment on a defined buyer population | Comprehension and category-fit across defined candidate names, before anything ships | Does not replace watching real customers encounter the name in a live product |
Recommended decision process
Subconscious runs a controlled experiment comparing defined candidate names across a defined buyer or user population and measures which name changes correct identification of the feature. The output is a causal effect with a confidence interval, not an aggregated self-reported score. That distinction matters: the question is not "which name do people say they prefer" but "which name, when substituted for another, changes whether people correctly identify what the feature does."
A workable process:
- Generate a working set of candidate names spanning descriptive, metaphorical, proper-noun, and action-led patterns. Otherwise the comparison ends up testing several variations on the same idea.
- Define the population the comparison should represent: new prospects, recent signups, or existing customers, depending on who encounters the name first.
- Run the controlled comparison and pick a name with both a high correct-identification rate and tight agreement across the population, not just a strong average score.
- Carry the top candidates into direct conversation with real customers before finalizing. See /research and /how-we-work for how Subconscious structures and validates causal experiments.
When the name needs to work in more than one market, run the same comparison against a population defined for each target market. Subconscious can run controlled studies against a person-level audience graph covering 800 million real people, supporting those market populations without committing to one name and finding out later. That audience graph describes reach for defining a population; it is not a pool of participants recruited for open-ended interviews.
Limitations
A controlled naming comparison does not replace watching real customers encounter the name in a live product. It does not constitute real-human validation, and it does not resolve emotional resonance or brand-fit judgment calls that benefit from a direct conversation with a customer.
Subconscious can test or validate studies with real human participants, letting a team move from a simulated comprehension experiment to real-human validation without changing the causal question.
Adjacent questions
Why not just pick the name the team likes?
Because the team already understands the feature. That's not evidence of how a new customer reads the name cold.
Does this replace talking to customers?
No. Use a controlled comparison to narrow candidates to a short list based on comprehension and category-fit, then validate the finalists with real customers before locking the name in.
What if the name needs to work in more than one market?
Run the same comparison against a population defined for each target market. A name that is fine in one language can carry the wrong category signal, or an embarrassing meaning, in another.
Talk to us at /demo, or read how other teams have used this approach in /case-studies.