Takeaways: Tailor your message to the audience. A product by itself is not a solution.
My first Presales manager would drum into us the refrain, “we sell solutions, not tools”. In the years since I’ve been involved in many similar discussions, trying to teach Sales and Presales to focus on value, outcomes or capabilities, rather than the products that are involved. But I have to admit, not mentioning the product name and not using words like “tool” is really hard to do. Especially when our training is usually on products, we price by product, and at some point the customer needs to install or login to one or more products.
This topic came up again recently in two separate discussions on the same day. First, I was talking with an experienced Sales Manager who is new to our company and was preparing for a CIO meeting. Through the discussion, it became clear that one of the traits of our team he had been observing (in both Sales and Presales) was an overuse of product names. His point of view was emphatic: “We should never mention product names”.
Later that day I had lunch with Presales colleagues, and the topic came up again. I can’t recall the full context but one of them fairly quickly made the point that “at the end of the day, we are selling a product”. It’s a viewpoint I have expressed myself, so it got me thinking. When is it ok to mention the product name?
My first conclusion is that what is most important is to tailor your message for the audience. This is true whether you are having a conversation, making a presentation, writing an article or demonstrating a product. If it’s a high level meeting with a CIO, talk about business outcomes and broad capabilities. If you are pitching a complex solution that involves multiple products, talk about the problem you are solving and the value you are delivering. If you are talking to a technical, knowledgeable buyer, then it might be better (and even required) to use the product name.
When talking to existing customers, I often present a slide showing general capabilities or a standard framework like IT4IT, then overlay it with product names. It helps make the connection between their existing tools and the solutions we want to talk about. I’ve also worked with products that have changed names multiple times and have been owned by different companies. Mentioning the old name is a good shortcut to get to a mutual understanding of what I am there to talk about.
The second thing I realized is that the selling/buying process has changed a lot since I started in Presales. Vendors typically get involved much later in the process, after the buyers have already done considerable online research. One of the consequences of this is that a technical buyer may approach you specifically about your product, and they may already have a fixed idea of what they are after. As my colleague John said at lunch, “They aren’t interested in your company or your other solutions, they specifically want to know how your ‘automation’ product compares against the other vendors they are considering”.
In such a situation, it can certainly be easiest to talk directly about the product. However, the requirement (and challenge) is for Presales to still do appropriate discovery and qualification about the problem, so that we can then position the right solution (which might be one or more products) and potentially expand the conversation. Try something like this: “Before I dive into talking about [Product X], can I ask a few questions to make sure I understand your situation and what you are looking for?”
One good reason to mention product names can be when you want the buyer to do further research online, or if you are going to send them a case study or analyst report. These are mostly aligned directly to product names and you might need to help the customer make the link from the solution you are proposing to the products referenced in the document. This can be especially useful if you are well positioned in an analyst report, have good brand recognition, or if you have an active and positive online community. (Of course, the reverse scenario might also be true, and you don’t want the customer looking up specific products!)
A third and very important consideration here is that a software product or tool by itself is not enough to deliver a solution. As vendors, we are fooling ourselves if we pitch a tool as a “solution”, without understanding, communicating (and costing) all the other activities that are required to get the software in production and being used effectively.
Delivering outcomes requires consulting, planning, design, implementation, configuration, integrations, training and change management. This is where services teams, partners and System Integrators are so important. The software itself may only be part of what contributes to a larger project, and the outcome may require multiple software tools working together.
(As a side note, one drawback of positioning a “solution” can be that if multiple tools are involved, the infrastructure cost can be huge. A SaaS service may help mitigate this issue, or you will need to identify areas of synergy, in order to redcuce the overall hardware footprint)
The final point I want to make is about the importance of having different roles in the sales team and assigning the right person to each conversation. We need Technical Presales who specialize in products, but when you have such deep focus it can be hard to step back and also play the role of a Solution Architect. Having a Solution Consultant or Enterprise Architect or Business Consultant type role within the Presales team can help address customer conversations with more senior people, or that are held earlier in the sales cycle. I have also seen great examples of collaboration with Solution Architects from Professional Services, who have the experience to contribute a broader solution focus to a sales pursuit. And as already mentioned, for a larger, more complex solution, a System Integrator (SI, or SIer as my Japanese colleagues say) may be required to lead the discussion on outcomes and help you sell a solution at a more senior level.
In conclusion, I do think its good practice to focus on the outcome being delivered, not the tools or products that will deliver the solution. Especially when you are talking to more senior people, when you are in early stages of discovery, or when you are proposing a solution that involves multiple components. It’s also a reality that we will need to show and talk about individual products, and that customers are often approaching us when already comparing different tools. I’ll try to talk about solutions and capabilities, but I’m not going to beat myself up for mentioning a product by name.
In the language you use today, are you selling products or solutions, tools or outcomes?
Thoughtful Presales 