I often do act as a sales enabler to ensure success of bigger deals. As a sales enabler, I introduce the customer to my products and its features. Oops, did I say features. Here comes my biggest concern, do I had to talk about product features to my prospective or current customers. Does it really make sense? Before you get fuzzy about what I talking about, let me illustrate something very simple. When I went to buy a car, the sales man was so enthusiastic to talk about all the security features such as ABS, EBD etc. I was puzzled about all those jargons, but I am very happy that car was providing some key features that would definitely ensure the safety of all the people travelling in the car. On the contrary, how nice it would have been if the salesperson has explained the benefits derived out of those features.
So taking a cue out of this instance, I normally hate talking about features unless the listener has thorough understanding of the product. I would rather talk about solutions built/ conceptualized on top of those features. Customer can directly relate to solutions as they are conceptualized on the basis of deeper understanding of customer pain points or overall market requirements. Product is definitely a black box to customer and he could not even fathom how the box would help him to address his business issues/ objectives, so talking about features is inundating the customer with technical jargons. On the contrary if we talk about solutions customer would easily understand the direct value derived out of buying the product. By selling solutions, I am clearly communicating the value or benefits derived out of using the product.
For instance, check which point makes more sense to the customer
- Product X supports multiple IPs per subscriber or
- Product X support multi-device plans or group plans
1st statement is typically based on features and 2nd statement is typically based on solution thinking. Now any idea with which statement would customers relate easily or connect easily. In addition solutions approach clearly articulate the capabilities of the products and it perceived benefits, so selling becomes far more easier.
Aligning with idea of selling solutions, I structure my presentation in 4 sections
- What is product X (talk about specifications),
- What are the customer/market pain points,
- Why product X (wrt to alternate products and it is not about competition) and
- How product X can address those pain points
It is more like a story telling with a proper sequence and flow, start with some static information about the product X and the organization Y (just talk for less than 5 minutes). Later talk about the pain points of the market in general. For instance, in case of DPI market, I can talk about the declining ARPU and increasing costs of SPs (for 10 – 15 minutes). Next talk about how product X can address those challenges effectively by outlining few solutions that might of interest to customers. For the success of the presentation, I also do a little research on the company and how they are performing. If possible, I would request my account team to have an informal chat with the customer to know about the primary business concerns/issues that they are looking forward to address using product X.
There can also be 5th section with respect to competition and highlight a comparison sheet. But I normally avoid as it is too early in the deal process to talk about competition, I might essentially do the same after responding to the RFx.
This methodology was working out for me until now, probably I have to solicit the opinion of experienced sales guy and rework the structure of my presentation accordingly.
I follow similar strategy while explaining the contents of latest release. I hardly talk about features introduced in the latest release unless the customer has thorough knowledge of the internals of the product. I would rather communicate the solutions that can be accomplished by the new set of features available in the latest release. Even while collating the requirements, I never ask customers for the list of features that they would require in forthcoming releases, I would rather ask for the list of pain points or business requirements that has to be accomplished by the product. Based on those inputs, I conceptualize solutions with help of solution architects and later convert those solutions into features and indicate the same in the PRD. My long pending blog post on ‘Requirements has to understood, not queried’ will touch upon the topic of collating the requirements and I assure all my blog readers that it will be my next blog post.