Lessons from three million downloads on the AppStore
In January 2011, I had summer holidays [developer from the southern hemisphere, namely from New Zealand - comment.], But instead of looking for work for a day or talking to people, I hid from everyone in my room, where I wrote the first the iOS version of the application called Class Timetable. A year earlier, I was looking for a simple, easy-to-use application for training schedules, and nothing in the AppStore did not fit my needs - everything was difficult and difficult to use. The idea was to create a simple, straightforward, straightforward solution, something simpler and more convincing than a paper schedule. For several months I spent about 500 hours designing and coding it. Today, the program has more than three million downloads, a lot of positive feedback, and at times it was my main source of income. Have not heard of the application? Yes, it has not yet taken off in the US, but is quite popular in Australia / New Zealand / UK, at least among college students and schoolchildren.
Recently, I read a lot in blogs about people who hit the jackpot, their programs got into favorites and they look at numbers like 100,000 downloads per day. Compared to them, I am only moderately successful. Class Timetable never hit the first place of the AppStore, I did not become rich in a day, I had more failures than successes. I spent a lot of time, probably thousands of hours, unlike some hit apps created over the weekend. Of course, three million is a lot, but they have accumulated over more than six years.
')
Unlike the jackpot, my story of “moderate success” is closer to hard work and slow, gradual progress. It’s probably closer to real life than other success stories, because let's face it: not everyone gets going, creating the next Flappy Bird. Instead of shooting like a viral hit, the Class Timetable has been moderately popular for over six years, which is a bit remarkable in itself - many # 1 apps cannot boast such a long life. I would like to share some of the things that I have learned over the past few years. I hope you find some of this useful, no matter how successful you are or not.
I still think that some of them were great ideas - maybe they didn’t have enough good progress or a bit of luck. It was an application Ginge-O-Meter, in which I put a lot of effort. Concept: take a picture of someone and determine how much red in his hair. It used real image recognition and color analysis techniques to produce a response, and actually worked (almost always). Unfortunately, the idea did not take off ... I think I earned about $ 50. This was my first big attempt, and to be honest, I was rather alarmed by how much effort I put into the application to end up with such a failure. But I didn't stop at that, and the Class Timetable evolved into what we have now. In any case, I want to say that you do not need to put everything on one bet. If your winning idea is not successful: get up and try again and again ... and again, because all you know is that your next idea can do it.
Imagine that you received a letter in all capital letters, which says that your application is stuck at the installation stage and you need to fix it ... such a disappointment, isn't it? After several such emails, you realize that you can never make your product easy enough to use. What I learned (except that I plunged into the ice hole and found the strength to respond kindly) is that the product needs to be developed as if the person will use it a step lower than the representative of the target audience. Keep it simple, implement protection from the fool - design everything for a beginner. Check that nowhere can you get confused and that every task is absolutely unambiguous, that everything is done simply. Less time will be spent on support, people in general will be happier with your product, and your ratings will go up.
When Class Timetable first started with thousands of downloads per day, I received about 20 emails per week. I am sure there were other users with the same problems that did not make it difficult for them to write a letter, but simply deleted the application. Having improved the program according to the complaints from the letters, I now went to the level of one letter every two or three days - and most of them are not about problems, but with a suggestion of features or rare letters from fans (I'm not lying).
Probably, I received hundreds of letters from users with a proposal to implement various functions, from really good to dubious proposals. But now, if I implemented all these functions, the application would turn into an incomprehensible mess, with 17 background selections, 72 other features distracting on the screen, and a list of settings for literally everything. Damn, even if I implemented every sensible idea, the result would be quite different. The fact is that even if users see the true problem with the product, they do not always know the best solution. So what to do? Listen to your users - their true, original problems - and solve them so that it is useful for the product as a whole. Sometimes a good offer of features has side effects for the product as a whole, and this means that it’s better to skip. This often happened with the Class Timetable: one of its main qualities is simplicity and ease of use. Although many features have been added over the years, many feature suggestions would have complicated the product as a whole. Sometimes this is normal, but more often I chose simplicity - the feature that makes this application unique.
Class Timetable never got to the AppStore main page and did not receive 100,000 downloads per day - but I do not care. Some applications reach the first place in the charts only to turn into a lifeless desert earlier than in a year. Perhaps they had some funny spark, a viral marketing strategy, or they were just lucky - but in the end, they had no content and they did not solve the real world problem in a meaningful way. By making a truly good product instead, you are designing something that users will come back to again and again. Make an effort where people may not even notice. Concentrate on solving real problems and make the product so that it will be really useful for users to come back and bring others along. Returning users are a good sign of the utility of the product. As a bonus, there is a small viral effect inherent in each user, and indeed it is nice to know that each new user is not just a replacement for the deceased.
When Class Timetable first appeared in the AppStore, it cost $ 1. I calculated that for the time I spent (about 500 hours), $ 1 is a freebie. So, in the first week, four people bought the application, and even less for the next week. I do not know what kind of feelings a person who hit the jackpot, but I did not have such sensations. 500 hours is a lot of time to flush down the toilet! I could have left him to die a slow death of one dollar a week, but instead decided to make the application free. I created it to solve a real problem and thought that others would find it truly useful. Almost immediately, downloads began to grow. 50 downloads per day, then 100, 1000 ... wow. If I took into account the number of hours spent and was not generous, I very much doubt that the downloads ever started at all. Soon after this, I added the function of intra-program purchase of additional functions, which had already begun to bring reasonable money. Much more than a few dollars a week. So do not be stingy: a product without paid users is (usually) better than a paid product without users at all. It is much easier to get paid from existing users than to attract a completely new paid user.
Sometimes you are stuck with a problem, and there are no good solutions: it could be related to the code you write, or to the decision how to promote the application. And then you start thinking about the problem in a broad sense. You realize that this tricky piece of code doesn’t need to be written at all if you design the program correctly, and one of your friends who has the talent to solve such problems will solve the marketing problem. This can be described as a “step back” from the problem. In my entire career as a developer, I did not regret a second when I did this. Many times, especially at the beginning of my career, I should have done this, but I did not. I walked the hard way with Class Timetable: in version 1.0, a lot of time was spent when I came to a dead end, but gritted my teeth with my teeth. I solved tricky problems by cutting corners and realizing my plans instead of taking a step back. As long as users do not know, there is nothing shameful about it, right? After a year or two, we had to rewrite the entire code base from scratch - for many reasons - which became a serious undertaking. Take a step back! It's worth it.
Today Class Timetable still feels good. I always make plans, be it the nearest update for iOS or global plans, what the program can turn into. If you're in school or college, feel free to try the Class Timetable - I hope you find it really useful.
Recently, I read a lot in blogs about people who hit the jackpot, their programs got into favorites and they look at numbers like 100,000 downloads per day. Compared to them, I am only moderately successful. Class Timetable never hit the first place of the AppStore, I did not become rich in a day, I had more failures than successes. I spent a lot of time, probably thousands of hours, unlike some hit apps created over the weekend. Of course, three million is a lot, but they have accumulated over more than six years.
')
Unlike the jackpot, my story of “moderate success” is closer to hard work and slow, gradual progress. It’s probably closer to real life than other success stories, because let's face it: not everyone gets going, creating the next Flappy Bird. Instead of shooting like a viral hit, the Class Timetable has been moderately popular for over six years, which is a bit remarkable in itself - many # 1 apps cannot boast such a long life. I would like to share some of the things that I have learned over the past few years. I hope you find some of this useful, no matter how successful you are or not.
Before writing an application that “did it,” I wrote a lot of things that didn't
I still think that some of them were great ideas - maybe they didn’t have enough good progress or a bit of luck. It was an application Ginge-O-Meter, in which I put a lot of effort. Concept: take a picture of someone and determine how much red in his hair. It used real image recognition and color analysis techniques to produce a response, and actually worked (almost always). Unfortunately, the idea did not take off ... I think I earned about $ 50. This was my first big attempt, and to be honest, I was rather alarmed by how much effort I put into the application to end up with such a failure. But I didn't stop at that, and the Class Timetable evolved into what we have now. In any case, I want to say that you do not need to put everything on one bet. If your winning idea is not successful: get up and try again and again ... and again, because all you know is that your next idea can do it.
Create a design for a newbie
Imagine that you received a letter in all capital letters, which says that your application is stuck at the installation stage and you need to fix it ... such a disappointment, isn't it? After several such emails, you realize that you can never make your product easy enough to use. What I learned (except that I plunged into the ice hole and found the strength to respond kindly) is that the product needs to be developed as if the person will use it a step lower than the representative of the target audience. Keep it simple, implement protection from the fool - design everything for a beginner. Check that nowhere can you get confused and that every task is absolutely unambiguous, that everything is done simply. Less time will be spent on support, people in general will be happier with your product, and your ratings will go up.
When Class Timetable first started with thousands of downloads per day, I received about 20 emails per week. I am sure there were other users with the same problems that did not make it difficult for them to write a letter, but simply deleted the application. Having improved the program according to the complaints from the letters, I now went to the level of one letter every two or three days - and most of them are not about problems, but with a suggestion of features or rare letters from fans (I'm not lying).
Listen to critics, but don't do what they say.
Probably, I received hundreds of letters from users with a proposal to implement various functions, from really good to dubious proposals. But now, if I implemented all these functions, the application would turn into an incomprehensible mess, with 17 background selections, 72 other features distracting on the screen, and a list of settings for literally everything. Damn, even if I implemented every sensible idea, the result would be quite different. The fact is that even if users see the true problem with the product, they do not always know the best solution. So what to do? Listen to your users - their true, original problems - and solve them so that it is useful for the product as a whole. Sometimes a good offer of features has side effects for the product as a whole, and this means that it’s better to skip. This often happened with the Class Timetable: one of its main qualities is simplicity and ease of use. Although many features have been added over the years, many feature suggestions would have complicated the product as a whole. Sometimes this is normal, but more often I chose simplicity - the feature that makes this application unique.
Great product is better than viral tricks.
Class Timetable never got to the AppStore main page and did not receive 100,000 downloads per day - but I do not care. Some applications reach the first place in the charts only to turn into a lifeless desert earlier than in a year. Perhaps they had some funny spark, a viral marketing strategy, or they were just lucky - but in the end, they had no content and they did not solve the real world problem in a meaningful way. By making a truly good product instead, you are designing something that users will come back to again and again. Make an effort where people may not even notice. Concentrate on solving real problems and make the product so that it will be really useful for users to come back and bring others along. Returning users are a good sign of the utility of the product. As a bonus, there is a small viral effect inherent in each user, and indeed it is nice to know that each new user is not just a replacement for the deceased.
Be generous
When Class Timetable first appeared in the AppStore, it cost $ 1. I calculated that for the time I spent (about 500 hours), $ 1 is a freebie. So, in the first week, four people bought the application, and even less for the next week. I do not know what kind of feelings a person who hit the jackpot, but I did not have such sensations. 500 hours is a lot of time to flush down the toilet! I could have left him to die a slow death of one dollar a week, but instead decided to make the application free. I created it to solve a real problem and thought that others would find it truly useful. Almost immediately, downloads began to grow. 50 downloads per day, then 100, 1000 ... wow. If I took into account the number of hours spent and was not generous, I very much doubt that the downloads ever started at all. Soon after this, I added the function of intra-program purchase of additional functions, which had already begun to bring reasonable money. Much more than a few dollars a week. So do not be stingy: a product without paid users is (usually) better than a paid product without users at all. It is much easier to get paid from existing users than to attract a completely new paid user.
Take a step back often
Sometimes you are stuck with a problem, and there are no good solutions: it could be related to the code you write, or to the decision how to promote the application. And then you start thinking about the problem in a broad sense. You realize that this tricky piece of code doesn’t need to be written at all if you design the program correctly, and one of your friends who has the talent to solve such problems will solve the marketing problem. This can be described as a “step back” from the problem. In my entire career as a developer, I did not regret a second when I did this. Many times, especially at the beginning of my career, I should have done this, but I did not. I walked the hard way with Class Timetable: in version 1.0, a lot of time was spent when I came to a dead end, but gritted my teeth with my teeth. I solved tricky problems by cutting corners and realizing my plans instead of taking a step back. As long as users do not know, there is nothing shameful about it, right? After a year or two, we had to rewrite the entire code base from scratch - for many reasons - which became a serious undertaking. Take a step back! It's worth it.
Today Class Timetable still feels good. I always make plans, be it the nearest update for iOS or global plans, what the program can turn into. If you're in school or college, feel free to try the Class Timetable - I hope you find it really useful.
Source: https://habr.com/ru/post/331466/
All Articles