In a perfect world, we (the software providers) should have enough time to develop and complete the perfect product – one that it is intuitive, easy to use, and full of the most in-demand features – before selling it at a reasonable price. I am reminded of a quote from Armageddon when one of the characters offers, “You know we’re sitting on 4 million pounds of fuel, one nuclear weapon, and a thing that has 270,000 moving parts built by the lowest bidder. Makes you feel good, doesn’t it?”

Thankfully, software is not a nuclear weapon and nothing catastrophic will happen if it has some defects. However, the underlying principle remains the same – when you have too many features without enough time to fully test or develop them, quality defects are inevitably bound to emerge as you rush your product to market.

The purpose of this post is to outline the process of bringing a feature request from idea to implementation. The catalyst behind this post is a feature request (codenamed #32) that has followed us since May of 2007.

Where Feature Requests Come from
Believe it or not, we do have a roadmap! This roadmap guides us in our decision-making as we scan the horizon and envision how our clients might use whatever features or products we provide. In this vision, we blend a mix of different directives, including service add-ons, feature enhancements, infrastructure updates, marketing activities, and other crucial elements we know will help us design a superior end product. From all these items, we develop an internal list of features that we call, not-surprisingly, “our features,” but we also actively solicit feedback from our clients to ensure that our long-term vision meshes with the reality of those who ultimately rely on our products. In fact, it is through this external focus that we derive the bulk of our improvement ideas.

We follow two simple rules when incorporating feedback requests from clients:

  1. Does the enhancement make sense?
  2. Will the enhancement improve the GUI?

In truth, these two simple “rules” are actually not that simple. There exist some product enhancements that could be of tremendous benefit to a small subset of users while harming others. It is not easy to reject a perfectly reasonable request, but we find ourselves in this very position sometimes when we realize that to successfully implement a particular enhancement could render the GUI less intuitive or more difficult to navigate. Because of our orthodox approach to interface design, we strive to keep things simple, avoiding the endless series of options and laundry lists that plague many other products (tools -> options -> etc).

Our uncompromising stance on potentially detrimental improvements means that we occasionally lose clients, but we are willing to pay this price. On one occasion, clients requested local installation capabilities for our product, but we regrettably had to decline even though such a feature is mandatory for many users.

However, even “rejected” ideas never truly die. By communicating with our clients directly and trying to understand their needs and processes, we often discover feature enhancement opportunities that neither party would ever realize. Having an open dialogue is crucial for continual improvement within our industry.

Documenting and Managing Feature Requests
We currently use Trac to manage our features. After one of our team members sets the ticket attributes, the rest of us can modify the values, making them more accurate over time. We then use these updated attributes to help us prioritize the request:

  1. Description – including how and where the feature fits in with the product.
  2. Customer email – allowing for easier feedback and follow-up.
  3. Size – development time, including time to implementation. In a later post, I may explain our “size” unit in greater detail, but in a nutshell, size is a critical component in productivity.
  4. Testability – essentially a simple guide that explains how testers can validate the feature’s usefulness.
  5. Milestone – usually set to TBD, but we occasionally assign specific goals based on individual client requests.

Monthly Plan – Monthly Releases
We deliver monthly releases of our product, with most updates scheduled two months in advance. Our approach is quite simple – first we add those features that we promised to our customers, then we add secondary features from our roadmap, and lastly we incorporate any TBD features until the estimated “size” of the proposed update approaches the limits of what our developers can handle.

This process allows us to respond to urgent requests very quickly – usually within 30 days. And because we have built a smart auto-update process, we can release individual enhancements and features directly to specific clients based on their current needs.

Feature #32 Case Study
At Testuff we have recorded, until June 2011, over 30 releases counting over 730 new features requests. Feature #32 is one of the first to be suggested, a few years ago.

It was a fairly straightforward enhancement that involved adding spellchecking capabilities to our editor. This request emerged internally during our planning board as we mapped out what we believed our customers would eventually request further down the road. However, we were surprised to discover that almost none of our clients needed this feature when we first began developing it. Even still, lack of interest was not the reason behind the feature’s delayed release.

Rather, we were initially unable to find a workable way to implement spellchecking in python wx.richctrl with our editor. Delay after delay pushed the timeline back, until we eventually realized that, absent any specific requests from an individual client (or group of clients), it made more sense to pause development of this feature temporarily.

More recently, however, we did begin to receive requests from our customers. Although we faced the same technical challenges as before, by pulling in additional outside help, we developed a viable workaround that allowed us to properly implement a spellchecker.
How we got this additional help is an interesting story by itself… we decided to give oDesk (and its likes) a chance and posted request for a similar job. The number of good ideas we got this way was surprising. This led us to start using this outsourcing channel, and so far, we are happy with the results.

Our successful release of Feature #32, in the last version, essentially highlights our approach to software development and testing platforms. We try to anticipate the needs of our clients while simultaneously soliciting feedback on additional improvements. In this way, we continue to deliver high quality products and services that address the individual needs of our growing user base.