The power of a name and its value has long been immortalized in prose, poetry, and religious ceremony. Everyone recognizes the things around them by name. Naming a product is important. This post explains why the name of our software is DayTickler.
A name is a word or combination of words by which an entity is designated and distinguished from other. You can hardly promote a product and expect it to bring huge benefits if its name bears no relevance to the target market. Contrary to Shakespeare's belief that That which we call a rose by any other name would smell as sweet, the answer to the question "What's in a name?" does not apply here. A name can make a large difference in the perception of what a product should be and how it should function.
For those of you who follow this blog, you know that in recent months we have repositioned our startup Slingboards Lab and that we are currently designing a personal task planner for mobile phones. We are currently building a first version of the software. We plan to market it as a freemium application through the apps store of Apple, Android and Microsoft.
The importance of choosing the right name for software is not to be taken lightly. Not only the name of your software is an important part of its "business card" on the web and in the apps store, but the name will enable customers to remember your product. This is about making your name talk-able. An easy name will make it easier for current users to refer your name to others. It is very well known that advertising is not a trustworthy marketing tactic as much as word-of-mouth. The name is probably the first thing prospective customers will find out about your application. It is a good way to differentiate yourself from your competition.
We chose the name DayTickler. Not only it is talk-able and the domain name was available, but it clearly explains what differentiates our application of the hundred Todo apps that already exist on the market. First, it was important to have the word "Day" because our product is a daily planner. Second, we choose the word "Tickler" because it is a device that serves as a reminder and is arranged to bring matters to timely attention. But that is not all, a tickler is also a device that make someone laugh by lightly touching a very sensitive part of the body. Our product is different from competitors in that it allows to easily team up with your family and friends to achieve your todos. We can imagine that the action of chatting and collaborating online with your close ones looks a bit like the pleasure of being "virtually" tickle.
In this post, I explain why the value proposition of the first version of the Slingboards Lab home page was not clear.
An entrepreneur is a creator. One of the challenges that awaits every entrepreneur is to succeed creating simple things with only one responsibility. Everything an entrepreneur creates should do one thing, and no more. In software architecture, we call this rule the single responsibility principle. I learned it many years ago from Robert C. Martin. In object-oriented programming, the single responsibility principle states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. Another way to state this principle is to say that a class should have one, and only one, reason to change.
I am reminding you of the single responsibility principle because, lately, I've broken this rule. It happened when I created the first version of Slingboards Lab home page.
I discovered the problem in the following days when I started testing this page with professional developers. I was mixing two very different messages. On one hand, I was trying to explain what a collaboration board is, and on the other hand, I was presenting our programming platform. Worse, I was using the word "slingboard" and the word "Collaboration boards" to express the same concept. To say the least, the value proposition was not clear. In addition, continuing my tests, I found that the primary customer segment for our product are the team leaders and not the professional developers.
Obviously, I quickly rebuilt the home page to improve our message. As expressed by my partner Erik Renaud: fail fast and learn quickly. Refactoring the website keep me busy most of my time last week. Now our Home Page has only one responsibility which is to present slingboards to team leaders. I transferred all the content that is intended for developers in the Developers Page.