Managing Feature Requests for iOS Apps

Posted on 19 February, 2011

Introduction

This week I’d like to show you how we manage feature requests for our apps with Jira. If you want to know why Jira is great, see my last post.

The Problem

Feedback is one of the most valuable things your users can offer you (after paying for your app of course). There is now way you – as a developer – can forsee all the features your app will need. What’s even better, through feedback you can get a good grasp on how your users are using your app and what they expect next to make it even better. Since those users are your perfect target group, what can be better then feedback from them?
It’s up to you to decide what to make of it, but receiving and managing feedback (or featured requests as a subset of the possible feedback types) is very valuable.
If you have done it right, feature requests will start to flow in. They may be submitted via email and if you don’t store it elsewhere, it will shortly mess-up your inbox. Worse yet, if it is not categorized, you’ll have a hard time to remember for which version (maybe you have an iPad and iPhone app) it was meant.

Feature Requests with Jira

As you may have noticed by now I am a big fan of Jira by Atlassian (and definitely not on their payroll – this is pure enthusiasm). Since we use Jira to track issues while developing our apps, what would make more sense than to store feature requests there? One possibility for such a setup would have been to configure our Jira installation for public access so that users could submit feature requests by themselves. We didn’t follow this approach because most users tend to give up on requests if the entry barrier is too high. Before using Jira, we had set-up an account with GetSatisfaction. However, the simple fact that users had to create an account there, led to very few requests. After providing a simple HTML form (and later even a “contact support” button from within the app) – feedback shot through the roof  (hat tip to Sarah for the great idea).
Right now our workflow consists of the following steps:

  • Feature requests roll in via email
  • I access Jira to see if there is already a similar request
    • If there is one, I comment on the issue with the text “+1″
    • If there is no request, I create a new issue with the type “Story”

As you can see, I have added a custom field for the issue type “Story” called “Feature requests”. Then I have setup Jira to count all comments on the issue to display the sum in that field.
The great thing about this setup is that the field “Feature requests” can be used to filter issues. So for example when planning updates for one of our apps I can create a quick custom search and filter for something like:
“show me all feature requests with the component “iPhone” and sort by “feature requests” count”

As soon as we decide to work on that feature, I create a sub-task for the “Story” issue and assign it to our huge pool of coders to work on (Trung or me).

Conclusion

Feature requests are valuable and usually hard to come by. If you make it easy for your users to submit feedback they will make use of it. You’d be surprised how many users are stunned by the fact that a human beeing responds to their requests. I guess our spoiled mass market mentality leads to the impression that companies employs vast numbers of automated support drones whose only purpose in life is to create canned responses to customer mails…
Storing your feature requests right next to your development issues is a clever idea that makes it easy when it comes to deciding what features to work on next.

Comments are closed.