Naming guide for products, features and programs

Background

Naming can be tricky. Not only do you need something that explains your product or generates curiosity, but you also need some level of internal consensus, assurance that you aren’t infringing on someone else’s trademark, and an understanding of any localization or translation issues that may arise. To ensure we don’t end up needing to run a last-minute name change process based on a trademark or communication challenge that pops up (causing a lot of extra work for engineering, design, and marketing), we’ve developed a relatively short and sweet naming process that will cover 99% of naming needs for products, features, programs, or events.

Overview

Goals:

  1. Prioritizing the use, and therefore the awareness and recognition, of the Sourcegraph brand
  2. Provides the fastest, most direct path to a user understanding the new program/product/feature
  3. Not conflicting with other names used internally or by competitors

Considerations:

  1. Is this an external name?
  2. Is it for an L1 product name or a branded feature?
  3. Is this for a public group, community, program or event?
  4. If internal, is it something that will be seen or used company-wide?
  5. What are the regional, global, and cultural ramifications?

Dos and Don’ts:

  • Do start with a code name that is extremely bland and/or descriptive (i.e. Website Refresh, Project Dark Mode). This may even end up being the final name for launch if the name clears one of the process flows.
  • Don’t fall in love with a name when starting a new project or naming sprint.
  • Don’t use other company names within your code name (i.e. “Uber for Code”, “Amazon for Code” etc.). This opens the door for potential legal implications if any project info is leaked or released.
  • Do provide clarity on who the project owner is, as they are ultimately responsible for signing off on the code name after receiving counsel and approval with Brand and Legal (and sometimes People and/or Ops) prior to committing. The project manager is the “lead” who is responsible for the work being shipped. This lead may be a Product Manager, design lead, marketing manager, event planner, community manager, etc.

A note on using descriptive names for features and programs:

  1. Aligns with naming conventions for all of our existing products and features
  2. Enables marketing to more efficiently build awareness for Sourcegraph (customers, analysts, the media just need to remember “Sourcegraph”)
    1. In the future, if we should choose to begin using “branded” names for all our products and features, it is much easier to go from generic/descriptive to branded than the other way around, so we can pick up the discussion again after Sourcegraph has achieved household status among our audience.
  3. Allows us to adapt as the product/feature evolves.
  4. Resonates with our target audience
  5. Unlikely to infringe on third-party trademarks (descriptive fair use is a defense to trademark infringement)

Descriptive or “concrete” words tend to be more memorable because they create a mental picture, as opposed to more abstract or “fluffy” words that require a lot of explanation or education. A problem with abstract words or words that have a wide variance in meaning based on usage is that they lack a mental reference point.

Additionally, abstract or “suggestive” names are more often reserved for brands, branded offers, sub-brands, or branded features to help differentiate a basically identical product from another; think “Bing” vs “Google” or Nike “Air” soles vs Adidas “Boost”. These names often require tremendous marketing lift and spend – as well as dedicated legal support for trademark registration and an extensive competitive analysis.

Stylization

After you’ve selected a name and it’s been approved for use, how does it show up across our communications, our digital channels and our products?

Following our Product Hierarchy, all Level 1 products, events, and programs should be capitalized. Examples: Universal Code Search, Batch Changes, Code Insights. This would also include Level 1 and externally-facing media we produce such as our podcast, a web series, and white papers or e-books. Another way to think about capitalization is, is this “thing” a proper vs a common noun? For instance, an annual Sourcegraph company picnic might be simply styled in lowercase, whereas the “Sourcegraph Summer Celebration” would benefit from using initial caps.

See the Capitalization Guide in the Handbook

When in doubt, reach out to the Marketing team and we can help identify if the name will benefit from capitalization, or if the product or program falls in a gray area.

Definition of Success

A naming convention will be deemed successful if it meets the following criteria:

  • Does not conflict with any existing product or feature name used by a competitor

  • Is not trademarked, either in the US or abroad

  • Does not require a lot of explanation to make sense to a potential user

  • Resonates with and is easily understood by our audience

  • Can be translated into multiple languages, either directly or contextually

  • Meets pre-determined score in the grading scorecard above

A naming convention does not need to:

  • Be a “branded” word or otherwise proper noun

  • Be able to be trademarked, unless it is unequivocally a new and unique feature or product

  • Have dual meanings or a clever word twist or pun

  • Be awe-inspiring or overly attention-grabbing

  • Have a strong emotional connection

An example naming scorecard:

Naming Scorecard: Insert Name Here
Grading Area1 (least)2345 (most)
Positioning
Clarity
Tone
Resonance
Recall
Emotional Connection
Technical Criteria Met?
Landscape Analysis1 (low)2345 (high)
Uniqueness
Defendability
Standardization
Marketing Lift

Additional Resources