Feature-rich or hard to use?

My blog this week is a bit of a rant and a little bipolar, based on some recent procurement discussions I have had. The first part of my rant revolves around the question "Who else is using it?" in relation to a product. The answer I want to scream is: "Who cares!"

Now I know that there is some value in knowing who is using a product, but I think that this dimension is often taken a bit too far. My organization is not NASA, UPS, Fed Ex, IBM, or Lockheed Martin. There is nothing about my organization that resembles those organization in any fashion. So does it really matter to me that they are using a certain product? NO! They certainly have 10 to 100 times the staff that I have to dedicate to any product, so their success with a certain product cannot be extrapolated to mean success in my organization. Conversely, the particular circumstance behind a failed implementation probably has nothing in common with my organization either.

You may be saying, ah, but you should be looking at how the product works in organizations similar to your own. I will admit that this is a better comparison. But unless I know the exact details of another organization's implementation, the mere fact that it is using a product is about as meaningful as knowing what temperature they keep the inside of their buildings. Unless you are finding out who is using the product so you can call them and get the particulars, the comparison is almost meaningless. So, the next vendor that cites 10 Fortune 500 companies that are using a product to me is going to get an earful.

If the issue is that high-profile organization are supposed to establish a vendor's viability, is that really a good measure of value or one that just makes us feel good? Some research needs to go into this. We all know of vendors with full client lists that have gone belly up. And I know I am not the only one who has seen the potential in a smaller company's product and successfully adopted it – even though the company didn't have a large customer base. So I wonder about the true viability of this measure.

Also related to procurement and evaluation, is the issue of a product's being "feature rich." To this day, I use the Microsoft Office suite as the perfect example of a product that's is so feature-rich its richness takes away from its usability. I contend that the majority Office users barely use five percent of the product's functionality. But, by golly, the features sure need to be there just in case somebody might need them. Thus we get products that are big and bloated and expensive, because features are what companies use to compete with one another. Whose fault is that? Probably ours, because when we go through the evaluation process, we often reward feature-richness with higher scores, whether or not the feature is practical in our own environment.

This argument also begs the question, Are feature-richness and ease-of-use mutually exclusive concepts? My answer to that is no, but feature-richness can and often does lead down the road to complexity, which in turn erodes ease-of-use. Using a broad, broad brush, let me paint the typical user as someone who doesn't want to read instructions, does not have time or inclination to attend training, and often blames IT, the computer and the software for their inability to do something. This translates to "the product and anyone associated with it sucks because I can't make it do what I want it to do."

So what is the answer here? For product development, it means that when determining the detailed requirement specifications for a product, one not only needs to look at what has to be accomplished, but how often the action/task is performed. Those tasks/actions that get performed the most, better be the ones that are the most intuitive and well thought-out.

This mentality, while it may be a gross generalization, calls for a customer requirement of ease-of-use and intuitiveness that most manufacturers do not cater to. They don't, because the people who are often doing the product evaluations do know how to use the products to a much greater extent than the typical user, and they look at feature-richness as a way to separate them. Don't look so shamefaced; I have been guilty of it, too.

For product evaluation, while it is good to keep in mind the features we would like to see our user population use, it is best to be realistic and put the most weight on the features they are most likely to use. It would also not hurt to get their opinions or include them as part of the evaluation team.

Lastly, don't be afraid of the little guy, or open source, or the like. If a product is promising and you can give it a good shake-out and feel strongly that you can make it work, it's OK to be the Lone Ranger. Tonto will come along soon enough.