We’ve got a strong team of developers working on inFlow Inventory, but we also have 231 feature requests right now, with more coming in all the time. What do we do?

Step one: take a deep breath. Step two: realize how incredibly lucky we are to have such a supportive community willing to help us improve. Step three: think long and hard about how best to meet their needs.

Obviously, we can only do so much at once, and some requests might make sense for one individual company but not for the community as a whole. So what do we work on first? Our starting point, naturally, is what does the inFlow community want us to work on? We talk with hundreds of customers a day through our customer support and social media, and we track every time we get a request for a feature or a problem to be solved.

We assign a vote score for each feature based on the number of customer requests recorded. Older votes are weighted less heavily than more recent votes; the logic here is that the needs of the community may shift over time, and if we’ve stopped hearing about something, it may be less important than it once was.

We also have our developers estimate how long it would take to implement each feature. Then, we sort the features by vote score divided by time estimate. The features with the highest ratio are generally the ones where we can help the most people the fastest.

We do, of course, leave room for human judgment. For example, some features may affect relatively less people, but be absolutely critical to them. Or certain related features may make sense to work on at the same time. So our entire team (most importantly the support team, who talk with customers the most) will discuss and vote on which features they think we should implement in the next release. Each person is given a budget (about 2 months worth of development work) and can vote for features within it. Based on this, we’ll discuss until we come to a consensus on the plan for the next release.

Sometimes we also schedule some work separately from this process, typically things that improve inFlow significantly but aren’t the sort of thing we’d get a lot of feedback about. For example, we recently invested in making the installation faster and more reliable, which we knew was important without being explicitly asked for this very often.

Depending on what surprises we come across as part of the development process, we might hold back a release to ensure that we get the details right, or sometimes we’ll even have time to do some extras besides what was originally planned.

We also handle software bugs separately. There’s no way for us to predict in advance what bugs will be discovered, but we try our best to take care of bugs as they come up, instead of letting them build up into a big hive. During the beta testing period, we focus on fixing bugs that were discovered, and then start the process over for the next release!

This process has helped us to preserve our much-needed sanity, and to serve the inFlow community’s needs while retaining responsibility for managing releases and the product as a whole. Keep that precious feedback coming, we can handle it!