Users all over the world tend to see iambic as an ill-mannered company. Documents To Go 7-an uproar about why this product wasn’t called v6.012. GravityBall-german users unhappy because of too many, daily updates.
-different reports and quotes from german boards and the vienniese PUG
All the cases above represent unhappy users-users unhappy with updates of the software they once bought cheerfully. An unhappy user generates fuzz-more than 100 happy users. And many unhappy users get you a place on this blog-as counterexample. To prevent you from being the next example, you will now find a short description of why each of the three products mentioned above failed and a few other hints too. It is not my intent to point fingers at anyone-I just want to save other developers from making the same mistakes.
Over-updating kills your user base (GravityBall)
Young developers-usually-are eager. They like to code and enjoy supplying their fellow users with the latest features and levels straight from the compiler. Not every release works well though. Thus a bugfix follows each release, usually followed by another release with even more features as an apology to users. Alas, a circulum vituosum starts off… While fast update cycles are ok in a CVS, they tend to annoy users. Keep in mind that the user has to visit his portal or launch his email app, download the program,… .
Many game developers think that they help their users by releasing a new level once a day. However, think of a game with 100 levels. When the developer updates once a day, game value increases by approx. 1% each time. Nobody will really feel that. When the developer updates once a week though, that’s 7%. And that will be felt, believe me! So, don’t update too often-users will not feel the improvements that much and will get annoyed in the process.
Tune in on Friday for the rest-look forward to the following don’ts:
- Force users to update-they will love you for it
- Increase version numbers fast and keep your updates expensive
Until then, feel free to discuss your software updating processes.
Related posts:
Content, RSS
Twitter
[...] Welcome back, fellow readers for the second part of the updating article. In case you missed out on the first piece, find it at http://tamspalm.tamoggemon.com/2004/12/14/update-wisely-and-be-lovedpart-1/ Force users to update-they will hate you for it This example comes from Agendus, where the version 8.006 does not work well on Tungsten T5 and Treo 650 handhelds. However, version 9.0 works well. Now, at the first look, this is perfectly o.k. Version 8 got discontinued-and version nine came out. But why did users make a terrible fuzz here? Well, I see two reasons here: The first reason was the short time between the versions, where each was about half a year from each other. Even huge companies like Microsoft leave at least one year of development between the versions-according to 1), users feel more of the development this way. The second problem with Agendus is that a more-less buggy product was abandoned, so users felt forced to update in order to be able to use what they already bought. Of course, this will not be accepted…. Increase version numbers fast and keep your updates expensive Now we are in the king’s class of annoying users. Documents to Go version 7 is an excellent program(I tested it on a comrade’s T3 and loved it). However, most users were pretty unhappy about the update. The reason was simple-the update was way too dear. When a program costs x, let the update be about x/4. Prices can of course vary a bit, depending on how much cash your users have. Regardless of how much your program costs, the update must be significantly cheaper to keep buyers happy. lf you want to be a nice developer, give away a free update to those users who bought your program-say-30 days before the new version came out. In addition, have your CustomerCare offer a few grace days to reduce bickering… [...]
[...] Update wisely and be loved-Part 1 Update wisely and be loved-Part 2 [...]