Recently, I was working with a company on both their product and company naming. Here was some of the basic guidance used to guide the decisions:
Some naming realities – Names are for people outside your company
o Names are things you want an audience (i.e. people) to remember
o Names are things you brand and even trademark, they are things you invest in, if you don't they are just words
o Names communicate and simplify
Some people realities:
o People are easily confused - complexity does not work well in names
o People have a limited cache - they can't digest too many names at once
o People forget - they need to be reminded over and over again of the same one or very few names
What is "naming convention"? A basic framework that…
o allows you to know WHAT you are actually naming and not naming,
o helps keep these names consistent and compelling, and
o makes it faster and easier to name each time.
Keeping things straight. Generally the things you name are as follows (make sure you really know the difference between them and how they relate to each other):
o the company - this is the longest lasting name you have to have. You pour your values,
personality, mission, vision etc into this brand (e.g. Microsoft)
o the product line - a family of mulitple products that are related to each other (e.g. Office)
o individual products - the products within a family, either different variations or component
products of the core family (e.g. OfficePro)
o product versions - as the specific individual products evolve, this is the means of keeping track
(e.g. OfficePro 95)
o ingredient names - the green crystals or Secret Sauce. These should be lasting technologies or
concepts that cut across more than one product (e.g. Intellisense, Retsin)
o feature names - usually version specific functionality, that you want to highlight in promotion but
not in packaging (e.g. Pivot Tables, the Blue Dot)
o program names - not products, but supporting efforts that are worthy of naming, putting
marketing investment behind. Often at the corporate vs. the product level (e.g. MSDN not Visual Studio Developer Network)
Some ground rules for a good naming convention
o Names should either be memorable or meaningful – create the right emotion or communicate/imply the actual thing they are naming
o Company names should be flexible and bigger than the names of the products, they are receptacles that you put meaning into. They don't have to be as concrete as the product names (Salesforce.com is kicking themselves, they are going to have a hard time launching an ERP product)
o Invest in very few core names, build the rest of your convention around them
o Do not name stuff you are not going to support or invest in over the long term
o Don't work too hard. Even if you don't love the name, even if it doesn’t make sense, if people already love it and are aware of it, keep it.
Also wanted to make a quick plug for Susan Giordano and Christopher Ireland who have done a bang up job for us on a number of corporate ID and naming efforts.
Posted by johnza at June 5, 2004 02:33 PM | TrackBack