If you want to be a bad product manager, use the internal name for a project as the name you communicate externally. You already have the team bought in to the name, and they think it’s great, so why not use it with customers? Sales and marketing are familiar with it already. Plus, it was a project name that one of your executives came up with, and you don’t want to offend her by not using it when you’re communicating with customers.
If you want to be a good product manager, choose the internal and external names for projects carefully. Naming products is an important but separate area that will not be covered here. Instead, think about projects specifically — new versions of a product, specific sets of enhancements, or major new features.
It is important to come up with a good name for a project that can be used internally. Internal project names should communicate the vision and purpose of a project. They need to be distinctive and set the tone for the product development team. Calling the new quicker checkout system on your web site “version 3” is fine but so generic as to be meaningless. Naming it “eCommerce lightning” takes advantage of the opportunity to focus the project and give the team a rallying cry.
There’s a reason why the military gives names to specific missions. Whether or not you agree with the strategy and tactics, it is hard to argue that “Operation Desert Storm” should have been called “The Kuwait/Iraq initiative of 1991.” (Granted, this internal name was used for external communication purposes as well.) Good names solidify the mission of a project.
Regardless of your internal project name and how appropriate it may be, it should almost definitely not be used to communicate to customers, users, and other external stakeholders. Internal names serve a totally different purpose and are used by people very familiar with the project. External names need to communicate the value proposition, benefits, and features to a variety of different types of customers. Names that you may love as a product manager may make no sense to a prospect.
Be careful about using internal names around people who have contact with external customers. Sales, marketing, PR, and customer service are on the front line every day, interacting with those outside the company, and there should be a clarity and consistency to your messaging. Reiterate the internal name too many times to these groups and they may mix them up when talking with customers and others outside the company.
Good project names are important to focus product development teams but not to communicate with the market. Make sure you pick the right name for the right purpose and only use your external name when interacting with customers and customer-facing staff to avoid the possibility of confusion.
Translations available:
You did write that product naming would not be covered in this entry, but then you also wrote:
“External names need to communicate the value proposition, benefits, and features to a variety of different types of customers.”
Scientific studies and some branding gurus (e.g. Al Ries, Laura Ries, and Seth Godin) have come to the exact opposite conclusion (at least for some kinds of products): descriptive names are not as effective as abstract ones.
More here.
You’re right, and thanks for catching it. The purpose wasn’t to focus as much on what the external name should be so much as to point out the external name has a different purpose than the internal name.
As you noted, descriptive names may not be the best choice for many situations. Wikipedia has a good overview of the different categories of product names as well as links to other resources.
Ah, yes, I had forgotten about that Wikipedia entry. While it contains some interesting and though-provoking information, I find that the entry contradicts itself a bit. I just added to the discussion page for the entry a blurb pointing out the inconsistency.
As a team member, my big pet peeve with product managers and naming of product versus project is when half-way through the project (let’s say it’s called Project X), the product team starts working on the product naming. (let’s say they decided on “product Supercalifragilisticexpialidocious”). The product manager then announces that the project name is switching from X to Supercalifragilisticexpialidocious with the justification that it is not consistent with the product. (That is also often poorly communicated). Now not only it is a mystery why X became Supercalifragilisticexpialidocious but introduces a layer of confusion across the team that ads NO value to the product or the intended outcome. Project names should NOT change until the project is complete, even if the name is bad. That’s why it IS important to pick a good name.
I am a sincere reader on this post from last year to this year,Thank everyone of course including Jeff, honestly speaking, Jeff made huge effort