Photoquarium Blog

Lately there have been a few blog posts that I have read about whether to relay the benefits or features of a product to the user in an attempt to give them the best tools to choose your product. Some circles believe that you should list the benefits that a product produces instead of features since benefits can be understood easier by clients instead of a list of features (which can and most times are a technical list and confusing to the end user).

One article (actually it’s a video) called Features Don’t Exits (Only Benefits), Max Pool goes on a little rant about a styrofoam drink container that has a feature labeled on it. He basically goes on saying that the feature is irrelevant and the company would have been better served to list one on the benefits of using a styrofoam container and then starts to relate this stance onto software.

Whether we list the features or benefits of the product, I feel that this is like most things in software development, we should look at each case and decide whether a feature will convey the most and best information to the user or will listing it in a benefit manner be more effective.

There was a follow up post by Jurgen Appello where he disagrees with this notion of benefits and expands more on the questions, who is deciding that this is actually a  benefit, the end users or the company, or what is a benefit. Here is a good quote from the article.

When you create a product, it is often necessary to anticipate what your customers want. You have to imagine needs and benefits, and design your product accordingly. But once your product is out in the open, being used by your customer, you must stop acting on imagined needs and benefits. You must accept whatever it is the customer is doing with your product. Don’t tell your customer how many suitcases the trunk in a car can hold. Just tell the customer what its dimensions and volume are. Whether your customers want to translate that to “number of suitcases”, “number of sheep” or “number of dead bodies”, is up to them

I have seen this situation on a few projects I have worked on where we are thinking that we are adding a benefit to the system by changing the way it works. In out minds this makes no sense the way it is working now and logically we are probably right.
But after the change is deployed to the field we find out that the users are using the product in a way that we can’t understand why. It could be because they have gotten use to it working this way or that they see the system in a totally different way then we do. Either way the benefit is actually a hindrance to the end user and complaints come rolling in. A few times we have even rolled back the changes.

So do we try and predict what the users want or let them fully drive the future enhancements and benefits. I believe its a fine balancing act that takes a bit from each side but pushing features and benefits onto a client can really hurt you. I have a firm belief that the user should be involved (or at least consulted) in all the steps of development. This can save from some long and expensive failures since it should be caught early on that this isn’t wanted or needed by the clients.

What is your opinion, features or benifits, who knows best?