Naming Process 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

The “Full” or Tier 1 process includes enough time to review and provide feedback on proposed names, or to help generate some viable options, as well as running a legal and localization search and conducting some external research to better understand how a name might land with our target audience. This process would be beneficial for Tier 1 or Tier 2 products, programs, and features

The “Light” or Tier 2 process provides at a minimum enough time to do a brief search and competitive analysis, and a 24- to 48-hour sprint to provide alternative options if any obstacles are uncovered in the initial brief search. We also provide tools and guidelines for anyone creating something that needs a name to run the Tier 2 process more or less self-powered.

Our goal is to make this as simple and seamless as possible while accounting for the challenges of naming things and remaining aligned on our goal of elevating and spreading awareness of the Sourcegraph brand.

The process aims to address three main areas:

  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.

The Process

The full process should begin once the project or program is considered an approved, viable object that will be released to the public. Experimental projects should use a descriptive code name (see important notes above) until viability is achieved, at which point the naming process for official release can begin. Expect the “full” process to take anywhere from 4-6 weeks max depending on the name, localization needs and trademark research or approvals. Thus, it’s important to align the full naming sprint with the expected launch date, to ensure there are no blockers to launch from a naming perspective. During beta testing and experimental phase, the bland or descriptive names can be used with users. Once a go-to-market is approved and planned, the decision between full or light naming processes should occur immediately.

“Full” Naming process for externally-facing products, features, programs, groups and events:

  1. Plan – POCs will work with the Marketing team to develop the Naming Strategy and assemble the Naming Team. The strategy session’s output is a brief which includes what we are naming, a detailed description, the foreseeable roadmap for the thing being named, where the thing fits into our overarching brand and product hierarchy, how the name should perform, what lift the name needs to provide, and an audit plan of competitors and similar brands or companies.
  2. Sprint – Naming team participates in a 5-day sprint to generate as many viable names as possible, facilitated by the Brand team. KDMs will be determined up front, though anyone may participate in the initial sprint based on various approach angles: Customer perspective, Literary and cultural inspiration, Obvious and descriptive, Mash-ups, etc.
  3. Test – Get the name(s) in front of our users and our target audience and measure Resonance, Recall and Clarity. This needn’t be a lengthy or expensive step; a targeted survey group of even 100 people, geographically distributed, can help gain enough of an understanding around your proposal and whether or not you’ve obtained enough of a delta to validate your hypothesis. For higher-profile products, sub-brands, or branded offers, a more comprehensive study may be required to obtain a statistically significant measure of both qualitative and quantitative data.
  4. Commit – All team members may not agree, but if we have demonstrated there are no blockers or conflicts, we will commit to the name (or new name) and proceed. Final approvals internally for chosen names will require sign-off from Legal, Brand, and Product, and in some cases (based on scope) may require additional approvals from Leadership Team.

“Light” naming process for Level 2-3 feature names and internally-facing projects, programs, and events:

  1. During the initial planning phase for the project or program, the Requestor should use the Resources provided below to see if their desired desired feature, group, or program name is being used elsewhere, has any translation or localization challenges, or has additional meanings or innuendos that may be culturally or demographically inappropriate
  2. Requestor shares results of initial search with Brand and Legal teams for review
  3. If required, Brand and Legal teams will do a more thorough background search and evaluation
  4. Requestor’s name is approved for use in the specific case requested, OR Brand/Legal teams may ask to meet with Requestor to discuss options based on preliminary search

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 chart in the Handbook, 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

We can test name selections by speaking to customers, internal stakeholders, POC users, and running rapid-response surveys of our target audience as a litmus. These surveys need not be the final decision-making apparatus, but rather will help guide us from problem to research to hypothesis to finalization and adoption.

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 for the Full Naming Process described above:

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

Still have questions? Reach out to brand@sourcegraph.com or sign up for Marketing Office Hours. If you’re ready to request a naming sprint, simply use the Creative Request Form.

Thanks for helping us continue to build a successful brand that empowers and resonates with our users!