The Art of Feature Naming — Four Survival Tips
Naming is hard. All kinds of naming is hard. Parents have a hard time naming babies. If you build or market a product you are passionate about, then it’s basically your baby. Product marketers have a hard time naming products.
It’s hard, because just like with human infants, is any name really good enough to describe the wonder of your baby? Maybe it would be simpler to just always refer to your baby as “wondrous, brown-eyed, perfect nosed creation.” That becomes hard to say day to day. “Honey, I’m changing wondrous, brown-eyed, perfect nosed creation’s diaper right now.” Not so practical.
Product managers often go through a similar journey. There’s often a desire to create as detailed, accurate and exciting a description as possible for a product. It becomes just as impractical.
Feature Name Firestorm
But it’s not just products. There’s a lot of theories and frameworks about naming products. You can pay agencies millions of dollars to help you name a product. That solves your initial problem. Then, your first major feature is ready to get released and once again, you have a naming problem.
If you market cloud software built using agile software development, this problem becomes an ongoing, relentless, torrent of a problem. The problem has gotten worse as deployment cycles have moved from quarterly to weekly to continuous delivery. At any point in time you may have a feature going out the door to customers. Features might be incremental, they might be upgrades, or they might be the first feature of a brand new feature area.
Let’s take that last senario — some totally new functionality. It’s a tough one. You’re engineering and product teams are trying to be agile. There are a bunch of use cases customers have been asking for that feel like they roll up into a big new feature area. But there’s no spec for this big new feature area. All product management knows for sure is the starting point. They have full clarity on the initial capabilities they are targeting. But it gets vague after that.
Will there be 10 more individual components to this feature area? If so, then maybe it’s worth a broad feature category name. Or is it so big it’s actually a new product altogether? Or, will there be 1 or 2 additional components to this feature area? If so, then maybe this is a small scale effort and the naming should just be specific to those 2–3 features. At the extreme, maybe the new functionality is additive to an existing feature, and there does not need to be a new feature name yet at all.
There’s also the problem of velocity. How do you spin up naming efforts when features are being released at any given point of time? When do you finalize the name? When the spec is written? When it goes beta? GA? There’s increasing cost of changing a name as it gets into the wild. Engineers and PMs will talk about it. Sales engineers will start referring to it. Internal docs will use the name. Momentum builds. However, it can be hard to really lock in a name early in the process because might be just a fuzzy picture of what the feature is going to look like.
How many layers of naming do you need? Just a feature category and individual features? Or do you need to bundle up some of those features into a sub-category?
How do you create consistency across feature names so they feel like a family?
And all of this before you have even gotten to the actual debate on the name of the feature. Then, you have to decide if you’re naming the feature based on its benefits, functionality, industry terminology or any number of other things to anchor against.
Naming is hard.
Bring Method to the Madness
To solve naming, you certainly need a process in place, where naming is done proactively and consistently as part of the feature lifecycle. You also need a clear system of record, where everyone knows where to look for official feature names.
Many of the issues above really become more art than science. Knowing your competition, your customers, your product and your technology well is a good start. It gives you the foundation you need to navigate the complexity.
I’ve come up with a few general rules to help guide a product marketer through the challenges of continuous feature naming:
- Keep names simple. A name doesn’t have to explain everything about a product. It’s simply a bookmark for a concept.
- Anchor as much as possible to existing knowledge among your customers. There are times where you want to be different, but being different requires a lot of energy. You will have to explain what your different thing is 10 times before people understand. You have to be very selective of what you decide to do differently from the rest of an industry.
- Say what your product or feature does or is. Sounds simple, but there is a lot of art in this. Try to strike a balance between using technical terms and plain English. B2B technology products are often complex enough already. People just want to know clearly what the different components and capabilities are of the product. If you get too creative with benefit-focused names, you make it harder to describe your product. I prefer benefit-led marketing messages that promote a functionally defined product feature set.
- Try to use the name. Try it out in marketing content, docs and product design mocks. See if it feels right.
Other then that, I don’t have any easy rules to follow. I’m not going to oversimplify this and tell you I know how to make naming easier. Naming is hard. I like to think I get it right a good amount of time, but I definitely still get it wrong at least some of the time.
