“What’s in a name?” A famous question that is as relevant today as the day it was penned. There are a few things that are completely in your control when you think about starting a business or kicking off a new project, and the name that you select is one of them. It never ceases to amaze me how few people give the name selection process the attention it deserves when they are commencing.

There once was a time when you could take a product almost all the way to the finish line and come up with your name then. The companies who really understood marketing and brand management would spend considerably more time on this exercise, but some of them are the worst offenders when it comes to coming up with names. More often than not, what they would bring to market is a line extension, utilizing some portion of an existing brand (i.e. Coke Zero, Miller Lite). They successfully bi-furcated the target market, and end up losing cumulative share.

The Internet changed the importance of a name in a few ways that may not be immediately obvious when you are thinking through a name, but are exceedingly obvious when you hear them said out loud. The discovery process that consumers go through today for information about your product or company will most likely (I really want to say “absolutely will”) begin with a search engine. Thus the question, “what’s in a name?” Perhaps a more contemporary version (much to the horror of Shakespeare lovers around the world) is “how Google-able is your product?”

A great example of this is a language invented by Anders Hejlsberg, and released by Microsoft in 2000. Initially, the code name for C# was “Cool” (supposedly for “C-like Object Oriented Language”), but in an effort to tie the language to the anchor brand of the C programming language, Microsoft opted for “C#” – pronounced “C sharp.” The only problem with this is at the time, the “#” character was a non-allowable character for search engine crawlers. They ignored anything after the “#” because the “#” is used for HTML to mark an anchor on the page. Further, at the time, most search engines ignored the “#” as an input character on the search page. This meant that anyone typing “C#” into a search engine would get a search for “C,” as the search engines would strip out the “#” character. Worse, not only would customers be confused if they found links to the older “C” programming language, but what if they were presented with stock information for Citibank, whose NYSE stock ticker is “C?”

Imagine how frustrating this must have been for anyone who heard about this cool new language and immediately went to the search engines to get more information. Sure, the year was 2000, so search engines were still new-ish, but the primary consumer of a new programming language, especially in 2000, would certainly be search engine savvy. The search would have come up empty, or, worse, pointing to many non-relevant sites.

Further compounding this naming gaffe is the fact that the character “#” is not usable in a URL. What? In plain English, Microsoft could not have the URL “http://www.microsoft.com/c#”. The “# is supposed to represent an anchor within the document, but without addition text after the “#,” the URL doesn’t work. Failing in finding the information in a search engine, a customer might try to simply tack the name of the new product on the end of the company domain. Again, the tech savvy customer who would be seeking this information would be stymied in their attempts. Even today, in 2009, this URL fails.

Typing “www.microsoft.com/c#”

What’s interesting about this is that even today, the Microsoft search box throws out the “#” for the customer. You can see this by looking at the search term presented on the lower left. As you can see, because the URL failed, Microsoft conducted a search for what came after the dot com, and thinks I was looking for “C.” With this as a failure, a customer might spell out “csharp” and find that the URL www.microsoft.com/csharp comes up empty:

Typing in the URL “www.microsoft.com/csharp”

Unbelievably, they repeated this error in 2005 with their new language F#.

When we first started IMSafer, the name wasn’t IMSafer. In fact, that name was more of a serendipitous discovery than anything else. The original name of the company was Collabarent. I was trying to be cute, and was hoping to convey the concept of parents collaborating. It’s a pretty awful name. Tough to spell and even harder to say if you aren’t ready for it.

One of the design principles of the product was meant to harness the collective wisdom of the parents using the system. We weren’t really clear what problem we were trying to solve other than taking on the “parental controls market.”

The challenge put to me by Tommy, my VP of engineering and co-founder, was that we didn’t have any focus. Without focus, and a clearly laid out problem set, there was a good chance that we would try to do too many things, and in fact do none of them well. The name I had chosen had pretty much demonstrated that sentiment.

Tommy took the challenge one step further and suggested that we really ought to spend time thinking about the core problem set, the impacted customers, the feelings we wanted to evoke from those customers, and see if a name would evolve. We set forth the following requirements: The name had to be:

1. “Google-able,”
2. Memorable
3. Not confusing with other products in the market
4. Immediately convey the purpose of the product

We also needed to ensure we could get the domain. You must always, always, always get the domain, and it must be a “.com.”

I want to take a quick moment to hit this point about domains really hard. Don’t underestimate the need, nay requirement, for a .com address. When Microsoft first shipped their Zune player, they didn’t own Zune.com. They do now, but at the time, it was www.zune.net. The same story played out for their Silverlight technology, except that Microsoft still doesn’t own the .com URL.

How many respectable or popular businesses do you know of that have a “.net” URL? Very few. The opportunity cost in terms of lost traffic and customer mindshare is pretty high, especially if there are two commas in your marketing budget. This problem is further exacerbated should your product or company have any level of market success and you decide that you are going to procure the .com address if it’s being squatted. Your market success will have the perverse effect of driving up the price for the .com version of your domain.

Back to Collabarent. With the above guiding principles in mind, we set about on an exercise to enumerate the problem sets we wanted to tackle, list out our customers, and decide what feelings we wanted to evoke. The final test for any proposed name was whether or not GoDaddy told us the domain was available. We came up with a bunch of names, but for one reason or another, the each failed the tests above. Finally, Tommy said, mostly out of frustration, “I just want parents to know their kids can IM safer.” I remember my first thought was that there was no way that domain was available. The likelihood of any seven letter domain comprised of any real words being available in early 2006 was pretty low. IMSafer.com was available. Unbelievable.

