What’s in a name? A curiously long post about naming things.

I cannot stress this point enough: everything needs a name! And everything will get a name, whether consciously (i.e., thought went into it) or not (i.e., whatever term happened to pop into someone’s head when he entered it into a task list)

In my career at Sandvine, and setting aside particular titles, in thirteen years I had three roles:

• Product Manager (individual contributor)
• Product Marketing Manager (individual contributor)
• Leader of the Product Marketing team

In all three roles, I dealt to some degree with naming ‘stuff’: when I was a Product Manager, we didn’t have a Product Marketing team, so naming decisions were left to us; later, the Product Marketing team took over naming, and I took over the Product Marketing team.

Naming ‘stuff’ is something with which many companies and individuals struggle, because it’s rarely simple or straightforward. And things were no different at Sandvine. Due largely to a combination of past choices over a fairly long history, inconsistency, corporate philosophies, breadth of ‘stuff’, lack of clear ownership, and other factors, naming was always a loaded, hot-button topic.

After a particularly contentious discussion (which ultimately ended positively), in December of 2012 I banged out a long collection of thoughts on the subject and distributed it to some internal stakeholders.

This post is that long collection. It’s curiously long, in fact, but if you work with names, then it’s probably worth a read…even if you just want to argue with me. If you’re just starting out with naming, either as an individual contributor or as a company, then it’ll show you how much complexity can emerge.

So, what’s in a name? More than you probably think…

A few notes:

• The verb conjugation will be in the present tense, because I’m just using my original memo as the basis
• The memo focused on product, feature, and technology names, but the same concepts can be applied to, say, solution families, use cases, and the like
• Also, this memo takes a pragmatic approach…it doesn’t actually get into the hugely important issue of what makes a good name (e.g., aspirational, outcome-oriented, test-of-time, big picture, etc.); I’ll likely address those in a different post
• There’s nothing proprietary in here: the product, feature, and technology names are published, and the rest is just a collection of my thoughts
• The tone was meant to be dually explanatory and exploratory, rather than dictatorial…I was trying to elucidate an opinionated and contentious issue, and to do so I needed to tear down the arguments that I kept running into internally (e.g., selective data, opinion masquerading as fact, etc.); sure, I was looking to establish accountability for naming within my team, but I was also open to discussion – I’d thought through many of the issues, and probably knew them better than anyone, but I’m not foolish enough to think that I’d come up with the best or only solution
• I’ve added occasional emphasis (bold) and a bunch of ‘present-day’ comments

Well, It’s Complicated

With every new feature and product developed at Sandvine, we are faced with a decision: what do we call all the components? Ultimately, everything we produce has a name, and names exist in a hierarchy: at the top there’s the product name, at the bottom there are atomic engineering feature names, and in-between…well, there’s stuff.

Present-Day Comment #1: Yep, whether you realize/acknowledge it or not, everything you produce has a name; the choice is whether you deliberately give it a name, or whether a name just magically gets given to it

Consider:

• Traffic Management
  • Base Traffic Management
    • Strict Priority Shaping
    • Weighted Fair Queuing
    • Minimum Rate Shaping
    • Policing
    • Blocking
    • Session-Limiting
    • Marking
  • Fairshare Traffic Management
    • QualityWatch
      • <atomic engineering features>
    • QualityGuard
      • <atomic engineering features>

The example above includes two concepts: names and a hierarchy. For interest, everything in the hierarchy depicted above (with the exception of the <> items) is listed in the product promotional material. In practice, some items get included in promotional material, and others don’t; during the early development phase we might have a fairly good idea of what we think will appear on public material, but the fact is that we don’t know for sure. Consequently, with regards to naming, we should assume that every feature, no matter how trivial, will one day be promoted.

Present-Day Comment #2: Hierarchies are a very useful organizational tool…they help bring order to chaos and have wide applicability; as our company’s capabilities grew, hierarchical structures were enormously valuable both from to organization the information and to help tell our story

Present-Day Comment #3: This last point, about assuming that names will be promoted/public has an important implication: never just ‘mail it in’ on a name, thinking that no one will ever see it

Hierarchies

