As I read this title, I realize that this could be the start of a book, not a short article. Ultimately, every bit of software written is for somebody (even just for the programmer who wrote it). So this means that end user (or customer) has the final say as to whether the program is useful – often, voting with their wallet.

It’s odd that software companies rarely give customers the focus they deserve. Perhaps the problem lays with the type of people that develop programs (broad generalization follows): Programmers tend not to be ‘people persons’, so it’s reasonable that making the software user-friendly, versus, say, an interesting technical challenge, is not a priority.

However involving customers early in development can make software radically different – and sometimes different is good. This happened with our latest software release, Rocket Retriever 3. Originally designed as a software tool to make managing my own files easy, it has since evolved, based on feature requests from customers, as well as what I felt was needed.

For instance, when originally developing it, I went to great lengths to keep the database up to date, scanning constantly. However, many customers complained that the scanning was unnecessary, so later versions had a throttle to control speed. In version 3, scanning can even be turned completely off on startup – this was because some customers wanted the flexibility of scanning once, and ‘freezing’ that scan (for instance, for files that rarely change, like a music database).

Another example is ‘skins’. While it originally appeared an unimportant request, more than one customers wanted a new look for the program. The retro 30s look was uninteresting for some, and perhaps detracted from using it in a work environment. With skins incorporated, Rocket Retriever can appeal to a wider audience, and even opens up the possibility of custom designs for specific clients, allowing them to brand the product for their company or site. Again, a customer request or two becomes a valuable feature.

The list can go on and on. But in distilling it, the main points are:

Give requests time to sinking – what seems an odd request may grow on you in time, and solve another customer’s problem later on down the line.

Remember that each customer represents a segment of your market – each complaint/comment could easily be the tip of the iceberg for many more customers who don’t wish to email.

Likewise, customers may illuminate target markets you never considered – one customer indexes music for this D.J. service, while another uses it in his law office. When I first wrote Rocket Retriever, I expected ‘power users’ to be interested rather than businesses – and delayed entering a large market area.

View customers as friends, not adversaries. Occasionally a complaint/feature request will be very specific and hard to implement (one request was for a search feature that looked for words in the files themselves, a significantly different product). However, customers who email you want the product, and just need a little extra to make it fulfill their needs. If you can satisfy that need, you could easily have a sale.

Working at communication is good advice for any programmer – listen to your customers, and you’ll be surprised at what they have to say – and the results will be well worth it when you release your next product!