Article: Never mind the solution sell – what about the solution buy?

sellingicetoeskimosSelling software feature-by-feature used to be quite the rage.  ‘Feature wars’ were what software vendors engaged in all the time.  ‘He who had the most features won’ was the way we thought things worked.  The media didn’t help this much.  Reviews were organized by grid with a list of features down the side and a list of products at the top.  It seemed that it was the only way people could distinguish between products.

These days there’s lots of talk among vendors about the “solution-sell”.  If you’ve been involved in high-end software, you know exactly what I’m talking about.  The basic intent is for the salesperson to identify some problem; some ‘pain’ that they have the solution for.  Then the issue becomes showing how the software, configuration, consulting and training that is offered can help solve this problem. 

If you’re a client, you’ve seen this too.  You’d be on the other side, presumably articulating the problem you’re trying to solve and determining if what the vendor is proposing can actually fix the issue you’ve got. 

While this sounds quite an appropriate division of labour, delivering, one would hope, the best delivery of problem solving possible.  Unfortunately, the most common scenario I see when I’m in a software sales scenario is a conversation about features.  The entire request-for-proposal structure often devolves to this paradigm also.  Recently I was able to work with a couple of vendors on an RFP for a large high-tech firm.  It’s a bit unusual for me as I usually only see our own responses.  As per usual, the meat of the document was a grid of features, which the vendors were to fill out with a yes/no/maybe type of response.  As I worked with these vendors, it became clear that the responses from each of them were essentially the same.  From one interpretation or another the response for virtually every feature was a “yes” or “yes with some effort”.  What a problem this must be for the client.  All solutions are identical, yet each is clearly very different.  How can one determine from this the ideal solution?

Well, part of the problem is that most RFPs don’t identify a problem or, in any way, ask for a solution.  Most RFPs are just like the one I’ve just described.  They request a list of functions.   The premise is, that the group that has created the list of functions have already determined that this function list provide the solution.  The premise is fine but is often not always accurate. 

There are a number of reasons for this.  First of all, most software selections of enterprise systems are done by committee.  It’s a necessity, of course, since enterprise systems will affect so many people, many will want a say in their selection.  A committee with a diverse membership carries with it many influences and these all become apparent in a software selection.  Some of the influences that must be dealt with include: merging the primary problem with others that committee members and their groups are experiencing.  “Let’s get something that fixes all our problems.”,  the presence of existing legacy systems and the familiarity with features that exist in those systems “We’re still going to be able to see the code numbers on the left right?”, the desire by some members to promote their own solutions with products familiar to them “I’m sure we could do all of this with our integrated ERP system.”, and, last but not least, the desire by some members to use the opportunity of being on this committee to promote themselves (Now, I’m sure that’s not happening where you work.).

Trying to chair such a committee becomes all about keeping the group focused on its task.  All too often, however, the original task of solving a problem becomes a task of choosing a piece of software and the reason for choosing it can become lost.  Focusing on a feature grid and creating a structure for putting items on the grid or weighting them by importance must often be the path of least resistance for the people running such a selection committee.

We’ve seen the end result of this on a number of occasions.  The committee ultimately chooses software after a long protracted process and, while the installation is successful, the problem for which the committee was struck is still not resolved and the implementation, as a result, can never deliver the hoped-for result.

If you’re on the client-side of an enterprise system selection, you can make a difference by keeping the original problem in sight.  Run the selection committee like a mini-project.  Have a charter for the committee’s purpose and keep it visible in all your internal communications.  If you must create a feature list, make sure the guidance for evaluating it is against the original problem or problems that the given system is to fix.

You should be communicating the problem or situation you are trying to correct up front with the vendors you speak with.  Most enterprise system markets are made up of a small number of vendors.  The project management market in which I usually work is a group that is small enough that all the major players know each other quite well.  Once we find out what people are trying to solve with our software, we have often no-bid and suggested the 2 or 3 other vendors who are more appropriate. 

If you’re trying to find out if a given product will provide the solution you require, outline the elements of the problem.  Believe me, it’s all too rare to find these in RFP-type documents.  Ask the vendors to outline how they would solve this problem in the particular paradigm their product was designed for.  You might be surprised at the different quality of the responses you get. 

In the situation I spoke of at the beginning of this article, it was obvious from carefully reading the list of features that the context of the features was for a system that would be used for financial purposes and that data would be ultimately destined not only for project systems but also for financial systems such as payroll.  While that wasn’t mentioned anywhere else in the document, it was enough to have the largest vendor decide to partner with one or two of the smaller ones to provide the solution the client requested.  It was the right move.  Discussions with the client during the selection made it obvious that the large vendor had the features requested but that in practical terms, the solution desired could have never been crafted out of them alone.

So, don’t worry so much on the vendor’s solution-sell.  If you’re the client, make sure you’re concentrating on a solution-buy.