I have recently been evaluating three ITSM products for a client. 
One is a long established global brand, one is a high-performing global newcomer and the other a regional niche player.  All are available in on-premise or SaaS deliveries. All the products have broadly similar features.  They are each aligned with ITIL.
The client’s requirements are only loosely defined with a focus on ‘look and feel’ and ease of management rather than functionality.  But with no clear definition on what is required of the product there can be no confidence that when selected it will do what is needed.   As in my earlier blog “It’s the data, stupid” this suggests a technical focus on features rather than an outcome based focus
The only comparisons that can be made are on features and price.  But again, without knowing what is required there can be no selection based on which features will add most value.  A technical audience will be drawn to innovation and new technology and seek to select the product that most exhibits those.  Again, this does not necessarily support the right outcome.  The products in any case are so feature rich that without clear requirements no meaningful distinction can be made on that basis. It becomes a “This product has feature X and this product has feature Y” discussion.  I am tempted to ask “So what?”  Any feature is only as valuable as your need for it; if you do not know what you need it for, how can you assess its value?
It then becomes a price based decision.  That will tend to select the product with the lowest apparent price.  Any such selection must be extended to assess the total cost of ownership.  Even then you are essentially saying “This product might be able to do what we want and appears to be the cheapest.”
This is a pretty poor approach to selecting a product that will underpin the management of IT services to your business customers for the next five to ten years.
Why does such a situation occur?
I assert that it is because such selections are normally driven from the IT infrastructure area. This can appear sensible as they are the people who use the tools day to day.  They are not the consumers – or certainly not the only consumers – of the outputs from the solution though.  Within the IT organisation the CIO, CTO, supplier and contract management groups are also involved.   And what of the business the IT organisation supports?  The type and quality of the service they receive is significantly affected by the appropriateness of the ITSM product.
What is really required here is a formal package selection exercise, driven by requirements.   This will involved engaging the applications and systems development areas because that is where those skills reside.  Business analysts will be experienced in determining requirements, developing weighted assessment criteria and evaluating products against them.  They can track requirements though the design phase and assist in testing.
And if you don’t have requirements, what do you need it for?
(Oh, and what did the client do when we presented our recommendation?  They asked for a further study as they couldn’t decide if it met their requirements …)