Software feature lists - I hate them.

I especially hate them when they are used as the primary way of making important software purchasing decisions. When you try to evaluate software based on a spreadsheet of features, you miss out on one of the most important aspects of software today – is it usable without training? Usability is more important than features because complex software rarely gets widely adopted. When software vendors prioritize at the feature level, they are focused on volume (more features are better). When customers buy software based on feature lists, you are influencing vendors to build more and more features, rather than focus on usability.

In my experience, most software features are never used, yet we make strategic purchasing decisions about the volume of features in a product. More isn’t better, every feature you add to a software solution makes the solution more complex. I have seen very few software vendors purposefully retire features that are no longer used, so the number of features goes on and on for the entire life of the product (often referred to as feature bloat – see Microsoft Word™ toolbar).

When evaluating software, the problems that you want to solve are way more important than a bucket of potentially irrelevant solutions (features).

I think all RFP’s should simply list all the problems you want to solve with the product. Each vendor could be asked to explain how they would configure/implement/customized their solution to create a suitable solution. Wouldn’t that be a way more effective way to evaluate solutions? Instead of a passive checklist where virtually every vendor says yes to every feature, you would ask the vendor to describe how they would solve your relevant challenges. For example, a web-to-print RFQ could include a checklist feature that says:

Track Order History

Every single web-to-print product would put a “yes” answer in that feature checklist. What does that “yes” tell you about the product? – not much! What if your RFQ instead said:

My customers need to easily re-order products they’ve ordered before.

My customers need access to past invoices for budgeting purposes.

My customers need to understand their spending at different intervals month/quarter/year.

Instead of a check mark, you ask for an essay answer that could include screen shots from the vendor describing how their solution uniquely solves this customer challenge. Their solution/feature set might or might not have anything to do with Order History. In fact, you might find better ways to solve the problem that you didn’t even know existed. You would actually learn during the procurement process rather than go crazy looking at a mind-numbing spreadsheet of “yes” answers.

Fall in love with the problem. This is a great mantra for business at all levels but it particularly applies to software. When companies go to buy software they typically don’t prepare by listing and prioritizing all the problems they want to solve with the solution. More likely, they are so frustrated with their current solution, instead of digging in further to make it work, they want to drop it and hope the grass is truly greener because the sales person said so. Or they get blinded by the bright shiny demonstration that highlighted all kinds of solutions (features) to problems they don’t even have. Yes, people buy software all the time because the demonstration was cool, yet it had no correlation to their current business problems.

You know why software demonstrations focus on the “cool” because it works. Do you know what the percentage of “cool” features that are actually used in production? (not many) Boring features that do boring things fast, effectively, and reliably are used extensively in production, yet they would put you to sleep in a sales demonstration. For example, a brilliantly executed approach to SSO (single sign-on) can be one of the most important features to driving adoption for your customers with web-to-print. If you take the need for a unique login and password out as a barrier to entry, you get way more adoption. If you have a feature checklist that says “SSO” and everyone says “yes” you’ll never know who has the brilliant implementation (easy to implement, easy on your customers’ IT department) and who has crap until it’s too late.

I’m not against flashy sales demonstrations, I just don’t want anyone to make important software decisions based on them. You should go into every technology decision with a clearly defined and prioritized list of the PROBLEMS you want to solve. This should not change even if you see the coolest solution you’ve ever seen because cool solutions to problems you don’t have don’t matter!