In this post, I am providing a progress status on the development of DayTickler.
As I wrote last June, the first version of DayTickler (the one that we will officially published in the app store) must be a lovable and marketable product. Because we aim at validating if a product/market fit is obtained, we must avoid publishing a prototype.
A prototype is perfect to test for usability because it allows evaluating facts. However, it fails miserably for evaluating usefulness. It is not the appropriate tool to validate the degree to which a product satisfies a strong market demand. As stated by Laura Klein in the article Building the right thing vs. building the thing right, “you can’t use a prototype to learn if you are building the right product.”
The right product is a product that does what we imagined, but it is design so it has what customers really want and need in a form that is easy to use and atheistically pleasing. In order words, the right product is a product that is built “right” or at least “right enough”.
However, as Ron Jeffries wrote in 2014, “You can't build the right product if you can't build the product right.”
Therefore, in June and July, we continued to validate our design with prototypes. As always, we are learning to be humble. Obviously, some of our assumptions were wrong. We found serious problems with the user experience. At such a point that we spent the last month redesigning our application. The good news is that our recent prototype tests are conclusive. We are on the right track.
When will you have access to DayTickler in the app store? Not until November. We must build the product "right" and to reach that goal we need to do more usability testing.
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."
At 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.