Sounds like we had a winner, right? Sort of. There were two problems which wouldn’t present until much later in our cycle. First, my board of directors, and many people we spoke to, often dropped the “r” from the name, and were convinced we were “IMSafe.” We did not own that domain, and spent a good deal of our time correcting people. We failed the rule of not testing the idea with enough people. Had we done that bit, we would have discovered this issue.

Second, the “IM” part of the name had the potential limiting effect on design and product direction. Company versus product name is a discussion for another essay, but it’s something to keep in mind when you are thinking about your company and your product portfolio. By adopting the name of our flagship product for the company name, there was a potential branding issue down the road should we have decided to broaden the scope of the company.

We had a similar problem at AskMe.com. When we started the company, it was known as “Xpertsite.com.” Yes, we spent a good deal of our time repeating the following, in one form or another: “no, w-w-w-dot-x, no e, p-e-r-t-site.com.” Very annoying, and distracting for potential customers. When we switched to AskMe.com, we spent a lot of our time explaining to people that we weren’t Ask.com the search engine. To this day, when I tell people that I worked for AskMe, some people tell me that they “use that search engine.”

The moral? First, make sure that you have a name that can be found in a search engine, and is unique enough that you are not going to get lost amongst the information about irrelevant products. Second, make sure that your name is not only easy to remember, but that it won’t get confused with some other existing product which already occupies some spot in the mind of your potential customer. Third, it helps if the product name immediately conveys purpose or relevance to your target customers. Lastly, make sure you can get the domain name, and make sure it’s a .com.

I don’t know about you, but many times when a supposed flash of brilliance hits me, I believe I have the mental equivalent of gold. I tend to get a bit ahead of myself, and start thinking about all of the money that I am going to make, what the product is going to be, how much customers are going to love it, how I am going to sell it, and who is going to buy it. Somewhere in the middle of that process, I start designing the product; making decisions about the absolutes of what the product will and won’t be.

You will find that your first idea is seldom your best one. This is true along two separate axes. First, if you spend any incremental time on design and storyboarding, you are likely to improve upon the original idea in immeasurable ways. Second, if you start letting your mind wander, you may come up with a completely different product/solution that addresses the same need, either directly or tangentially, and does so in a far better way than your first idea.

Just as the notion of testing your idea with only one person is a guaranteed recipe for fail, using yourself as the sole testing point will likely land you in a situation where you could potentially create something that no one will want. This is especially true if you just start building the first thing is that pops into your head.

Building is something that you should only be taking on after you have thought through what it is you are hoping to accomplish. Let your thoughts percolate for a little. Then let them simmer. I’m not talking about taking weeks or months, but don’t be afraid to let an idea sit for a day or two before you act.

Further, if you have a set of people you trust to not crap on your ideas, you will find that the simple act of trying to describe what it is that you want to do will reveal cracks in your idea. If you can’t explain it, you probably shouldn’t be building it. Even if your colleagues don’t buy into the concept, it’s likely that they will ask questions which will force you to think about what it is you are actually trying to do, and whether or not you are accomplishing that goal.

How many times have you said “I know what I want to say, I just don’t know how to say it?” My eighth grade English teacher would beg to differ. If you can’t explain it to someone else, why do you have any reason to believe that your translation of what’s in your head to an actual product will make any more sense? A great example of this is a focus group. If you have ever sat in a focus group, there’s a high probability that in your head you were screaming something along the lines of “why are you doing that you stupid customer?!?! You’re not supposed to use it that way. No!!!!” The physical instantiation of your idea is simply a representation of your ability to explain what it is that you wanted to do, and if you can’t explain it, you certainly can’t build it.

When I first came up with the idea for IMSafer, the product concept was to have a local program running on a computer doing all of the language analysis, and to have the code based on an open source product called Snort. IMSafer was envisioned as a program which was supposed to trap all of the traffic on a local home network, and perhaps even talk to the house router/cable modem. In not thinking through the idea, and not sharing the idea with anyone, I started making design decisions that were terrible. Awful, actually.

The team and I spent some afternoons and nights at the local Starbucks during the very early formative days of IMSafer, and just the exercise of trying to explain to them what I was trying to do showed me that I was designing something that not only would not scale (that’s a fail), but would also fail the grandma test (“can grandma install and use this?”). There was no way to make a customer friendly and easy to install piece of software doing it the way I originally wanted to do. Here’s a useful tip: any time you have to use the words “network” and “configuration” in a product intended for home use – fail.

It was clear from just the first conversation that we needed to vastly simplify the product, and that meant changing where the code lived. It also meant removing the number of moving parts from the customer computer. Our target customer was a parent in their late 40s to early 50s, and at the time we started IMSafer, that particular demographic was not the most technically savvy. If I had just rushed headlong into development, I would have either made design decisions which would have destined the product to failure, or would have cost me a great deal of time, energy, and effort to redesign when we finally figured out that what we had built was wrong.

All of this reminds me of an old joke that I love:

There’s an old bull and a younger bull sitting on a hill. The younger bull says, “Look at all those cows. Let’s run down and shag one of them.” The older bull ponders this for a moment, considers his answer carefully, and says, “How about we walk down and shag them all?”

The moral? If you take your time and think through what you are doing, you will more than likely get an optimized result.