When dealing with many users suggesting all kinds of different features, big ones and small ones, there’s two things you need to decide on:

• Which ones to implement
• How to implement them

Which ones to implement?

Sales
For each feature, you should always consider: Will adding this feature actually result in more sales? Either by attracting more new customers, by convincing more of your existing customers to upgrade to your new version or, more indirectly, by making users happier and thus more likely to tell their friends about your software.
If none of the above applies, then you may be better off not implementing a particular feature. Less is more.

Statistics
Features that are requested more frequently are important to more of your users, so should receive a higher priority. That is, if they make sense, which is for you to decide. Only implement stuff that fits the direction in which you want to take your software.

Of course, you need a sufficient number of requests to decide. Don’t just pick one feature with 3 requests over one that got “only” 2 requests. Not getting enough feedback to make your decision purely on the number of requests? Then I’m afraid that you will have to guess. Pick the features that you think will be appreciated by the largest number of users.

Beware of the “vocal minority”
All users are not created equal. If all requests for a particular feature are coming from a small, but vocal sub-group of your users, then beware. These users may not be representative for the rest of your audience, so implementing that feature may not be as important as it seems to be.
At Collectorz.com, the features that are requested on our forum are completely different from the ones we are getting by email. We have found that the typical forum user, often advanced and tech-savvy, is different from the average Collectorz.com user. So we have to take that into account when “counting” the number of times a feature is requested. However, I must say that the forum has also been the best source for wild, out-of-the-box feature ideas…

Beware of helpful users
When users suggest a particular feature, always make sure they actually want or need that feature themselves. In an attempt to help you, some users tend to make up features they think other users will like. Or they suggest functionality just because one of your competitors has it. Which by itself is never a good reason to implement a feature.
This is a common effect when you explicitly ask users for feedback. My experience is that the best feature requests are unsolicited, resulting from a user’s personal experience with your software.

Hidden feature requests
The best feature requests are not only unsolicited, but may not even be stated as a feature request. They may be disguised as a frequently asked question, or a common complaint. Read between the lines of your customer support emails. There will be loads of hidden “feature requests”, e.g. questions about how to accomplish a tricky task or complaints about some actions being too cumbersome, users being frustrated trying to understand your user interface.
Frustration is a major conversion killer, so implementing functionality to take away this frustration may be more important than programming your number one feature request.

Which features can you think of yourself?
Finally, don’t just rely on your users to think of new features to add. Often you can think of more important features yourself.
Users only tend to think in terms of small changes or additions to existing functionality. Whereas you can (and should) take a step back, think out-of-the-box and come up with completely new functionality. Stuff that your users may never have considered even possible.

How to implement them?

Solve the actual problem
Don’t just implement the feature that was requested. For every feature request, try to get to the story behind it. Try to find out what the actual problem is, then solve that problem. You may be able to come up with a better solution than the one the user was suggesting.

Don’t let users design your UI
Don’t just implement the feature exactly as it was requested. Your users are not user interface designers. Build the functionality they requested, but design your own interface for it, a user interface that makes sense, is understandable and consistent with the rest of your program.

Go broad
Feature requests are often very specific, solving a special problem that particular user is having. But with your implementation, you may be able to go broader, create a more generic solution that solves many similar problems. And thus make more people happy.
An example from the cataloging world: if a user requests being able to sort collection lists on the Title field, in both ascending in descending order, why not go all the way and immediately allow this for any field?

Go deep
The implementation of one requested feature is likely to trigger the next one. Can you predict what your users will request next, after you release your long awaited new version? Then why not get it over with now. Go deep and immediately add all related functionality that you can expect to be requested.

Beware of feature creep

I hope the above will help you decide which features to implement and how to implement them. But whatever you do, remember it is your software and that you are the one who is responsible for making a quality product. Listen to your users and use their ideas to improve your software, but don’t let them dictate your priorities.

Through the years we tried: simple todo.txt files in our CVS project trees, Word documents on a shared file server, Google Docs (both spreadsheets and text documents), Mantis, The Bug Genie and since a few weeks: Lighthouse.

The Bug Genie

Though I liked using a real bug tracker system, The Bug Genie didn’t work for us.

At first, it looked good. Nice up-to-date web 2.0 UI (as opposed to Mantis, which is not so easy on the eyes). It has a good project structure, allowing products, editions, builds and components (but all are mandatory, making it a nightmare to set up and maintain).

