Mario Cardinal

"The real voyage of discovery consists, not in seeking new landscapes, but in having new eyes" – Marcel Proust


Leave a comment

Minimum Lovable and Marketable Product

In this post, I explain why the first version of DayTickler must not only be lovable but also a marketable product.

Following my last post some readers were surprised that we will take almost nine months to produce a minimum viable product (MVP). According to Wikipedia, a minimum viable product (MVP) is the product with the highest return on investment versus risk. Usually, a MVP only has those basic features that allow the product to be deployed, and no more. The product is typically deployed to a subset of customers (early adopters) that are supposed to be more forgiving, more likely to give feedback, and able to confirm a product vision from an early prototype. As stated by Eric Ries in his colloquial book The Lean Startup, “The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

heart and dollarAt this stage in our product development, we seek to validate whether customers will agree to subscribe to the premium version of DayTickler. As we aim to market to consumer in an already mature market (there are already over a hundred to-do app), we can hardly launch a product that would be perceived as incomplete. We need to polish the software to the point of making it lovable, and this requires time. Furthermore, it must have all the necessary features to make it marketable. In our case, this requires building not only the core of the product but also the main feature that will convince customers to subscribe and pay for the premium version. This means that the product cannot be a prototype and this takes work. Especially that while building the product, at the same time, we continue to do consulting. Here’s why the construction of the MVP is so demanding and requires more than 9 months.


1 Comment

Minimum Lovable Product

In this post, I am providing a progress status on the development of DayTickler.

For more than seven months, with my business partner Erik Renaud, we are currently building the first version of DayTickler, a mobile app to plan your “Today Schedule”. It’s going well. By the end of August, we will have a Minimum Viable Product (MVP) ready for launch in the app store. The process may seem long but we must ensure that our first version will be a minimum lovable product.

As noted on twitter by Jussi Pasanen, building a MVP is much more complex than programming a few scattered features. This is a wise mix of a functional, reliable, usable and emotional design.minimum-lovable-product


Leave a comment

Speaking at the Ottawa IT Community

For those of you living in the Ottawa area, Thursday night (April 9th), I will make a presentation at the Ottawa IT Community.  This event is free and takes place at the Ottawa Microsoft Office. I am speaking at 17h45.

I will do a talk about “A Personal Perspective on Designing Mobile Applications”.  For those of you who follow this blog, you know that I am involved in the design of DayTickler, a personal task manager for Apple IOS, Google Android and Microsoft WP8. During this presentation, explore with me what I learned during this unique journey.

http://www.meetup.com/ottawaitcommunity/events/209125852/


Leave a comment

What’s in a Name

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.


Leave a comment

Freemium apps for our business model

Making money with a mobile application is not an easy thing. Gartner is forecasting that, by 2017, 94.5 percent of mobile downloads will be for free apps. They even predict that through 2018, less than 0.01 percent of consumer mobile apps will be considered a financial success by their developers.

Yes, they forecast that only one (1) out of 10,000 developers will make enough money to survive and stay in business. Slingboards Lab (my start-up company) want to be part of the survivors. This is why, last summer, even before starting the development of our mobile app, we have clearly defined a compelling business model.

Our business model is the fundamental way that we plan to make money from our application. Since we do not have thousands of loyal customers, an established brand or something very special and desirable, we believe that the model of paid apps is not sustainable for our environment. In addition, in 2013, only about 10 percent of mobile applications in the Apple app store have been paid, and this percentage has been declining for years. For these reasons (rational justification), and especially because we liked the idea of offering free software (emotional justification), we opted instead for the model of freemium apps.

Free + Premium = Freemium

Freemium is a business model in which you give a core product away for free to a large group of users and sell premium features to a smaller fraction of this user base.

Freemium-300x206The goal is to offer a fantastic product with limitations. The basic feature will be satisfying to the point that customers can remain on the product for free. However, because we will offer outstanding user experience, we believe that with time they will be hungry for more – seeking out the paid product to enhance their experience and broaden their engagement with our services.

A common misconception is to believe that all business models that involve the use of free products are freemium models. There are three other business models centered on a free product, which are commonly used; direct cross-subsidy, ad-supported and gift economy. Chris Anderson’s wrote a great post about the four kinds of free.

If you are planning to build and launch a mobile application for the consumer market, attracting users and keep them “hooked” is what you should be concerned with. Business success will depend on raving fans, customers who will buy the premium version of your software.  In 2014, mobile apps with freemium models account for 98% of the revenue in the Google app store and 95 % in the Apple app store. With such facts, and because we will be competing with free anyway, it seems that only a freemium business model can emerge with success.


1 Comment

We are building our mobile app with Xamarin.Forms

