People are interesting. We tend to gravitate to those who are similar. We like familiar sounds, foods, and experiences. We like routine.
I don’t mind familiar settings and I maintain a close set of friends. It works.
However, when it comes to sales we are in a different ballgame. We must deal with different types of people all the time. A wide range of personalities and backgrounds. Everything changes depending on who you are talking to during the deal process.
An important sales principle I realized many years ago is you get delegated to the people you sound like.
I argue Sales Principle 7 is the most important and not discussed nearly enough in sales and sales training. People dynamics is by far the most underestimated part of sales and a major reason why sales is a stressful job.
Everyone believes they can do sales. Yeah...no. Everyone can’t because working with people is hard. Closing a $50k deal is fairly straightforward. Try closing a seven-figure deal and tell me it doesn’t give you mysterious heartburn.
I’ll share why it is absolutely critical to be conscious that you are speaking to people and not just selling a product.
With this in mind, you’ll find conversations will naturally flow smoother, you’ll get timely information from key decision-makers, and ultimately close deals.
Much like when code tells a story about the developer who wrote it. For salespeople, our words tell a story about who we are and who we should be talking to in a deal. Speak the right language and you’ll end up gaining the right insight.
When selling a technical product or service you’ll most likely be working directly with engineers. Regardless of whether you may consider yourself a technical salesperson, you better know how to speak to the end-user or you won’t get very far.
Most often you’ll face unexpected hurdles just because an engineer may not believe you understand their project and requirements.
There is a balance every salesperson must face on how technical one should get. The argument can be made you don’t need to be so technical if you have access to an applications engineer to support the pre-sales deals.
I’ve found in my experience it is best to know just enough to be able to identify opportunities and understand the application. If you pretend to know something you don’t, it can backfire. Don’t fake it.
I know where to find the opportunities but I’m not going to dive into architecting an inventory management platform. I leave that to the pros.
However, as salespeople, understanding subtle conversation dynamics will dictate the flow of the deal. If you start saying things like, “I’m not the architect on this project, but help me understand what you are looking to build and your schedule,” you’ll most often get a high-level view which is what you want at that point anyway.
Jump into a technical conversation right away and you could end up in the weeds real fast. Then good luck finding your way back.
The goal at the beginning of qualifying a deal is to get the big picture early. Questions around schedule and budgets open the possibility to meet additional people on the team who are privy to those details. You may get a response such as, “I’m not the best person to comment on the budget and schedule. Let me introduce you to the program manager or my manager.”
An engineer has a different language as does her manager. Speak their languages and you’ll have a chance at building better rapport.
Find Common Ground
How many of us know the difference between client and customer? Does it matter? We often use those words interchangeably. Well, in our noisy competitive world understanding the differences of client or customer does matter.
A customer is generally referred to as a one to one transaction for a standard product. You’re buying a product off the shelf such as an iPhone or SaaS product, you are a customer.
Clients are buyers who generally receive a customized product or service. The interaction to purchase a service varies every time. Consultants will refer to their buyers as clients.
For example, at Skiplist in our service business, we build custom software solutions for enterprises. They are our clients. Every project is different, and we tailor the interaction for every client.
Why is this important?
Understanding the client or customer perspective is critical. If in a highly transactional customer environment, you may realize volume is key and a lower cost would be a huge factor in the decision process.
In a client environment, the expectations are around a more personalized experience. The focus may be around more high touch higher quality interaction.
Clients are looking for a specific outcome based on their specific requirements. Price may not be a critical factor.
Capex vs Opex
For every single deal, there is someone in purchasing counting the numbers. They also speak a different language.
Understanding the difference between capital expenditures (CAPEX) and operating expenditures (OPEX) can make the difference in crossing a deal over the finish line.
Capital expenses are for purchases used in the future. You can think of them as investments a company may make to support growth such as equipment and R&D.
Operating expenses are for day to day purchases. These are expenses to keep the business running such as rent and salaries.
If you know your way around accounting a bit you can sometimes get buyers to find budget from the OPEX bucket as opposed to the CAPEX budget. As an example, when buying equipment a company may choose to lease equipment rather than buy it outright which may change the budget from CAPEX to OPEX.
That’s all I am going to mention in accounting. I don’t want to bore myself.
Relationships over Money
At the end of the day, there are no such things as business to business (B2B) or business to consumer(B2C) selling.
Everything is person to person (P2P). Companies don’t sell to each other. People do.
Remembering this critical dynamic about selling will take you a long way to consistent success.
Most importantly, you’ll build stronger bonds with people, and if you are not all about relationships over money. Don’t bother.