For Starters 18: Just Pick a Name. Any Name.
An essay about Parkinson’s Law. No, the other one.
There’s this great, very long, 7-year old essay on just how valuable a name can become over at Good Beer Hunting on Bud Light. It talks about the lengths corporations go when their billion dollar asset is more a name and less a product.
Back around 2005, two separate conversations with potential business partners fell apart, partially due to a disagreement on what the name of our collaboration should be.
In both cases, the disagreement wasn’t over what our name was, but that we needed to answer that question ahead of determining service offerings, landing clients, even working together on a small project to figure out if we work well together.
So we didn’t. Any of it. That was the answer.
For the next 13 years, many of my client saw my company’s name for the first time on my invoices. Because, as someone that really, really enjoys naming things:
For starters - names don’t matter at all.
Yes - your business entity needs a name.
Yes - your nascent product needs a name.
No - it doesn’t need to be missing an ‘e’ or any vowel. It doesn’t need to be pun. It doesn’t need to be descriptive. It doesn’t need to be SEO-optimized. It doesn’t have to have any meaning. If it does, it doesn’t have to have meaning to anyone but you.
The early success of your venture has nothing to do with the name you give it. It depends on getting paying customers at a sustainable level. There is no brand expectation on day one.
I’m a very big fan of code names, or working titles, for project: names that concentrate the purpose and personality of a project into an economical shorthand for the project’s collaborators to remember what they’re doing and why. I’m even a fan of changing the code name mid-project; either to keep the rest of the org guessing or because the meaning has changed. I also firmly believe the code name is never exposed outside the company walls, maybe not even exposed outside the department walls.
Our internal world has far fewer requirements and concerns on naming than the outside world. The venture will have, must have, a completely different public-facing name. This expectation should be set up front with all collaborators.
Yes, this is as much a corporate security issue as it is a way to allow the internal team to shutter the effort gracefully prior to a public release.
The code name is for the collaborators.
The public name is for the customers.
Properly naming a product for external, public consumption is a project in and of itself. A project with so many potential dead ends it should not be committed to until the product is pushed to prod.
Until then, it’s a form of over-investing and a distraction from generating the kind of overwhelming customer demand we so often talk about in this newsletter.
Too many times to count, I’ve worked with teams so attached to their product’s code name they insisted on going public with it - only for it to bite them in the ass; janky domain name availability, unexpected trademark infringement, confusing against parent brand, confusing against existing product portfolio, too close to a completely different product line the intended customers already buy, doesn’t fit into parent brand.
Ugh.
It’s almost like the problem is so complex there are specialized firms experienced in solving it.
Yes, I’ve facilitated naming exercises for new ventures, half-day efforts where we fill whiteboards with post-it notes on our aspirations for our newborn product, the personality of the product, we pontificate the emotions customer will have when engaging with the product.
Only to have the entire venture nixed in the next round of budget cuts because it didn’t have any revenue.
In retrospect, our time may have been better spent at the beach.
Or selling.
Almost anything other than debating over a name.
P.S. For more naming advice, read David Sedaris’s You Can’t Kill the Rooster
P.P.S Oh, yea, Parkinson’s Law of Triviality: focusing on things that are well understood, rather than what is significant or difficult.