I recently had an email conversation with someone who asked me if I had a feature matrix for Devshop versus the competition. After I thought to myself, “What competition?!” 
my very next thought was a moment of silent panic. Crap! Where’s our feature matrix?! Did anyone do a feature matrix?!
Then, as I often do in those moments, I took a breath, thought for a minute, and realized it was a good thing there was no Devshop feature matrix. I hadn’t gotten around to one because I didn’t think it was important. I mean, I’ve generated those things many times over for the companies I’ve worked with in the past. It just seems like “what people do.” After consciously thinking about it though, I decided that unless someone is holding a gun to my head, I’m not going to do one.
The trouble with feature matrices is that they are probably the #1 cause of “missing the forest for the trees” in a software purchase decision. Let’s face it, unless they’re actually generated by the customer themselves, as a means of comparing specific products they’re looking at, then they’re all biased anyway. It’s kind of like asking an interviewee for references. Who’s going to give you the name and phone number of someone that hates them? No-one. Feature matrices developed by vendors are always stacked to show their products in the most positive light.
As I went on to explain to the person that was asking for the matrix, this (the feature matrix) is not an approach that we would ever take in selling our product. Our design goal is to make it so incredibly obvious when you put Devshop side-by-side with any other product, that Devshop is the one you want. It should take you a whole 10 seconds to realize that. If we were to have to pull out a feature matrix to make the decision, then we’ve failed as designers.
Feature matrices come from this habit that we all have about wanting more “features per dollar”. It’s the “biggie-size” mentality where for 10 cents more you can have twice the fries with that burger, even though you don’t need the extra fries and may not even eat them anyway. This consumer purchasing behavior has led to product developers cramming in more features without too much thought about how they fit together, how relevant they are to solving the problem at hand, or what impact they have on usability (which is the one thing that ultimately decides the success or failure of a product in the users’ hands). You see this thinking embedded in the “less is more” philosophy that is finally starting to take hold in the software industry.
The real design goal should be to solve the customer’s problem with as few features possible (therefore guaranteeing the easiest adoption and lowest learning curve). As sales people, we should all be able to define why our product design is better equipped to solve the customer’s problem without resorting to a spreadsheet crutch.
There will be times when a customer demands a matrix as part of their purchasing process, particularly for large sales. To the degree that you can re-focus their attention on what matters (why your product’s design is better suited to solving their problem), you and your customers will be better off.
