If you’re a senior executive responsible for setting – and overseeing the attainment of – your enterprise’s corporate growth goals, I have a question for you: How informed are you on the individual contracts that comprise the overall total of your organisation’s business-under-pursuit? How certain are you that the priorities underpinning the prioritisation of current […]
"You’ve proposed a ‘sledgehammer’ solution and we are a ‘walnut’ customer." Feedback of this nature is not uncommon in ICT bid debriefs, by my observation. And it’s just one example of the many different ways in which a proposed “solution” can be totally out of alignment with a client organisation’s actual needs. Taking the above example, how does it come about that a client organisation finds a huge solution put forth to it, for a comparatively small need? Often, it results from the vendor sales team’s excitement over their company’s latest technology/product, and their un-resisted temptation to promote it as the solution to all problems, both great and small. A Lack of Questioning Know-How Sometimes, however, it’s a lack of know-how, when it comes to mapping out a process for digging deeply into the client’s “big picture”. Let’s take a look at the dangers of not knowing your prospective client’s world as intimately as you perhaps think you do. Here’s a telling comment made to me by a client of one of my own clients some years ago. I’d been digging around (in a proactive proposal scenario i.e. one not subject to probity restrictions) to identify the reason for the significant amount of push-back the BD team sensed during interactions with the organisation in question: “(Vendor) is used to dealing with organisations with daily throughputs equivalent to our monthly throughput volume. We’re not there yet. They want our business but they’re in auto-pilot mode when they converse with us. They don’t get us or where we’re at. If they did, they wouldn’t be proposing this big thing.” The vendor’s reputation was being compromised by this situation: Pushing what the prospect saw as an overkill solution was creating the distinct impression that that organisation was seen simply as a “great big cash cow”. Worse still, one that didn’t know any better. If, for example, your client is an organisation with a call centre, does your client consider its needs – in the context of its own industry norm – relatively simplistic? Or, in fact, quite complex? Or somewhere in between? Frame the Question from the Client’s Perspective You need to ask the question from the client’s perspective . And then you need to understand precisely why the client considers that the organisation’s need sits at this level of simplicity or complexity. And within that level of simplicity or complexity, what are the client organisation’s specific priorities and why? What aspects of their business or their customers’ behaviour dictates that these are the priorities? And what are the risk factors associated with these priorities not being recognised? And, coming back to simplicity (or complexity), are their hidden layers of complexity required to actually achieve the simplicity (i.e. in a risk-free manner) that the client desires? Perhaps what the client desires more than anything is simplicity of implementation and operation . . . but is overlooking the fact that there is necessary complexity involved in creating that simplicity? Good Questions Catalyse A Deep & Meaningful Relationship The point is, there’s a whole line of investigation that needs to be conducted, and this is the type of question that can catalyse a deeper and more meaningful conversation between vendor and client. It’s the type of questioning that lets the client know you’re not just trying to apply your newly released technology or other flavour-of-the-quarter solution to that organisation’s needs or problems, regardless of whether it really is the best, most client-centrically thought-through option. Questions like these show that you see your role as understanding specific problems and solving them, or understanding specific desires and fulfilling them . . . as opposed to simply spruiking your software (or other form of “solution”). The key is for you, the vendor, to enable the customer – and to do so in the most proficient, cost-effective, adoptable, adaptable and results-oriented fashion. And the only way to be sure that what you propose will do that – in the words of the afore-mentioned end-client – is to: “Get involved and not just talk the talk. Interact with us and immerse yourself in ‘a day in the life of’. Invest some time looking at the world through our eyes and, more specifically, through the eyes of those in our organisation who have to pick up your technology and kick goals with it.”
In a challenge workshop I held recently for a meeting of the senior marketing and sales personnel of a multi-national in the broader infrastructure and engineering space, I was told (I’m paraphrasing): “We struggle with converting client needs into end benefits. We’re good at communicating features, but not extrapolating these into project-relevant end-benefits.” Now, notwithstanding that the industry in question requires substantial use of technical specifications and other feature-related detail in submissions to its client audiences, the workshop participant that voiced that general concern was right on the money. These features still need to be converted to actual “benefits”. There’s a simple exercise for arriving at the benefits of a feature, without losing the necessary details of that feature, as required for the satisfaction of the client-side’s technical evaluators. Here’s the basic version: Throw up three columns onto your whiteboard. Head up the left-hand column, “Feature” – and articulate the key elements of the feature. Head up the middle column, “Relevance to Which Specific Project Objective?” . Head up the third column, “How It Helps to Achieve That Objective” . Again, this is just the basic version; more extrapolations are required to take this all the way through to any form of “win theme” contribution. But it’s a great start.
