A little while back, a potential client contacted me wanting to develop a software system that would help them manage their data in a highly regulated environment. During our conversations, one of the key things they kept saying is they were looking for a “highly consultative approach”.
It’s probably the first time I’ve heard a client specifically point that out as a key factor in their decision. I am, however, familiar with the consultative sales approach and I think to a large degree, it’s the approach we follow when we’re working with prospects.
From this one particular client’s perspective though, it was a very rare thing to find a software development company, IT services company, or really any group of “techies” that understood what it meant to be “consultative”. In some conversations I’ve had since then with other professionals, they tend to agree that IT product and services companies do a very poor job of proper sales techniques in general, and being “consultative” in particular.
A Definition: What do we Mean By Consultative Selling?
Consultative Selling is really an iteration of an approach created quite some time ago by sales coaching professionals. It has at times been known as “Solution Selling” or “Needs-Based Selling” – but ultimately, it’s about good communication.
For example, Richardson, a global sales training organization, defines the approach as:
Consultative selling techniques are all about the dialogue between the salesperson and the customer. The word dialogue comes from the Greek and means “to learn.” In Consultative Selling and Needs-Based Selling, the salesperson learns about customer needs before talking product.
Perhaps the Greek entomology is our first clue as to the issue. In order to be successful at a consultative approach, you need to be able and willing to “learn about customer needs before talking product”.
In our industry, just the simple act of learning is a real challenge, which affects not only software developers who are involved in sales processes (so called “technical pre-sales”), but also the sales people themselves. Ours is a rapidly changing industry, and needing to stay on top of the newest regulatory demands, javascript library, or cloud-based paradigm means that staff members at a technology firm are already crammed to the gills with the need to stay on top of trends.
The Trap of Good Old Features and Benefits
In some ways, this means it’s very tempting for the entire industry to become about who can show a customer they know more/have more. Who can, in an initial conversation with a prospect, demonstrate that they are the smartest IT consultant/programmer/salesperson in the room, wowing them into a purchase decision? Who can show them that their product or service has the most features and benefits?
Though it may sound like I’m being facetious, to a large degree this really is the way a lot of technology firms think. I have personally worked with, and sold alongside of, technology companies both large and small, and it is rare that they take the time to really learn about the customers’ true needs in their industry – instead, they want to rattle off technical jargon, or impress the customer that their product checks all the boxes.
This is of course made even worse when the prospect is pushing you to work through a RFP process – a situation in which it is impossible to learn about customer needs, and all you can hope to do is to check the right boxes and be the lucky winner (this is part of the reason we rarely engage in RFP processes).
With all this pressure to keep on top of trends, check boxes, and impress, how can staff at an IT company also be expected to spend the time to learn the ins and out of their clients’ business needs? How can they justify spending time learning about how adhesives are manufactured, how medicaid claims are processed, or how an architect works with an elevator installer? That knowledge is something that they don’t generally have time to learn, and for which there is often little incentive.
Extending Agile Iteration to the Sales Cycle (Helping Tech Types Understand Consultative Selling)
I think perhaps part of the solution to this problem is to try to frame the goal of being consultative in a way that IT professionals will understand it.
In most of these types of IT firms, Agile practices such as SCRUM and other methods are well established. One of their core teachings is that iteration is key – that you can never know exactly what the future holds, so you need to work in a gradual, iterative manner to determine requirements and build software features.
This approach is different than the old way of doing things, the so-called “waterfall method”, in which IT folks would attempt to gather all requirements for a system upfront, make huge assumptions, and then go off and work for 24 months and hope to come back with a working product or system.
In some ways, the old way of doing sales that we see many IT firms stuck on is all about assumptions. When in a sales meeting, IT people want to assume that a customer needs some feature set, or that they want to hear about that new training that your entire consulting team got certified on. Because they make the assumption that the prospect fits into a given mold and will love their features and benefits, they end up missing the mark because they never listened to customer needs – they just waited for the right cue to do their presentation of assumptions.
And often, since the prospect really struggles to determine what product or whose services they should select, they go with whatever presentation is most aesthetically impressive, thinking “well, how could this go wrong?”.
This client/vendor/solution mismatch of course leads to a lot of problems down the line.
Perhaps if IT firms were to try to adopt some of the Agile mindset towards their selling processes, this could made better. An “Agile Sales Process” would in a lot of ways be similar to a consultative selling process – asking questions, learning about customer needs, and having a dialog with customers to build a true set of “known facts” instead of operating on assumptions. This set of prospective business requirements (similar to software solution requirements) could be tweaked in further conversations, making sure that when it came time for the team to present their suggested solution, it matched the client’s needs as closely as possible.
What do you think? Has innovation in selling processes at IT firms lagged behind technical process innovation? Do technology companies sell 2010’s technologies using 1970’s techniques? Leave a reply in the comments with your thoughts.
