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 in any fashion, those organizations. 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 success in their organization with a 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. While I will admit that this is a better comparison, unless I know the exact details of another organization's implementation, the mere fact that it is using a product is about as meaningful to me as knowing what temperature they keep the inside of their buildings. All of this is to say that 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.
Also, regarding knowing who is using a product to determine the vendors viability is that really a good measure of its value or one that just makes us feel good? Some research needs to go into this. We all know of vendors who have had lots of clients that have gone belly up; and I know I am not the only one who has seen the potential in the product of a smaller company and adopted it in spite of its not having a large customer base and been successful. So I wonder about the true viability of this measure.
Now, still 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 which is so feature-rich that its richness takes away from its usability. I contend that the majority of users who have MS Office installed barely use five percent of the products 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 two concepts that are diametrically opposed?" 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 doesnt 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 cant make it do what I want it to do."
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. Dont look so shamefaced; I have been guilty of it too.
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.
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 opinion or include them as part of the evaluation team.
Lastly, dont 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, its ok to be the Lone Ranger. Tonto will come along soon enough.