Happy New Year to you all!
In this first posting of the year I would like to share the 6 top learnings I had while developing/improving Kwik. Hope you enjoy and provide your comments (agreeing or disagreeing):
6. DON’T UNDERESTIMATE YOUR PRODUCT
As I mentioned in my first post at this site (Why the world needs Kwik?), the original idea for Kwik was much far from what the current product is. Honestly, although I was expecting to get success with the plugin, I was not expecting the huge amount of users in just few weeks. Fact is, I underestimate the product I was building.
Suddenly I had to review my hosting and online marketing payment plans and had to find time and money to add new features to support the arrival of the first apps made with Kwik. I had even to depreciate the focus (leave behind, to be honest) on comics and put all my efforts on the Books part of the plugin.
Why am I bringing this learning here? Because some of you may be in the same, yet not perceived, situation. What I mean is, you start to develop your storybook/app/whatever you are building just “to test if it works or to see if you will like this app development thing”. Then you launch it and start to see people downloading (sometimes buying) and asking for improvements or complaining about this and that. So, what to do now?
The 3 paragraphs above are there just to remind you: be prepared for growth!
5. AVOID DESIGN ON THE FLY
I use this in all of my talkings (I have been in the software industry for a while, as some of you have already figured out thru Linkedin or my personal blog). Being a designer myself, I learned that the more time you spend in planning, the less you will spend on fixing.
In “Kwik’s” case, the more users started to use, more they requested for things I didn’t think were important or was not ready to implement. With that, I had a hard time re-writing functions and even the full interface in matter of months. To keep things in the timeframe, many times I saw myself doing something that I hate: designing on the fly.
Designing of the fly is horrible: it is expensive (hours and money), it never works well (the nice new feature usually breaks old ones) and the frustration is huge.
In the case of using Kwik, it amplifies. You are using a plugin inside a product that will create code for another product. In all 3 cases there are so many variables that the line dividing success and failure is pretty close.
The most successful experiences with Kwik are from people that learn about the product limitations (user guide and postings!!), plan accordingly (from what each interaction does till the name of each layer and actions) and push limits only when they are comfortable with the basics. In sum: learn first, use later!
4. ALWAYS LISTEN YOUR CUSTOMERS, NOT ALWAYS TAKE SUGGESTIONS AS PRIORITIES
The old saying tells “the customer is always right”. What the saying does not tell is the most important info: who is really your customer?
Since the beginning I have an open forum with users (not necessarily customers yet), collecting feedback and prioritizing features according their requests. This has worked most time. However, not always customers really know what they want or need (don’t be mad on me yet :)).
For example, in several surveys people asked for in-app purchase (which I honestly never thought was really important for Kwik’s main target audience – can you name a great storybook app which has IAP implemented?). Two months after and NO apps with IAP were made with Kwik.
The time spent with IAP would allow me to develop, for example, the multi-language feature (not practical for most American users, but crucial for international audiences). As an example, in less than a month since its availability, I have checked myself 3 apps being made with this functionality.
My main finding here: sometimes majority is not the main driver on a decision.
3. 30-45 DAYS BETWEEN NEW VERSIONS IS NOT GOOD
This is very important and some of you will not agree (lets see the comments). Bringing several new features every month hasn’t been a blessing but a curse. An example, only now, 4 months after the release of version 1.6, I am seeing apps using features from that release. Things like text/audio sync, IAP (1.7), haven’t showed up yet. Why? Simply because Kwik releases are faster than people can consume!
With this learning, I am informing now that the interval between new releases will be larger than 30 days from now on. Of course they will not occur every year and a half, like some big players do but, 60-90 days may be a good number. I will learn from reality and adapt it if necessary.
What you should know? New features are not always good for your app.
2. DO NOT MIX NEW FEATURES WITH REGULAR UPDATES
This one I learned the hard way and I will never do it again! From December 29 till January 4, I released 5 updates, adding new features, then fixing old features – SHAME ON ME and I apologize for that. The reason: I added new features that I couldn’t test appropriately and found out that they were not working well in real life.
I thought the new features were “simple ones” (a new clean function and a potential new one) so, why not?
Fortunately, just a few but kind users were affected (thanks to holiday season) and promptly contacted me for fixing. Test always first, test again, test another time, and then launch!
1. THE GOOD IS ENEMY OF THE GREAT
This one is old but it applies to several users of Kwik. Some of you have already a good product (I have seen many) but the idea of keep polishing and adding and tweaking stop you from the most important thing: do not try to make it great before launch – as you will NEVER finish! Remember the first iPhone (it didn’t have apps, it was really expensive, etc)? It wasn’t perfect but it was good. With time and market share (and of course revenue from sales) it got great. Not trying to compare Kwik with apples (bad joke) but, if I haven’t launch version 1.0, I would never had Kwik doing what it does today. More than 40 apps wouldn’t be made because the plugin would exist only in my machine!
Launch a good product, collect feedback, improve and then make it great (you are getting fast satisfaction, money to cover the first expenses, etc). Also, if the product is not that good, you haven’t spent months and months on a dead idea.
Always target the great but launch when it is good! What makes a product memorable is the use of its users, not its developers!