Sixteen months ago, I wrote on this blog that if a startup has to build a mobile application, the entrepreneurs should never go native. At the time, there were only three options for building a mobile application:

  • Build three different native applications: Native apps are specific to a given mobile platform and are built using the development tools and language that the respective platform supports (e.g., Xcode and Objective-C with Apple iOS, Eclipse and Java with Google Android, Microsoft Visual Studio and C# with Windows Phone).
  • Build an HTML5 application: HTML5 apps use standard web technologies—typically HTML5, JavaScript and CSS. This write-once-run-anywhere approach to mobile development creates cross-platform web page that work on multiple devices by mimicking the native user control behaviors.
  • Build an hybrid application: Hybrid apps make it possible to embed HTML5 apps inside a thin native container. Hybrid apps combine the best elements of HTML5 app but, unfortunately, they do not provide a native user experience.

Since last spring there is a new option:

  • Build native applications with Xamarin.Forms: With a C# shared codebase, Xamarin.Forms is a cross-platform development tools that enable to easily create user interfaces that can be shared across Android, iOS, and Windows Phone. The user interfaces are rendered using the native controls of each the platform, allowing to retain the appropriate look and feel for each platform.

xamarinThe option proposed by Xamarin seems very promising, especially since this company is not a newcomer. Xamarin was founded in 2009 by the instigators of the Mono project. Xamarin.Forms is the result of five years of work to build a cross-platform natively backed UI toolkit abstraction for mobile development. This is a serious player in the mobile arena. In fact, last week they held their annual conference in Atlanta. With over 1,200 registered developers, the event was not only sold out but also the largest cross-platform mobile development event.

Why all the interest about Xamarin? Probably because there is a growing awareness in the industry that when it’s time to write a mobile app — something interactive, not just a document with some hyperlinks, the Web is a second-class option. I was not surprised to read this week that Tim Bray lamented that the mobile apps are leaving Web work in the dust. The reality is quite simple, native rendering is important and the three major mobile platform vendors (Apple, Google and Microsoft) are embedding this feature in their proprietary operating system not in the open Web browser.

For those of you who follow this blog, you know that in recent months we have repositioned our startup and that we are currently building a personal task planner for smartphones. Following the above arguments for Xamarin, what development tools do you think we chose to build our mobile app? The very nature of a startup is that you have little money and need to be super fast on the market to validate your assumptions (and discover that you’re wrong). On the other hand, because the apps are the natural structure for mobile experience, I think native rendering is mandatory. So there is only one logical choice. Do we think that everything will be perfect and really easy with Xamarin? No, but we are confident that in the next 12 months we will not regret our decision. Anyway, if Xamarin proves unsustainable and our product is a success, then we should have the resources to rewrite the application with another option.


Leave a comment

Getting a sense of fulfillment

I just finished Windows 8.1 UX Design Jump Start online training on the Microsoft Virtual Academy. One of the major learning from this training is to focus on the “less is more” approach. This approach was adopted by the architect Ludwig Mies van der Rohe as a precept for minimalist design.

In the “less is more” approach, it is essential to establish the “Great at” statement.  This involves defining in one sentence what truly differentiates your software from the competition. Your product should focus on the scenarios and features that deliver on that greatness. Nothing more, and nothing less.

Hooked-How-to-Build-Habit-Forming-Products-220x222For several years, I thought that limiting scenarios and features to support the “Great at” statement was the main justification for creating this statement. A book that I read last spring has totally changed my understanding of what is a “Great at” statement. This book is Hooked: How to Build Habit-Forming Products.

This book provides a fascinating process for creating products and technologies based on human psychology, persuasion, habits, needs, etc. It describes the techniques you can use to keep the users of your software coming back to it frequently. This book covers the psychological side of business, but does so for the modern tech entrepreneur and business owner, not for the modern psychologist.

When building a habit-forming product, start with the source of emotion then build the product around one habit that fulfill this emotion. Hooked is not only about making things into a habit, but it’s also about where to make things seamless, where to give a variable reward, and how to pull people back to your product through action triggers. I’ve never read a book that covers all of these subjects so well.

Cognitive psychologists define habits as, “automatic behaviors triggered by situational cues.” In this book, you will learn that building a habit consists of four parts: the trigger (make the user realize they must take action), the action (should be easy to achieve), a variable reward (keeps them coming back), and investment (leading people to engage and create value, which keeps them coming back).

After reading this book, I changed my approach to defining the “Great at” statement. Now, I start with the source of the emotion (eg, pain, joy, fear, etc.) – then I build the product around it (and not the other way around). I write the “Great at” statement from the point of view of the users, what they feel, and how the product will fill the emotional need they have.

In a previous post, I explained that the concrete measures and tasks presented in this book had greatly helped us during our last pivot. At the end of the pivoting process, after deciding to build a personal task planner, we developed the following “Great at” statement:

  • Our product is great at getting a sense of fulfillment.

Our goal is to reproduce the positive emotion that makes you happy when you get an achievement. Our personal task planner provides a sense of fulfillment when a user acknowledges, commits and achieves a task. The scenarios and features must support this emotion. This is the narrative frame of our product.

In closing, I highly recommend reading Hooked: How to Build Habit-Forming Products. It’s a fascinating book, well-written read, and honestly – if you have a startup it’s a requirement on your reading list.