In simplest terms, at the top we have products (“Traffic Management”, in the example above). At the bottom, we have atomic ‘engineering features’ (“Strict Priority Shaping” and the other items listed under “Base Traffic Management”, in the example above); think of the ‘engineering feature’ as the simplest atomic form that we develop (before you get into the intricacies of individual procedures and objects in code). What goes in between? There’s no single answer because, in practice, we haven’t been consistent over the years. In the case of “Base Traffic Management”, we’ve given a name to a collection of features.

In the case of “Fairshare Traffic Management”, the name encompasses two non-functionally named features (i.e., “QualityGuard” and “QualityWatch”). Each of these two non-functionally named features is actually composed of many more granular engineering-level features, but for simplicity’s sake we choose not to expose them in our promotional material.

Generally, we’ve chosen to group features under a collective name in the hierarchy when the features collectively solve a single well-defined problem (in Pragmatic Marketing’s terminology, both “QualityGuard” and “QualityWatch” are called “Marketecture”, and there is a template for mapping customer problems to engineering features via a linkage of marketecture).

Types of Names

Ultimately, whatever name is assigned is the name that we (likely) live with forever: that’s the name that appears in engineering documentation, CLI commands, release notes, promotional material, etc. With so many points from which the name is referenced, changing a name post-facto is very expensive and tedious. Therefore, it’s extremely important that we be mindful of the impact of the choice of name, we choose a name after careful consideration and thought, we choose a name early in the New Product Generation (NPG) process (in practice, we have the names planned by Concept Commit, and confirmed by Execute Commit).

Present-Day Comment #4: Getting a name established before coding begins is pretty crucial; more than once, we ran into an unexpected problem in which production had begun before an official milestone, and then it was “Well we can’t change the super-descriptive-and-technical-name-or-weird-acronym because we’ve already written the CLI commands.”

Present-Day Comment #5: Note that – to combat an argument I faced frequently – “careful consideration and thought: doesn’t mean “take forever and perseverate, form a committee, etc.”; it’s more like, “give an appropriate amount of thought”. So, if you’re naming a new flagship product or major differentiating feature, then you’ll take more time (maybe even weeks, including trademark searches) than if you’re naming some contributory atomic feature (maybe five minutes). Use “just enough process” and make a conscious decision, rather than being held hostage by a decision made without thought.

Broadly speaking, names can be divided into two categories:

• Functional Descriptions as Names
• Non-Functional Names

Functional Descriptions as Names

Examples: “Quota Manager”, “Weighted Fair Queuing”, “Network Protection”

A functional description has the benefit that no one can trademark it, which means that Sandvine cannot be forced stop using the name. However, it has the major downsides that the generic-sounding name is not memorable and can imply that there’s nothing special about the feature (i.e., it’s a commoditized function – for a company that differentiates based on technology, this is a very serious risk).

Present-Day Comment #6: Picking generic names was a conscious part of Sandvine’s intellectual rights management strategy at the beginning, and was adopted for some good reasons; nevertheless, it caused problems later in life. Like many things, there are trade-offs. For instance, as a company we engineered differentiated, complex technology, but used generic names that undermined that differentiation. Our competitors could – and in many cases did – just outright copy-and-paste our descriptions and terminology, creating the perception within our target audiences (whether legitimately or as a negotiating tactic) that all the market offerings were roughly equivalent. In some cases, this lack of distinction had disastrous consequences.

In practice, people frequently shorten functional description names into acronyms (e.g., “QM”, “FSTM”, “RTE”, “NA”, “NDS”) or short-forms (e.g., “Peak Period Dashboard” instead of “Peak Period Analysis Dashboard”, “Analytics” instead of “Network Analytics”, “Demographics” instead of “Network Demographics”), and in doing so create customer confusion and render the name pointless (i.e., it is no longer memorable or special in any way).

Non-Functional Names

Examples: “SandScript”, “QualityGuard”

Psychologically, non-functional names are valuable – they convey an aura of uniqueness, of excellence, of importance. However, this value is diminished if the naming pool is diluted; that is, if we start giving everything a snazzy name, then each individual name becomes harder to remember and seemingly less distinct.

Present-Day Comment #7: People really can become addicted to wanting to give everything a snazzy name…restraint and oversight is required.

