A long time ago, there was a big fight between Engineering and Marketing regarding the name of a new 1.0 product. I was not there, but the fight went something like this:

Engineering: “So what are we going to call the product?”

Marketing: “We’re not sure yet. The focus group data isn’t complete.”

Engineering: “A focus group is going to tell us what to call our product?”

Marketing: “No, we gave them a list of 20 different names and they’re going to determine which name strategically distinguishes the product from our competitors by conveying its unique positioning.”

Engineering: “Screw that.”

Knowing that they’d lose a marketing battle with Marketing, but wanting to have some minor say in the name of the product, the Engineers made up a name for themselves. It was their name for their product and you’ll never know many of these names because the engineers just invented codenames.

Codenames are Stories

Product codenames are the mysterious cousins of official product names. They are intended to be disposable and are often designed to obfuscate rather than illuminate. For me, a good codename needs to meet a set of requirements because they define an important and personal part of engineering culture.

These are my rules:

Codenames are chosen by the folks building the product. The people who are building the product are the only ones qualified to pick the right name of the product. If Marketing is picking a codename then you don’t work at a product company – you work at a marketing company. Good luck with that.

The best codenames are emergent and never picked by a committee. When the idea of a product has enough velocity to deserve a codename, start listening for it. It often just shows up. High quality codenames are emergent and there are likely going to be two or three wandering the hallways before one just sticks. Be open to organic codename rejection and never ever call a “let’s name the product meeting”. Just listen.

Codenames have multiple levels of meaning; they tell the story of the product. At my first startup, our platform was failing. We’d built it too fast in an attempt to beat competitors to market, and it was missing essential features. One of our senior engineers spun up a product to address the feature gap and after three weeks we called it “Snowball”.

When anyone learned the codename, they laughed. They laughed because they got it – they knew we had a snowball’s chance in hell of building this product in time. However, they also knew the other intended meaning of the name. They knew of all the engineers on the team, this engineer was the one most likely to produce a product we could build on. He was an architect and he built with expansion in mind. If he was successful, he’d give an initial product that would build on itself – you know – like when a snowball rolls down a hill.

There are bonus points if a codename is “nerd interesting”. A codename usually has nothing to do with marketing. It’s cultural documentation of a product. As such, codenames tend to emerge from the nerd domain of interest. This is less a rule and a more of a “nice to have”, but when a codename meets all the other criteria and remains steadfastly nerd interesting, I mentally clap. Especially since…

Codenames are one word. Exceptions are few and far between. The reason? Efficiency. A codename is chosen as a time saver. My first significant product, Paradox for Windows 1.0, had a great codename “Tsunami”. It met all the requirements: a single word, nerd interesting, and it simply told the tale of what we were attempting to do with the product – there’s something big coming, we’re building the first easy to use relational database to the then-emerging Windows platform. Good codename.

For our subsequent release, we had a codename contest (fail) because the different parts of the the project – the front-end Windows application and the back-end core technology team – each wanted to be represented (lame). We eventually dubbed this new version “Thelma and Louise” which was a fine movie, but a really shitty codename. Say “Thelma and Louise” ten times fast and remember that you picked this name as a convenience… not as a verbally stumbly hindrance.

Never let mechanics pick codenames. The more Vulcan-like on your engineering team are going to want to build structure into your codename process, and as a general rule I think it’s elegant when a codename allows for future codenames that show discernible progress. In a less inspired time, I picked “Redline” as a codename because I was currently fascinated with ice hockey. The subsequent releases had a different lead and he picked Orangeline as the next release name, then yellow, green, blue, indigo, and violet. That’s ROY G. BIV for you wavelength nerds in the audience. Brilliant.

For each engineer who is up to the task of inventing clever and elegant codenames, there are the mechanics who want to beat the living poetry out of them. Resist these engineers. They will have compelling arguments for why calling the release “Q1-A-4” is the right thing to do, but their arguments lack poetry and entirely miss the point.

The Point

Years ago we, the product team used to get boxes that contained the printed documentation and media that came with the first version of the products we built. The Internet has mostly replaced this channel, which means when we’re done with a product we, the dealers of bits, confusingly have nothing to show for it. T-shirts help, but a t-shirt is just a conveyance for an idea, for a name.

Codenames document your product culture and there is an economy to these names. Every single product in your company doesn’t need such a name. My rule of thumb is that a codename designates a product or project of significance. What is significant is entirely up to you, but I know that you will never make a project significant by giving it a codename. If your idea or product is shitty, a codename will never help.