Good Rules for Product Naming
Product naming seems simple until you try to name something that doesn’t confuse customers, developers, or internal teams. After years of seeing products with names that obscure rather than clarify, here are the principles that actually work.
What Product Names Should Never Be
Patterns to avoid:
- Acronyms - They create cognitive load and exclude newcomers
- Team names - Products outlive team structures
- Project names* - Projects end, products evolve
- Code names - Internal references don’t serve external users
- Clever over clear - Wit without meaning creates confusion
An asterisk on project names: unless the project is specifically about building the product, in which case it’s just a product model and shouldn’t share the same name anyway (proof by contradiction).
Start with the Right Questions
Before brainstorming names, understand the naming problem:
What are people missing due to current naming?
Identify the confusion, ambiguity, or barriers the current name creates.What do we want people to recognize in the naming?
Define the key associations, capabilities, or relationships the name should convey.Which terms need to be distinct to meet the above needs?
Determine what must be unique versus what can share naming conventions.
A Decent Default Naming Framework
A clear product name can follow this structure:
[Brand] [Family] Service [Distinct Subfeature] [Version]
This pattern creates hierarchy and context while remaining flexible enough for different product types.
Why This Matters
Product names shape how teams think about boundaries, how customers understand capabilities, and how ecosystems develop. A good name becomes infrastructure for communication—it reduces explanation overhead and creates shared mental models.
Bad product names force constant clarification: “When you say X, do you mean the platform, the API, or the dashboard?” Good names eliminate these questions before they start.
Implementation Notes
- Consistency beats creativity - Following a naming pattern helps users predict and understand new products
- Test with real users - Names that make sense to product teams often confuse customers
- Plan for evolution - Good naming frameworks accommodate future products without breaking existing patterns
- Consider the ecosystem - Names exist in context with other products, tools, and industry terminology
The goal isn’t perfection—it’s clarity and consistency that scales as your product portfolio grows.
Related:
- From Project to Product Management - Understanding product boundaries
- Platform Product Extension Model Language - Naming patterns for platform extensibility
This is an entry in my digital garden. See what else is growing here.