Additionally, more due diligence is required before we introduce and use a non-functional name; we must ensure no one in a related business is using the name already.

In practice, the trick becomes how to balance the pros of introducing a non-functional name with the cons of introducing too many names.

Hybrids

It’s perhaps worth noting that we’ve occasionally used a hybrid model, with a prominent example being “Fairshare Traffic Management”. The “Fairshare” component is not actually a word, but is a concatenation that is based on the descriptive idea of “fair share” (as in, “fair share of network resources”). When combined with “Traffic Management”, the whole name becomes an interesting hybrid.

A Note about Legal Concerns

Present-Day Comment #8: IANAL (I am not a lawyer); consult a lawyer for lawyery stuff

The primary (legal) risk associated with a name is that someone else is using it; however, if two companies are using the same name, it does not necessarily mean that one is infringing upon the other’s trademark. If they’re in unrelated industries (so there is no risk of confusion), then it isn’t a problem. We use “QualityGuard” as a feature name, and Nissan (the motor company, not the computer manufacturer) uses the same term to describe their warranty, and we do not expect this to be a problem.

Nevertheless, the day may come when we are challenged by another entity over the use of a name. If such a challenge arises then Sandvine has three main avenues of action:

• If the challenge is completely without merit, we can continue to use the name
• Insert “Sandvine” in front of the name (e.g., “Sandvine QualityGuard”)
• Stop using the name

Present-Day Comment #9: As far as I can recall, we never ran into any legal issues with any of our names

Decisions, Decisions

Ultimately, since everything we produce fits within some structural hierarchy and each item in the hierarchy must have a name, we must always decide:

1. Hierarchy: What hierarchy will we impose upon the product? Alternatively, how does the new item fit into the existing hierarchy (e.g., is it a feature, a sub-feature, a technology, a new product, a set of features, etc.)?
2. Naming: What do we name each item in the hierarchy?

Determining an Appropriate Hierarchy

Consider the example below, and note that it’s not exhaustive (there are products omitted, and even for products that are included there are engineering-level features that don’t appear in the table):

Product	Second Level	Third Level
Traffic Management	Base Traffic Management (*)	Strict Priority Shaping
		Weighted Fair Queuing
		Minimum Rate Shaping
		Policing
		Blocking
		Session-Limiting
		Marking
	Fairshare Traffic Management (*)	QualityWatch
		QualityGuard
Usage Management	Quota Manager (*)	IPDR Input
	Policy Enforcement (*)	Usage Monitoring
	Record Generator (*)	IPDR Input
	Online Charging (*)	3GPP PCC Gy R7
