Value Selling is a concept familiar to many, but Value Buying is more of a mystery. In this blog post, KangaROI Co-Founder and CEO Devin Halperin will use his decades of experience to take you behind the scenes of sales, help you understand how you should be making purchases, and why you should be Value Buying.
Why do we buy things?
There’s a multitude of reasons that people purchase products or services, but generally they can be categorized into 2 groups. The first being practical and the second being emotional. When we look at purchasing software or services for our company, we often believe we’re buying solely for practical reasons, but there are many factors that fall into the emotional category as well. Do I like the people from company A? Have I heard great reviews about company B? Will I get a promotion if the project goes well or worse, be fired if it doesn’t? We like to believe that we are rational beings, but at the end of the day there’s always going to be factors that are hard to put a price on.
How do we evaluate products?
We know that it’s hard to be objective when evaluating multiple products so the most common method is to let data speak for itself. We create a list of items that we care about and do our best to rank these items from most to least important. Unfortunately, there’s likely 3 or more vendors that are able to check the boxes for all of those features and so we have to find more items to measure them. We ask for a Proof of Concept to display how they will achieve the results. We look to Gartner to see which one is in the uppermost quadrant. We create an RFP that has such an exhaustive list of items that it’s bound to help us determine which one is best for us. Once we’ve gone through these, the result is that we usually go with the vendor that best understands our problem and gives us confidence that they can fix it.
What is Value Selling?
I’ve worked in Solutions Consulting for over 20 years and I like to consider myself fairly adept at understanding a customer’s problem. I’ve also been trained in a method called Value Selling, which taught me not to sell my product, but to find out what matters most to you and then figure out a solution to that problem. The more I know about your problem, the better I can address it as part of the sales process. What this allows me to do is begin to quantify how big of a problem you have, while also attaching metrics to it to “justify” the amount that our software costs. As an exercise, next time you are talking to a sales person in an early discussion, ask them how much their product costs. If they can’t tell you, it’s because they want to quantify your problem first to justify the cost associated with fixing it. Why do you think there’s usually a basic price for software and then a “Contact Us” for the enterprise version?
So what’s wrong with that?
In short, there’s nothing wrong with wanting to understand your problem fully and selling a solution that’s fairly priced for solving it. The issue lies in how the problem is quantified. There are whole teams at software vendors whose sole job is to come up with metrics that can be used to display how much that vendor can save you (or generate increased revenue). This is called Business Value Consulting. They may have contracted a consulting firm to tell them they average a 20% efficiency gain for a certain process, or can reduce overhead by up to 50%. These are great outcomes, but what are they measuring against? Is that 20% against a company that doesn’t have any solution currently in place? What am I supposed to do with the 20% extra time I recovered in the process? I would never tell a client to let a team of people go, but I also can’t dictate how they should use what I’m claiming they can recover.
A common joke in sales is if you didn’t write the RFP, don’t bother responding to it. From a business case perspective, I’m usually the one who is helping put it together for a customer to pitch to their leadership. That means I’ve helped define the metrics and how they relate to you as well as the overall value of the solution. The higher I can value the business case, the more we can potentially sell our solution for. Kind of a fox guarding the hen house scenario.
Okay, what should I do?
This is where we get to the concept of Value Buying. It’s likely you didn’t take a call from a vendor if you didn’t have a problem that needed fixing. The issue is how can you quantify your problem before speaking with vendors? Most mid-level management in IT comes from a technology background which means they likely aren’t versed in building business cases, so they seek advice from outside counsel. What if instead you had a framework in place that taught them to identify which metrics will lead to cost savings or revenue generation and got realistic expectations when it comes to delivering the actual solution? In fact, most vendors will give you the metrics they use to calculate their value and you should be the one dictating how much you actually believe you’ll save and which of those metrics you want to use. This can all happen before a pricing discussion takes place so as to let you dictate what your problem is worth and how much you’re willing to pay for it.
As an additional benefit, when you are in control of the metrics, you can ask for agreement from a vendor on how much you should save. If they tell me 20% and I only get 10% are they going to pay me back for the difference? A solution sale or purchase should be an agreement between two parties that will be mutually beneficial. If you aren’t tracking and working towards a common goal then it’s likely one side is getting a lopsided amount of the value. How often is that vendor following up with you to make sure you got what was agreed to in the initial business case?
What's next?
At KangaROI, we’re building the first Value Buying platform that will bring customers and vendors closer together around actual outcomes. What’s even better is that we use our own platform to ensure we’re delivering value to our customers. Feel free to reach out, and we’d be happy to show you how it works.