However, reporting bugs was a hassle, there’s too many fields to fill in (and all mandatory!): Product, Edition, Build, Issue Type, Component, Category, Severity, Issue Summary, Issue Description and How to Reproduce. You have to enter something into each and every field before you can submit a bug, very annoying.
You can guess what happened: lots of “asdf” and “qwer” entries

But that wasn’t the biggest problem. It’s reporting and browsing features are just too limited and clumsy, especially when you have multiple projects going (we have over 20 now). The Frontpage of the The Bug Genie is one loooonnnnngggg list of all issues, grouped by project.
Maybe it is just me, but for me the most common task I perform is to check the open issues for a particular project. That should be just one or two clicks away. In The Bug Genie, the only way to get a list of all open issues for a specific project is to go through the clumsy Search feature. Which is weird, I mean, even Mantis has simple project tabs at the top.

Alternatives?

So after using The Bug Genie for a couple of months, I started looking for a replacement. Early June I asked for tips on the ASP Forums and on Twitter:

I received the following suggestions (thanks all!):

• Bugzilla
• Fogbugz
• Mantis
• Lighthouse
• adminitrack
• Arctic Tracker
• Assembla
• Unfuddle
• Kayako

Fogbugz was the most often suggested tool by far, so I looked at that one first. Also because it is created by Joel Spolsky’s company Fog Creek.
However, Fogbugz is complete project management system, that does more than just bug tracking. Which probably explains why it is so expensive. It costs $25 per user per month (I need eleven users). $275 per month is a bit pricey for just bug tracking.

A friend, former co-worker and former employee (all rolled into one) recommended to take a look at Lighthouse. And I didn’t look any further…

Lighthouse

First, Lighthouse is a hosted bug tracking solution. When I started looking for a new bug tracker, I had no preference for either a hosted or a host-it-yourself solution. I have no problems installing a tool on our own servers, we did the same for Mantis and The Bug Genie (and still do for WordPress, PHPBB, etc…).
But now that we have chosen for Lighthouse, I am happy that they host and update it for us. It’s nice to log in and find new features and improvements.

Lighthouse does bug tracking only, it has no project management, collaboration or customer support features. Which is fine with me, because it is great at the bug tracking part. I like products that do just one thing well.

Creating a new project only takes a name and an optional description. No need to define an elaborate project structure, with editions, components, builds etc… Once the project has been created users can immediately start reporting issues.

Adding bugs is super easy and accessible. There’s only a few fields (Title, Description, Who’s responsible, Milestone, State, Priority and Tags) and only the Title is mandatory. And for many bugs a descriptive Title is enough, at least initially.
I’d rather have users add Title-only bug tickets, than run the risk of a 5-minutes-per-bug reporting process making them give up alltogether.

What struck me as strange, at least initially, is that Lighthouse has no fields to indicate in which part of a program the bug was found (called Component in The Bug Genie, Category in Mantis) and no Issue Type field (for stating where the issue is a bug, feature request, change request, etc..).
To be more precise, it has no special, dedicated fields for those.

But it does have a blog-style Tags fields. Which you can use for Categories. Or for Issue Types. Or both. That’s the freedom you have in Lighthouse. In the Create Ticket screen the tags you used before automatically appear as a tag cloud below the Tags field. Just click one to add a tag to your ticket.
The tag cloud is also shown in your navigation panel on the right, for easy access to a ticket category.

Which brings us to the browsing and searching features. You can browse tickets per project or get an overview over all projects. Every project page has direct links to lists of Open tickets and Resolved Tickets (called Ticket Bins in Lighthouse). The cool thing is, you can define your own Ticket Bins too, based on tags, states, responsible, ticket dates, etc… Just do a search and save the search as a Ticket Bin.

Now I must admit that the Search feature is a bit clumsy. I mean, there’s no “advanced search” screen where you can define your searches with separate Tag, State, Responsible and Date boxes. You need to type queries like

tagged:”bug” state:open responsible:me

into the search box. Works fine for programmers, but for anyone else that’s just too cryptic.

Then, last but not least, the pricing. It’s cheap. If you only need one project (and 1 or 2 users) it’s free even. We are currently at the “Bronze” plan ($24 per month), which allows 10 projects and 15 users. We’ll probably upgrade to the Silver plan ($49 per month), once we start moving all projects over from The Bug Genie to Lighthouse.