Network Protection	URL Access Control
	Network Protection	Outbound Spam Mitigation
		Worm and Denial of Service Attack Mitigation
	Subscriber Protection (#)	Bot Detection
Network Analytics	Network Summary Dashboard
	Real-Time Entertainment Dashboard
	Peak Period Analysis Dashboard
	Routing Efficiency Dashboard
	IPv6 Transition Dashboard
	Usage Management Dashboard (*)
	Traffic Management Dashboard (*)

(*) denotes separately licensed

(#) denotes a packaged professional service

It is instructional to note that:

• Some items are licensed separately, some are included with the main product license
• Some third-level features are mapped to more than one second- and first-level item
• Some second-level items have third-level items, some do not
• Some items are descriptive names, some are not

As another example, consider Control Center, in which individual UI components and features must be named:

Product	Functional Tabs	Feature Names
Control Center	Operations	Smart View
		Real-Time View
	Policy	QuickEdit
		PowerEdit
	Configuration	Auto Discover
		Snapshot
	Change History

Ultimately, the hierarchy decisions are based upon a combination of “how do we want to sell this item?”, “how do we want to organize this item?”, and “how do we want to promote this item?” (how much do we want to expose in promotional material), all of which are informed by our understanding of our customers.

Further muddying the waters, we have never settled on what to call each level of the hierarchy, in a classification sense: Feature? Marketecture? Capability? Feature-Group?  Application?

We close off this section with an acknowledgement that there is perhaps work to do in this area to determine best-practices.

Determining an Appropriate Name

Recall that all things need names, so focusing just on “what needs a ‘cool’ name” is ignoring the vast majority of cases.

Present-Day Comment #10: I cannot stress this point enough: everything needs a name! And everything will get a name, whether consciously (i.e., thought went into it) or not (i.e., whatever term happened to pop into someone’s head when he entered it into a task list)

At this point, we will assume that the following process is always applied:

1. Prior to Concept Commit, we have knowledge of
   • The problems we are aiming to solve with the new development effort
   • The granular breakdown of the project; that is, descriptions (and working names – the words we are using internally to distinguish one task from another) of the atomic engineering features that will be developed to ultimately and collectively solve the problems
2. Prior to Concept Commit, the Product Marketing Manager (in collaboration with the Product Manager) will examine the list of atomic feature descriptions and, for each one will determine if the feature fits the criteria for a non-functional name (see the section below for these criteria).
   • If the feature warrants a non-functional name, then such a name is determined
   • If the feature does not warrant a non-functional name, then a functional name is determined subject to the sanity check of limiting the name to no more than four words (that do not collapse to some convenient acronym) that we would without hesitation include on a piece of promotional material
3. Prior to Concept Commit, the Product Marketing Manager (in collaboration with the Product Manager) will complete the Pragmatic Marketing “Marketecture Analysis” worksheet to map the atomic engineering features to the defined market problems, and to determine if collections of atomic engineering features will be collapsed into intermediate entities (“marketecture”).
4. For each new intermediate entity created during step #3, the Product Marketing Manager (in collaboration with the Product Manager) will determine if the intermediate entity fits the criteria for a non-functional name (see the section below for these criteria):
   • If the intermediate entity warrants a non-functional name, then such a name is determined
   • If the intermediate entity does not warrant a non-functional name, then a functional name is determined subject to the sanity check of limiting the name to no more than four words (that do not collapse to some convenient acronym) that we would without hesitation include on a piece of promotional material
5. At each level of the product hierarchy, the same naming principles are applied, right up to the top (product name) – the result is that by Concept Commit, everyone should know what everything is called, although we have until Execute Commit to finalize the names. The expectation is that this approach will balance the needs of engineering (knowing what things are called, so the name is reflected appropriately in early-stage development) with the pragmatic needs of marketing (to circulate names and tweak if required up until a reasonable point, where the “reasonable point” is the Execute Commit milestone).

Present-Day Comment #11: In practice, we had to amend our process to get names set before CC, because we ran into several situations where development work had started before the EC milestone (say, if a project was obviously going to be undertaken)

Broadly-speaking, similar thinking is applied to the naming of GUI elements: figure out the hierarchy, name things appropriately, have things visible by Concept Commit and settled by Execute Commit.

What Gets a “Cool” Name?

Arguments in favour of developing a non-functional name usually resonate the loudest when applied to items that:

• Are a differentiating technology or capability unique to Sandvine (e.g., “QualityGuard”, “SandScript”)
• Are of significant strategic value
• Obscure underlying complexity

We should also apply a fourth criterion, “Is there no reasonable functionally descriptive name?”. In other words, we should generally err on the side of needing to prove that a non-functional name is necessary, rather than handing them out like candy. For instance, in most cases functional names are perfectly sufficient, and we do not want to risk dilution of the pool of non-functional names or introduce legal concerns. Control Center has a feature called “Real-Time View” that gives “real-time visibility into network traffic and operations metrics”, and the name is suggestive of that function.

The more criteria satisfied, the louder the calls for a non-functional name. Two prominent examples of items that fit the above criteria are SandScript and QualityGuard. Consider the criteria as they apply to SandScript:

• Differentiating?
  • Our Policy Engine (and event-driven policy capabilities in general) is a differentiating technology and SandScript is the means by which we define what the Policy Engine does
• Strategic?
  • Our Policy Engine is of enormous strategic value due to its unique capabilities, and SandScript is of enormous strategic value because it allows customers to configure policy management in the field with a massive degree of control
  • Secondly, one major argument in favour of naming our policy language was to combat misinterpretation of “you can do that in policy”, by which we meant “you can do that with our proprietary, event-driven policy definition and scripting language”, but which customers understood to mean “you can do that only in your PCRF”

Present-Day Comment #12: Note that, at that time, Sandvine did not sell a PCRF, so what was meant to convey “Sure, you can totally do that in our amazing system” was sometimes interpreted as “you can do that only in that other thing that you bought from someone else”

• Obscures complexity?
  • The network policy control instructions governing how the intelligent network operates are incredibly complex, but SandScript gives a human-understandable means by which these instructions can be both controlled and understood, while hiding what’s ‘under the hood’
• Reasonable functional alternative?
  • Contrast “you can express that business rule in SandScript” with “you can express that business rule with Sandvine’s proprietary, event-driven policy definition and scripting language”

Applying the same analysis to QualityGuard is left as an exercise to the reader.

At this point, we should have a general understanding of the reasons why we would want to create a non-functional name, and an appreciation of the restraint with which we must approach this subject. The final step is perhaps the most contentious.

OK, this “thing” fits the criteria…so what do we call it?

Throughout this document, we’ve included examples of names already used by Sandvine. Some are completely functional (e.g., “Weighted Fair Queuing”), some are completely non-functional (e.g., “SandScript”), some are somewhere in-between (e.g., “Fairshare Traffic Management”), some include ‘CamelCase’ (e.g., “SandScript”, “QualityGuard”, “PowerEdit”), some do not (e.g., the “Fairshare” part of “Fairshare Traffic Management”), some are one word and some are as many as four words (e.g., “Peak Period Analysis Dashboard”). What’s the point of this paragraph? We have no hard rules.

Present-Day Comment #13: This point was crucial to my overall position, because over the years I’d run into many arguments that relied upon selectively chosen data. I wanted to firmly establish that we had no hard rules governing our naming.

The closest we come is the ‘rule’ that product names are functional descriptors of two words (e.g., “Network Analytics”, “Traffic Management”, “Network Security”), but:

1. That does not apply to “Network Demographics Server” (although, to add clarity for our customers and consistency with our other products, we externally refer to this product as, simply, “Network Demographics”, while our internal documentation still says “Network Demographics Server”)
2. That does not apply to platform components, which seem to have settled organically on three-word functional names that are acceptably compressed to acronyms (e.g., “PTS”, “SDE”, “SPB”)

So, before moving on, let’s summarize a couple of guidelines we would follow if we were to prioritize being consistent with the past:

• Platform components: three words, functionally descriptive, can be an acronym
• Products: two words, functionally descriptive, should never be reduced to an acronym

What about everything that goes below the top-level product or platform name in the hierarchy? Historically, the names Sandvine has assigned to elements in the hierarchy:

• Can be 1 to 4 words
• Can be functionally descriptive, can be non-functional, can be a combination
• Can include CamelCase
• Can include portmanteaux and concatenations
• Can include acronyms, without being reduced to acronyms
  • e.g., “IPDR Input”
• Can include standards terminology (e.g., “IPDR”, “Gy”, “R9”, “3GPP”, etc.)

In fact, someone would really have to try quite diligently to break the above ‘rules’.

We must explicitly make a decision: Accepting that Sandvine’s existing non-platform and non-product names are all over the map, do we continue with this level of flexibility or do we adopt and enforce more restrictive rules (understanding that they will never be “consistent” with the names already on the market)?

I argue that the reality is that we operate in a complex market and provide complex solutions (often organized in a specific hierarchy) to complex problems, so restrictive rules will prove impractical. I also concede that consistency left the station years ago, so it makes little sense to adopt restrictive conventions now without retroactively renaming everything.

It’s perhaps worth noting that this approach is one born of pragmatism and is actually grievously opposed to my own predisposition for standardization, structure, and consistency.

Present-Day Comment #14: This next part, while a tad repetitive, gets to the official proposal.

I hereby propose that we adopt a convention of flexible-but-subject-to-a-few-guidelines:

• Platform components: three words, functionally descriptive, can be an acronym
• Products: two words, functionally descriptive, should never be reduced to an acronym
• Everything else:
  • No more than 4 words
  • Can be functionally descriptive, can be non-functional, can be a combination
  • Can include CamelCase
  • Can include portmanteaux and concatenations
  • Can include acronyms, without being reduced to acronyms
    • e.g., “IPDR Input”
  • Can include standards terminology (e.g., “IPDR”, “Gy”, “R9”, “3GPP”, etc.)
  • Generally, but not unequivocally, the lower something is in the hierarchy, the more functionally descriptive the name

Practically/procedurally speaking, the most important aspects of naming are that naming be done early in the NPG process, so all the impacted parties are working with the correct name, and people understand and use the correct names in all communications.

Present-Day Comment #15: And herein lies another major issue: when names aren’t clearly established and enforced, different people in the company use different terms with the same customer. So the poor customer talks to an Account Manager, a Sales Engineer, a Support person, maybe someone in Marketing, Engineering, an Executive, and so on, and hears a half-dozen different names for the same thing. Rather than understanding that all those terms are referring to the same item, the customer just concedes that there’s no way he can understand our insanely complicated product, and just sorta puts on a distant expression. And of course you’ll run into people saying, “Well I’d never say X in front of the customer”, but they do. They do it in emails, or casually in presentations, or it’s written in the presentation. One name appears in the product roadmap, and another in the datasheet, and another in the documentation. It’s pure mayhem. Companies need to get accountability and (just enough) process in place right from the get-go.

Procedurally:

• The name is owned by the Product Marketing Manager, who accepts input from other parties but is ultimately responsible and accountable
• Starting at the bottom (atomic engineering development features) and working up in the hierarchy is ideal

Present-Day Comment #16: Establishing responsibility and accountability – in this case, with the Product Marketing Manager – is key; many of our problems were exacerbated, if not caused, by a lack of clear ownership

Name Changes

It’s important to at least raise the issue of name changes and hierarchy changes. Some examples from the recent past include:

• “Aggregate Traffic Management” became “Base Traffic Management”
• “Network Demographics Server” is referred to externally as “Network Demographics”
• “WDTM” became “Network Protection”
• “Network Security” was created as a parent to “Network Protection”
• “URL Access Control” moved under the “Network Security” umbrella

These are the five that sprang to mind given about 30 seconds of thought…a comprehensive list is likely much longer.

In this document, we’ve already alluded to and explicitly stated many parties who are impacted by a name or hierarchy change, so the list won’t be repeated. When choosing whether or not to change a name or product hierarchy, we are (as always) balancing pros and cons, and guidelines will likely prove more fruitful than hard rules.

Present-Day Comment #17: Another general Lee-ism: guidelines and templates are great guardrails, but situations are unique, so flexibility should be permitted (within those guardrails)

What might the future hold in terms of change? One possibility that springs to mind is that of Network Analytics – with an ever-growing list of dashboards, will we continue to implement and list all of them as immediate children under the “Network Analytics” product, as in this tree:

• Network Analytics
  • Network Summary Dashboard
  • Peak Period Analysis Dashboard
  • IPv6 Transition Dashboard
  • Routing Efficiency Dashboard
  • Real-Time Entertainment Dashboard
  • Usage Management Dashboard
  • Traffic Management Dashboard
  • “Real-Time Communications Dashboard” (*)
  • “Subscriber Analysis Dashboard” (*)
  • “Traffic Management for Mobile” (*)

(*) working titles applied to dashboards planned for the Network Analytics 4.0 release

…or adopt something like this?

• Network Analytics
  • Network Summary Dashboard
    • Peak Period Analysis tab
    • IPv6 Transition tab
    • Routing Efficiency tab
    • Real-Time Entertainment tab
    • “Real-Time Communication” tab (*)
  • Usage Management Dashboard
  • Traffic Management Dashboard
    • “Mobile” tab (*)
  • “Subscriber Analysis Dashboard” (*)

Food for thought.

Present-Day Comment #18: Yep, that’s really how I closed off the note, apparently. The ultimate result of this curiously long memo was that folks recognized that I seemed to have put a great deal of thought into things – and no doubt highlighted many subtleties that weren’t widely known – to the point that everyone basically conceded ownership of the subject to me and my team. Huzzah! I’m perfectly comfortable making decisions and being accountable, regardless of outcome. I just wanted organizational clarity, so we could stop repeating all the same mistakes.