The 13 things we have learned from the failure of our app
In 2009, with a colleague, we developed an Android run tracking app, CoolRunner. It was stuffed with interesting features, as a matter of fact, it knew more than any other run tracking app in 2009 and 2010. We were proud of it … and we failed; we barely had any users, and we made only a few dollars.
These are the things we have learned from the failure of our product:
13.
You need to have a strategy to build trust because people won’t pay a penny to you if they don’t trust you. In 2009 September we released CoolRunner v1.0.0 as a paid app for $0.99, and there were just a handful of people who of people who were brave enough to pay for something they had never seen working, to a group of people (us) whom they did not know and could not be sure that they’d maintain the app.
12.
Focus on the users first; aim for having a large (and increasing) active user base. After you have it, you can figure out how you can monetize it.
11.
You can make more money from ads than from paid products and services. Well, it is a no-brainer today, and it might have been a no-brainer in 2009, but as B2B developers, we could hardly imagine how could we make money if the users don’t pay for the product. Then around the end of 2009, we learned that there is something, called AdMob. But we had no strategy how to increase the user-base, our brains were wired by the B2B world, where the product with more features and lower prices won.
10.
Have the first release as fast, as possible. How fast? We have been writing the code of the first version for 9 months, but we could have released something that could have the features 3/4 of the runners need in 4–6 weeks. So let’s say, aim for having the first release in 6 weeks, latest, but it is way better if you can have it in 5 days. Had we knew this, the would have learned earlier many things, for example, that the app should be free, and it should be structured differently, and …. Many things.
9.
The first release should provide the bare minimum what the potential users may need, nothing more. What is the bare minimum in this context? A minimal feature set which is useful enough for the users to use the app again and again. That feature set changes from users to users, you may say. Yes, you are right, but that it another learning point (see 5). If you stuff your first release with various features as we did, you will lose valuable time and you won’t learn fast enough, and you will, most probably, not properly address their needs.
8.
Have a (viral) growth and user acquisition strategy. How will you acquire new users, what channels will you use? How could your existing users “advertise” your product and help you in acquisition? Our only answer was that we will upload to the store, and if someone needs a run tracking app, he will find it somehow. But if a runner did not know that run tracking mobile apps as such exist, he was unreachable for us. Similarly, if we were not on the top of the hit list, the potential user would not even look at our app page. Workouts could have been shared on Twitter (in 2010 they had a very small user base), but not on Facebook. We have written no blog posts about the app, we have not advertised the app with Google.
7.
Dogfooding is good. We used our own product, and we recorded our workouts with it. This is one of the few things we did right (the other was the frequent releases after v1.0.0); we managed to polish the features and improve the usefulness and usability of the app. At least, from our perspective.
6.
Test the product with users you want to acquire, and the current users (if you have any). CoolRunner was optimized for our needs, reflected our mindset and mental model about running and mobile apps. My colleague was a marathon runner, and we were both server-side programmers who got their first computer in the 80s and who were used to unfriendly UIs and reading manuals. If we’d tested the app with any runner other than us, we’d surely not have written a user manual for a mobile app…
5.
Have a well-grounded view of the potential users, especially their needs, desires, what make them happy, what make them angry, and understand the consequences of selecting that given user group. Do you want to develop a run tracking application for young adults who run 20–40 kilometers a month? Well, it will be way different from that app, which is developed for marathoners who want to qualify for Boston. Our app contained features for all kinds of runners, and consequently, was not the best for any runner.
4.
Know your competition and use their products to have a deep understanding of them. It is not enough to read the product spec, study the screenshots, install the app, but you have to use it to see their strengths and weaknesses. You can learn from them, and you can find their weak points where you can beat them.
3.
Know your market, including the market size, and value. What is the number of potential users? How much money would they be willing to spend on the product?
2.
Have a conscientious social networking strategy. Our users were individual islands, there did not know or interact with one another, and they could not form communities. Good social networking model and good social networking features, however, decrease churn, increase retention and engagement beyond the primary use cases (in our case, running and workout analysis), may increase the usefulness of the product, and would make it more fun to use, thus increasing user satisfaction.
1.
Without perseverance, you have to be extremely lucky to be successful. The first release of our product will not be an instant success, there will be many things you have to learn and adjust. But it takes time to recognize the issues, to come up with the potential solutions, to select the best one, and to implement it. How long does it take? In the case of CoolRunner, I’d say that 3–5 years. Have we spent this much time on CoolRunner? Unfortunately, we have not, and this was our biggest mistake.
Liked this post?
If you enjoyed this post, please help out your friends with a *clap* or a share.
