Naming products isn’t the problem
Why product backlog item naming matters 2020-05-05 #product
Companies find it famously hard to name their products. Fortunately, for product people, they don’t name products often. However, content marketing and user-interface text include plenty of product-related names, which have to come from somewhere.
Business objects and musical instruments
Enterprise software sometimes lets you define your own data structures, blurring the lines between configuration, customisation and software development. Imagine hypothetical product management software that deals with customers, products and product capabilities. If you were using it to manage a platform for online music lessons, you might want to relate each lesson with a musical instrument that you define by:
- name, e.g. transverse flute
- type, e.g. woodwind
- portable, e.g. yes
Salesforce has built-in business objects such as account, to which you can add your own custom object types, such as musical instrument. Unfortunately, other products use different names:
- business objects
- custom objects
- complex objects
- object types
- record types
- complex types
As a product manager, adding a capability such as configurable business objects to the product backlog means naming it, or choosing between the names already in use, in the market, among existing customers, and within your own organisation.
Product backlog naming
A product contains many names - concepts and capabilities, jargon and features. Product people have a big influence on naming within their products, because they get to choose first. Product concept and capability naming starts in the product backlog.
Product capabilities appear in the product backlog, where their product manager blesses and names them. Meanwhile, the same things arise in sales’ conversations with customers, and in product marketing analysis of competing products. Unfortunately, different people use different names for the same thing.
If you decide to add custom objects to your product, you can do without friction caused by sales calling the capability business objects because it sounds enterprisey, while customers are used to their legacy system having record types, and software developers insist that the correct (technical) name is complex types. While you can’t (and shouldn’t) completely avoid a concept having different names in different contexts, as with scientific names versus colloquial names, everything goes more smoothly when everyone consistently uses the name you want customers to use.
Product backlog items use a mixture of existing concepts and new concepts, which also have names. Naming product backlog items comes with great responsibility, because names stick. Even bad names.
Good product capability naming
Good product backlog naming goes beyond using a consistent abstraction level. Good names:
- consistently name either capabilities or features
- use a descriptive phrase that summarises the capability, instead of code names
- use subject matter domain language, rather than made-up jargon
- consistently use the same terms, instead of using synonyms
- contain few words so that people don’t invent abbreviations.
Good names exhibit consistency and explanation, and don’t come easily. But good names have great value: they form the basis for effective concise communication. And naming tips can help.
