A Monthly PS Principles Newsletter For Decision Makers [September 2022]
In this edition...
Views from the Summit
The 3 Tenets Of Selling Services
Customers Must Be Engaged In The Process
On Belay
Sales Compensation For Services
Selling Services Vs. Products
Free Climbing
Establishing Implementation Partner Programs
Useful But Proceed With Caution
Book Review
Change The Culture Change The Game by Roger Connors And Tom Smith
Views From The Summit
The 3 Tenets of Selling Services
To sell services effectively, I find that it helps to have an unwavering belief in three core tenets. The first is that it is not a selling process, it is a buying process. The customer has a need and you are there to convince them that you can fulfill that need. Listen to what they want and respond in terms of the needs they have expressed. Anything short of that misses the point. The next two tenets are what we will focus on for the rest of this article. The first of those two tenets is that when selling services you must accept and be able to articulate that you are selling people's time. You're not selling a result, an outcome, or a product, but rather time. If you sell a result or an outcome, you are not only misleading the customer but also missing the opportunity to create real differentiation. This leads me to the last tenet, you must sell to the danger. If your service doesn't mitigate or remove some element of danger then you have no value to sell and the customer doesn't need you. Finding that danger is something you can both listen for, but also use your expertise to identify.
First, let's look at the legalities of selling. All over the world there is a legal distinction between products and services because of one core difference. When a customer buys a product they are allowed to expect an outcome. A product is built and sold to a specification. The product is supposed to give you an outcome. A service, however, is not guaranteed to give you an outcome because the customer plays a part in the service, whether the customer wants to believe that or not.
You might think that sounds harsh to remind a customer that they are buying a service and not an outcome, but I do this straight out of the gate to set the expectation that the customer is going to have to participate in the service journey to achieve their desired outcome. As ideal as it would be that you could just pay the expert to make it happen, enterprise services simply don't work that way. The customer wants the solution tailored to their specific needs and only the customer knows what those needs are. A customer that expects to be disconnected from the receipt of the service is almost certain to negatively impact the project for both parties.
For example, take a hairdresser who cuts someone's hair. You might not think the customer plays a big part in the provision of the service, but the hairdresser asks, "How would you like your hair cut?" If the customer describes their desired haircut poorly, incorrectly or in a manner that is not understood, then there is a strong chance the hairdresser will interpret something different then what the customer wants. When the hairdresser asks, "Should I take about this much off?" the customer must respond in a way that gives the hairdresser direction on how to provide the service. Even if the hairdresser does everything the customer asks for, there is still no guarantee that at the end of the process, the customer likes or even wants their hair to look that way. This is because the act of providing any service requires an expert to fulfill the desires of the customer but through their own interpretation of the customer's requirements.
Now multiply this by a hundred and you have a haircut that might look like a technology project. There are thousands of questions for a customer to answer as we go through our process and if they are not prepared to engage and answer them, the project will suffer. Getting this out in the open from the outset is a great way to start the buying process. It tells the customer, pay attention otherwise you might buy a service that doesn't work the way you want it to.
This approach also opens up your ability to use the third tenet. Every customer is buying something that reduces their risk of failure. Every customer knows the dangers of implementing technology projects. They will not be on time, they will not be on budget, and they are very likely to be more difficult than imagined. They know this because they see the reports, but they often continue to believe that they will be the exception because the service providers they go to make them think that there is no danger.
This is where you can create differentiation. Every journey has danger, but within a sales cycle you can create competitive advantage by identifying which of the dangers within the journey you already have answers to. By doing this and sticking only to the dangers that you can answer, helps you create differentiation that others have to try and follow.
Here's what I mean. When we were implementing CPQ solutions we decided to go out and ask customers what their biggest fear was when it came to implementing such solutions. While we thought it might be something like SKU rationalization (the removal of duplicate SKUs) we actually found it to be that there was a fear that the sales team would not adopt the solution.
A deeper knowledge of sales teams helps explain this. Sales teams are notorious for rejecting solutions as users. While they beg for tools to help them sell more, if they feel that a tool restricts their ability to sell then they will reject it outright and the money spent has been a waste. As a result, this is the number one fear for most organizations implementing any solution that requires the sales team to be a customer.
To address this fear and create differentiation we decided to tackle it head on and sell to it. We identified as a part of our slides, the existence of our best practice for the adoption of CPQ solutions. A document that would outline all of the things the customer should be doing to ensure that the sales team would accept the solution after it was built. We did this because we knew it was a fear and rather than ignoring it, we sold to it but only once we had developed the answer to the fear.
And this is where you create differentiation. By addressing this fear either you are addressing something the customer already knows but other organizations have failed to mention or you are identifying something new for them that other competitors have failed to discuss. Either way, you look like a trusted advisor much faster than anyone you are dealing with. We've used this process across multiple organizations now and we are still amazed at how well it works.
To summarize, selling is an art but there is a science to it. If we solidify the idea that we must listen to the customer as "the buyer" and forget that our role is to sell, we can hear what it is the customer is asking for. If we can remain grounded in the fact that we are selling a service, we can identify for the customer how they can engage in the process and ensure their project journey is successful. At the same time, to excite them about our services we must help them identify the key areas of danger that only we are able to help them conquer. The result of this is the acceleration of trust in our organization, which ultimately is what the customer wants to buy.
We run a class on services selling. If your sales team is looking to enhance its skills in services selling, get in touch.
**Enjoy what you're reading? Feel free to forward to your colleagues!**
On Belay
Sales Compensation for Services
Incentivizing sales teams to sell services depends on whether or not you are a product or a services company. In fact, the relevance of services to the sales team depends on how the company as a whole wants services to be viewed. All too often within product companies, services is disregarded as a part of the sales commission plan. I think this is a mistake because it incentivizes sales to not position services (whether through partners or our own services team) as not being a differentiator. Why is that a mistake? Because most products in most product industries are already commoditized.
Many CFO's look at services within a product company and they think, they need to minimize the incentives for selling services because they do not want the street to think that they are a product company that needs services. Selling too much services as a product company can have a negative impact on the multiples you may be able to achieve for your valuation. While there is merit to this view, it negates the fact that revenue has nothing to do with how we incentivize our sales team to win deals. For example, incentivizing sales to include services doesn't necessarily mean that we will sell more services than we want to but it can mean selling more product if we incentivize the sales team to use services as the differentiator.
The degree to which we sell services is also dependent on the degree to which we believe services is crucial in making the customer successful. If we think the customer would be better off with a partner's services, then we shouldn't incentivize them at all, but in doing so, I'd also question any existence of an internal services team that is being asked to generate profit. Product companies that think they have cracked the code on having cost-centre driven services are almost always proven wrong. As the product grows, so too does the customer's demand for expert services. The cost to maintain such a team cannot scale with the company because the cost eventually becomes a drain on margin that needs to be recouped. It is very common that upon acquiring a poor performing start up, the equity firm quickly turns the services team into a profit generating engine simply because we have learned that it needs to be that way if it is going to continue to scale with the rest of the company.
Hence, incentives for sales teams within product companies to sell services should be linked primarily to the sale of product. To do this we need to work out what our average attach rate for service to product sales is. In some companies you might find a 1 : 0.25 ratio while in others I've worked in, we have had as large as 1 : 5. Yes, our services implementation costs were about 5 times what we sold in product ARR. This can happen and if it is needed for customers to be successful then we shouldn't be afraid of it. As we grow the ARR, the large ration begins to diminish in comparison and the evaluations will right themselves.
The amount to which we pay commission on services sales within a product company should also be capped so that we are not incentivizing a situation that makes the CFO cringe at the end of a quarter. With rare exceptions, we do not want services revenues outstripping product growth and becoming the headline. Capping the services incentives gives the Sales team a good boost to their earnings while also not distracting them from selling product.
The question is often raised, should we incentivize sales on the outcome of the project? My thoughts on this are divided. Mostly I say, "No". Dragging sales into the services implementation is a waste of their time. My friend and colleague, Wayne McCulloch (author of The Seven Pillars of Customer Success) thinks that the CSM's would be a much better choice for this provided that they are also targeted and responsible for services project margins. Let the sales team get back to the job of closing deals.
On the "yes" side of the equation, I think that at a minimum Sales should be incentivized to hand the customer over to services in the best way possible. Hence, in an ideal world, I would hold off on paying any commission to a sales person until they have introduced the customer to services, walked all parties through the sales process that resulted in the project and connected our services executives to the customer's executives so that a proper stakeholder relationship can develop. In most organizations this simply doesn't happen and it kills the ability for the services team to run the project effectively. In most cases, I blame both teams. Sales doesn't do it simply because they don't see it as their role and services doesn't do it because they think it is someone else's job to own the executive relationship. It's a gap we can't afford to leave open. At a business level most exposure in an organization occur at customer handover. Whether it be marketing to sales, sales to services or services to support. The less effective the handover process is, the more likely it is we lose the customer during the handover.
With pure consulting companies the answer is much simpler. Of course we incentivize the sales team with good commissions. What changes is primarily the role you want the sales person to play once the sale is made. Depending on the existence of a customer success team you want to make sure that the relationship developed by the sales person is not lost simply because the services team is now engaged. Making sure that sales teams are connected to their customers while not being burdened by the project is key. The primary reason for doing this is that in a pure consulting company you want repeat sales. You want the customer coming back to you and asking for more services. This is not always true of a product company.
Free Climbing
Establishing Implementation Partner Programs
I'm often asked how services selling and the use of partners should be integrated. This is a complex issue that has no right or wrong answer but more or less a mindset that I think should be followed.
The first is that we need to recognize what the role of a services team is inside of a product company. In a nutshell, the role of an implementation team in a product company is to get the customer live as quickly as possible with the version of the product that is currently available. This is a very specific goal that is aligned with the primary objective of every SaaS company. Secure the renewal! The role of services in securing the customer renewal is often overlooked in this world of CSM mania. If the services team doesn't get the customer live there is no "success" to manage. What is also amplified in a SaaS world is the speed in which services gets the customer live. A 3-6 months implementation is acceptable to most companies. 6-9 months is bearable, but any more than that and it is likely that they start asking for ARR relief given that they are yet to make full use of the product they purchased.
Later than that and you might find that they simply don't renew and now you never had the customer that you actually thought you had sold. One of the most telling things I look for in a SaaS company's services portfolio is how many new customer implementations are on hold. The more on hold projects, the less likely the company is to succeed long term. It's that simple. Get your customer live, or pay the price.
Now, back to partners. If the role of the services team is to get the customer live, that means that they should be the experts in helping the product company secure its revenue. This is something that an external partner will never fully own because at the end of the day they are more concerned about their own survival than yours. Hence, partners are best suited in two other circumstances. The first, of course, is if they brought the opportunity to you. If that's the case, they should do the implementation. The second is if the customer is a repeat customer looking to do a second implementation or an enhancement. In order to keep services revenue under control, it may be worth making sure that your services team is reserved solely for the use of implementing new customers. This ensures that losses of ARR during the implementation process are kept to a minimum.
If partners are to be used, in any sense, we must make sure that we understand how to certify the skill level of partners so that you can have some control over the quality they produce. The issue and danger with partners is that no matter what you do, they will serve themselves, before you. That is not a slight on partner organizations at all, it is just business and thinking that it will ever work any other way is naive.
Hence, partners must prove themselves worthy of being counted as partners. There needs to be an educational and experience bar that separates them from the pack. Likewise, within your own organization there needs to be a distinction between Sales Partners and Implementation Partners. I've seen these programs get way too "integrated" which only leads to Sales Partners trying to implement solutions they know nothing about. If a company wants to be able to do both that is great, but there must be criteria and certification objectives in place.
As an example, some of our own clients enforce a model that only counts a partner as "certified" if they also have their consultants complete the PSCC-1 certificate. The reason being is that they want to be able to rely on their partner's ability to lead the customer as effectively as they have learned to do so. Anything else is a recipe for partners to let the customer lead the project and blame the product for the eventual failure.
The final core tenet of partnering that I will mention is how to ensure we know how to position2 ourselves as in-house implementers against partner organizations. Channel conflict must be kept to a minimum, hence I find a few rules need to be applied. The first is that we will not compete with a partner if they brought us the deal unless the customer makes a specific request and that the partner has been made aware of that request. We do not want to rip services away from a partner that we know is trying to make money from implementing our products. The second is that we do not negotiate our rates down when competing with partners. The in-house services team must remain the most expensive but also the highest value option for the customer. If we can't live up to that, then something is seriously wrong. Price matching partners is channel conflict in its worse sense. It establishes an environment that creates the illusion of a partner network that then evaporates as soon as the sales process gets real. If you start a partner program then you want it to succeed and to succeed there needs to be a place for them in the market. You cannot allow that place to be above you in quality or price, but you can allow it to be below you. That helps your customers make choices. Pay more and get the A team that works closely with the product engineers or pay less and get the B team that doesn't.
Personally, I think implementation partners are a must within every product company, but I treat the entire program cautiously. Too much focus on partners and it can damage both the outcomes we achieve in first time implementations as well as our chances for long-term customer expansion. It is important that partner programs carve out a clear space without having to conflict with their own in-house services. The wiser we are about establishing this program, the better off we will be in the long run.
Join our Summit newsletter group on LinkedIn and let us know how your firm has managed implementation partner programs.
Outside of how to manage a services P&L, I don't necessarily give a lot of management advice. However, if you wanted to know what book or training has most influenced my approach to management, it might well be this book. I did their training many years ago and while the training itself did not shake my world, a few concepts within the book did.
The Results Pyramid is a way of looking at how we can change the way a team achieves results. It works on basic principles of psychology and is not referenced solely by this book, but others such as The Culture Game by Daniel Mezick. In essence, what it describes is how belief underpins how people behave and if we want them to behave differently then we need to be focused on what they believe and how to generate experiences that help them believe something else. While many people might turn off at this point, I urge you, don't! It works and it is 100% something you need to understand as a manager of people.
The second thing this book gives you is the real benefit of both recognition but also recognition "above the line". This book makes a great distinction about how we think and communicate as managers. The first is that we all have various thoughts that are constructive and destructive. For example, that guy is difficult to work with but he is a great developer. Hence, what we need to work on is the way in which we filter or deal with this combination of emotions. If we fall below the line, "Geez, that guy is difficult", we hold each other and ourselves to be accountable to the fact that we have dropped below the line. This way of thinking is no longer productive so let's get it above the line.
The second part of this is how we use such thinking when giving recognition. Recognition creates the experience we mentioned earlier in the Results Pyramid and helps us reinforce above the line behavior in our organization. By rewarding this behavior, we set an example within our firm on what we expect from everyone.
Without getting too much into the cognitive psychology, this book explains that these tools are critical in helping you change organizational behavior and achieve new results. For most of us in professional services, this is what we are trying to achieve. We are trying to get consultants to behave in a way that generates profitable outcomes even when they are not being watched by an executive. To do that, you need to deploy the approaches laid out in this book.
If you have a book recommendation, let us know at summit@psprinciples.com
PS Principles LLC, Prospect Ave, Park Ridge, IL 60068, USA, +1 (650) 731-0001