27 Feb 2023 · 52 min
Kison Patel and Pat Bellotti discuss how to integrate sales teams and products after an acquisition without tanking revenue. They cover compensation models, which salespeople to keep, and how long the whole process takes.
We recently launched a new book titled how to Stand up an M and A Function. Even if you're an experienced M and A practitioner, standing up an M and A function is a challenge of its own. That's why my colleague John Moretta and I compiled a series of templates, perspectives and Excerpts from over 50 interviews to help you build your M and A team from scratch. Topics include the order of hiring, establishing your operating model, developing your organization's integration muscle, and more. Find it on Amazon under How to Stand up an M and A Function link is in the show Notes I'm.
Kisam Patel and you're listening to M and A Science where we talk with deal professionals and learn valuable lessons from their experience. This podcast focuses on stories, strategies and what actually happened during M and A deals.
Foreign.
Welcome to M and A Science where leading M and A practitioners share lessons learned from their experience. If you're interested in keeping up with the latest from M a science, visit mascience.com subscribe to our free newsletter Every week we share highlights from our interviews, invitations to events as we build the greatest community of forward thinking M and A practitioners. Again, that's mascience.com Kisan I'm your host Kisan Patel, CEO and founder of M and A Science. Joining me today is Pat Bellotti, VP Corporate Development Integration at Zendesk. Zendesk is a service first CRM company that builds software designed to improve customer relationships. Today we're going to continue our conversation on Go to Market Integration. Pat, how's it going?
Great, great. Kisan, good to see you again.
Hey, thanks for taking time to continue our dialogue. We didn't get a chance to talk about Go to Market so let's get things off.
Thanks Kisun. So I've been doing integration for about 22 years working at Sun, Cisco, Docusign, Microsoft and most recently Zendesk. Because we're going to talk about sales and that side of integration today, maybe I'll provide a little bit more background on how I got into sales and how did I get into sales integration along the way in my high tech career I started out in finance, then I moved into some strategic planning roles. Then I did a stint in a engineering group which was actually trying to build a suite of products bundled under one part number. And then I got a call from one of the HR people at the company and they said oh, so we just have this new organization within sun called javasoft and its purpose is to sell Java Engineer and sell Java, which was super exciting and they need a Sales operations person. Now I actually had not done in sales operations but I went and interviewed the head of sales. We hit it off and I learned so much about sales in those years that I was working with javasoft and I loved it. I felt really at home in the sales organization. So I continued in sales operations type roles for several years. And then Sun Microsystems decided to create a integration team modeled after the one at Cisco. And one of the roles was a sales integration lead. And I'm like, oh, that's my job, I have to have that job. I fought for that job and I got that job for my time at Sun. I just did sales integration and then I moved over to Cisco and started in sales integration and then eventually switched over to general integration. When I was doing sales integration there were not very many companies in the beginning who had anybody on that side of the business. They seldom had marketing integration or engineering or sales. It was all about HR and finance and IT and that sort of thing. And I think they just thought that the business groups would handle the go to market side. But. But of course a business group is made up of engineers to a large extent and the salespeople aren't integrated in that. It was really interesting to build it and then to see other companies decide that they too needed to put more attention. And I think if you go over the whole 20 years there's been a dramatic shift. It's not that those other elements, the people and the HR and the IT and all that. It's not that they're role has been diminished at all. That's still there and it's still super important. They've gotten very good at it. And meanwhile there was this sort of deficit on the go to market side, which I think is why so many companies are really paying attention to it. You've made it a big focus of your recent podcasts. So anyway, that's how I ended up on that sales side. And even when I'm a general integration lead, I can't help but over function in the sales area. So I'll apologize in advance to all the sales integration people I've ever worked with who I'm constantly like, what about this? What about this? So apologies in advance for those folks.
When we reference sales integration and then go to market. What is go to market encompassing?
I would say that the go to market encompasses all of those functions from marketing to generate leads through of course the sales team, the support team. If you have professional services, that's the customer facing roles. And then of course there's a whole slew of back office roles that support that. But it is the whole soup to nuts. And it includes, of course, very prominently the product and engineering group's plans. Maybe you put the product managers into the go to market channel, not so much the engineers. It's that product marketing person who's sort of the bridge between the two, which is why that job is so hard, because everything that somebody else doesn't own is owned by product management.
Why is go to market integration so important?
At the end of the day, companies need to generate revenue. And usually most deals are justified on revenue. Not always. But even if they're like, this is talent and we're bringing this talent in, why are you bringing the talent in? So they can make a product so that we can sell it. Unless you're in some sort of altruistic endeavor. Revenue is the reason at the end of the day. And so it's really important. And it's all about the customer and it's very disruptive to customers. When there's an acquisition and integration and there's so many things that can go wrong. The team is not motivated. The sales reps don't like it, People start to try to poach your team, competitors start to fud all sorts of things. Oh, you don't want to go with them because that's not going to work for you and come over to us and it's a very dangerous time. On the other hand, you can really knock it out of the park, especially if your customers are almost telling you, boy, I wish you would buy those guys. And that happens sometimes. Because if you're a major enterprise company and you really like the technology of some really small company, but good luck getting that past your procurement team or your legal team, because they're going to say, oh, they're too small. It's too risky for us to contract this important piece of our infrastructure to such a small company. Sometimes your customers will say, boy, I think this would really fit your portfolio well, we'd love it if you guys would think about buying them. That's a big win.
Revenues, the customer experience. Can you give me two examples of go to market integration gone terrible and go to market integration gone really well.
I'll tell you one that went really well. I'm going to acknowledge James Harris at Google for two terms that he uses for the acquirer and the acquired company that I thought were much nicer than acquirer and target. He used host, I guess, meaning the acquirer and inbound team. Referencing the team that's being acquired. So I'm going to try to use those two terms in this case, the host company and the inbound team had been working together as partners. They were in a partnership and customers liked using the products together, but they were separate products. The teams knew each other. The host company decided to make the acquisition and they needed a period of time to get the product into the host company's suite. So during that time they kept the sales force, and I'll talk about this later, this model, they kept the salesforce selling and they worked very hard to get the products integrated quickly. Now, one of the things they found is, of course, if you keep selling the product and you're going to put it in your suite and you're not going to charge anything extra for it, once it's in your suite, the people that you have sold it to in the last six months are probably not going to be super happy because all of a sudden it's free. And so in that case, we actually had to refund those. So if you're doing a business model and you're following that format, make sure you put the refunds in your business model because you, you can't. But at the meantime, it kept the product in market, it kept the salesforce motivated, it got the customers on board. And you know, realistically, it's, there's not a negative there, but you did pay commissions on stuff that you didn't actually bring revenue in on, but that's okay. And meanwhile, that sales team, and this was, again, you don't always have this, but the sales team was excellent. And they were much broader than just their standalone product. So while they were still selling their standalone, they were ramping up on the larger hosted product. So that by the time they were integrated, those reps turned into reps representing the full suite. So it worked out really well. And I would attribute the things to the fact that they understood exactly where they wanted to go. They focused on that. They manage the sales team really well and the product's been a huge success. So that was a great one. One of the things that is your worst case scenario, this is really bad. And I've seen this happen a couple of times. You acquire this product and it's more complicated than what you sell standardly. So your general post account rep cannot sell this product by themselves. They have to have someone helping them. Now, if you get rid of all the sales reps from the inbound company, you're going to have nobody to do that. If you turn the inbound sales reps into Generalists. And your product is easier to sell than theirs. They will start selling your product, which is great for your product, but of course you just tanked the acquired product. And even worse is if there's a competitive product in the market and your account reps have no help to sell the acquired product, they might actually tell the customer to go buy the product from a third party because they can't sell it, they can't represent it. If they try to sell it to your customer with no support, odds are it's not going to go well. Might mess up their deal. And so isn't it just easier to tell the customer, oh, go get that piece from that other company and let that other company take care of it. That's your nightmare scenario. And I've seen that happen. And you try to say this isn't going to end well, but people are funny. Maybe they've got their eyes set on a different part of the goal or they actually don't believe that product's so hard to sell. Oh my reps will pick that up real quick. Well, no, if it's really hard, they might not.
What makes go to market integration so hard?
A lot of people in business functions, in sales, in even marketing and engineering don't really understand how sales works. They don't understand it. They make references to reps as being coin operated or that's consulting, because that's not really true. Good reps are motivated by satisfying their customers. The fact that they get paid really well is a nice thing. And I know they're motivated by that. I don't mean to downplay that, but there's a lot more to it. I don't know that those other functions quite understand how it really works. And so they tend to make assumptions about sales and how sales works. And smart ones bring sales people into their product planning meetings, their pricing meetings, all that. They are such a source of reality check. I remember there was a pricing committee at one of my companies I worked for. And of course the sales guy who was assigned to sit with us on the pricing committee was often traveling so we didn't have him all the time. But whenever he was there it was like the meeting was ten times better because the product group would say, oh, we're going to charge blah blah blah for this. And he just look at him and you go, yeah. So have you figured out what your competitors charge? And da da da da, they're not going to buy that. That's not going to work. They just have insights into the reality of the market. That are super helpful.
I want to try to walk through the timeline of planning this and what I'm trying to get to is the key decisions. Seems like some of this stuff shapes early and then because you only have so many things, you could actually one information you have and then some of the stuff comes after you get the deal done. Can we walk through that from the very beginning? Does it even start before loi?
Oh, definitely, because before loi, you make a P and L. You make your business case that you're going to present to justify whatever price you're going to present and negotiate in the loi. So that business case has got to have elements of headcount and that sort of stuff. So you have to have an idea. There's about six or seven things that I want to know as an integration lead and a sales integration lead. I want to know the answers to these like six questions right out of the blocks and then I want to know what is the plan to get the revenue? What parameters are we working under? So let me talk about the six and then I'll talk about those parameters and then we'll see how they meet in various scenarios. So one of the first things I want to know about the inbound company is how many customers they have and how many of those customers are my customers. Now, sometimes customer lists are are confidential and things like that. But frankly, most larger software companies and smaller software companies, they put a lot of their logos on their website. So it's not like it's a big secret. So I want to know, do they have the kind of customers I have? Are they the same customers? And that sort of thing that's important to me and why it's important is if it's a volume of customers and I'm going to do something dramatic that's going to affect my timeline and my costs. If they have a small number of customers, maybe moving them onto something new isn't that hard. But if they're key customers of mine and what I intend to do with the product does not actually achieve parity with what they have today, they'll have a more significant influence on what I'm allowed to do. It's like we can't eol that product because that customer is really important to us and they really like it. That sort of thing, you get into that sort of thing. So understanding the customers is important. The next very important piece is the product plan. To be honest, sometimes you don't know exactly what you're going to do as early as pre loi, but you got to take a guess. So is the guess I'm just going to continue to sell this product standalone. It's a standalone product. I'm going to bring it into my company, I'm going to keep selling it standalone, or am I going to put it inside something I already sell? And if I do that, am I going to charge or am I not going to charge? Am I going to increase the price or charge separately as a module or something like that? And part of that also is thinking about how long that's going to take if I decide I'm going to stick it in my product. Especially if you're a large enterprise company and you're acquiring something from a smaller company, there's a huge, what we call technical debt. Because security, privacy, even the way they manage the code might all have to be modified in order to meet the larger enterprises criteria for putting their brand on the product, knowing what you want to do with it and how long it might take. And this is a big debate, there's the optimists and the pessimists about how long these things take. One of the factors that weighs in on that timeline, you can't just go hire a bunch of contractors to fix the things that you need to fix because it's the people who designed it who can fix it. But then you also want them getting it into your product. I mentioned earlier product parity, understanding whether whatever you do with it, do you have to make it exactly the same or can you just make it what it should be and recognize that migration path for some customers might be uncomfortable and maybe you're going to have to help them, which again adds cost, which you might want to think about putting in there. So those are three sort of product things. Then you've got the actual makeup of the sales team. Who is the sales team? Are they account managers? Meaning they sell all of the products of the inbound company and they go direct to the customer. They are the single face to the customer for that product. Are, are they technical? Is it a technical sell and these people are pretty technical? Or are they classic account reps, handshaking, back patting guys? And they have sales engineers that help them with the more technical aspects. So understanding what type of rep they have and whether they have ses and then you have, do you have a place to put the reps? So this is an interesting dilemma for many companies. Most companies have account reps that sort of sell the whole portfolio. If you have one unified thing and it's all at the same level of expertise and that you just need those types of reps and they sell into the account. But if you get more complex products, more specialized products, even products that map maybe to a vertical or something like that, then you have to have specialist reps. And specialist reps, they go out with those account reps. So here's what happens. If you acquire a team of sales reps that know their product really well, they don't know your portfolio. You're going to have to rely on your account reps to be the face to the customer. But you need these specialists to support. So first thing you can do with them is you make them overlay specialists. This is the common format. Make them an overlay specialist. They don't like to be called overlay, so you might want to avoid that word. But that is what they are. In a way, they're not thrilled about that because they're not the single face to that customer anymore. They're part of a team. That's the model. Okay, so they're going to be a specialist. So where do I park that specialist? I have three places I can park a specialist. The first place I can park a specialist, which I think is the ideal, is if you have an incubation sales specialist organization. They're organized at a worldwide basis. So all the worldwide people report into the same leader in the incubation sales area and you farm them out to support the team. The second scenario is you don't have an incubation sales organization and you decide to park them in the business unit which has engineers in it, doesn't have incentive comp in it might have some business development people in it. So you turn them into business development people who aren't on quota. Sales reps like to be on quota. So now you put them in an engineering group where what they like to do and the care and feeding that they need isn't really available. So not ideal. Can you park them there for a short period of time? Probably, but not ideal. And the third place you can park them is you can give them to the geographies. So you say, oh, these are specialist people. And I'm going to give. These guys are in APAC and these are in Europe and these are in the US and they're going to go in there and what's going to happen is the next time there's a layoff, those people are the most vulnerable because they don't carry big quotas. They carry a specialist quota and you're worldwide. Your APAC person says, My reps carry $50 million quotas, and these guys carry a $3 million quota. I wonder what I'm going to do with that headcount. So it's very vulnerable for those folks. So ideally you have an incubation sales team, especially if you're a serial acquirer. This is going to happen time and time again. It behooves you to do that. Those are kind of the three there. And the last thing I also mentioned earlier is just how hard is their product to sell versus yours? That matters. So those are the elements that I need to know. I need to know those things and then going across, what I want to do is I want to understand what requirements are on me as far as when I have to generate revenue and what can I do. Scenario one is finance has said this deal has to be accretive in the first year. We need that revenue to continue and no slowdown in that revenue. Okay, that's fine. You should know that you're going to need to run that business off of inbound teams, whole infrastructure with their sales reps in order to generate that revenue. So that has a big impact on your plans for headcount, who you're going to keep and not keep. You can't get rid of finance people that are running quote to cash. You've got to keep that team because you've got to keep that revenue going. So that tells you one thing. The problem with that is if your end goal is to have that product inside your product, Those engineers aren't 100% free to focus on that because anytime you're still selling, they're still involved. Customers have problems. Level 3 support. Big customers want a special modification, whatever. Your engineers are going to be occupied helping those customers. So that's your one one scenario. The next scenario is that your company's actually willing to wait. They're actually willing to wait maybe 12 months for you to get that product on your price list. 12 months may not be enough time for it to be fully integrated and fully up to speed and perfect, but it's probably enough for you to get it on the price list. That's a second scenario there. You might start by having them continue to sell it on their systems and then prepare to cut over at a year. And the last scenario is you're really focused on the long term. And so in that case, again, depending on where the product is, you might actually stop selling the product to new people. You might actually say, it's more important for me to get these pieces in there and make them perfect than to keep selling that Takes a lot of guts and probably means that the products you're acquiring are early stage enough that stepping out of the market for a period of time is not all that disruptive. If you really want to build the perfect product with all these little pieces, that's one strategy. So I've gone on and on there a bit but as you can see you got to mix and match these things and see which ones work. And something I completely skipped Kisan, is that I'm not even talking about back office compatibilities or any of that stuff which also has to be factored in. I'm really talking sort of on the front facing part of it. But if you acquire a product, we all lived through this while we were working for On Prem companies that sold On Prem software and then all of a sudden we started acquiring companies that were software as a service and of course the systems had no idea what to do with those. And it took years for many companies to cut over from on Prem to SaaS. That's a major lift. So you can't discount backend compatibility.
It's a lot of homework to do up front. You talked about how many customers they got, how many are common, understand their product plan, understand if this is something you're going to keep as a standalone versus integrate, how long is it going to take to do that product parity? We talked about the type of sales rep, what's that structures look like for expected company, where's the home going to be for the reps, how hard is their solution to sell?
That's the list. There's a lot of things things there but that's the scenario.
We're working with the finance folks that want the deal to be accretive from year one. That's where we factor that into the model to make this deal work.
Yeah.
Is there anything you do there to balance that out? To say hey if I'm going to be part and execute on this, how do we get alignment there to make sure that seems like this is an important thing to get aligned around?
Yeah, I think it is. It helps a lot if the teams and that includes finance leadership and the engineering group and the sales leadership all coming together and saying the value driver of this deal is X. What is that? Is that short term or is that something that has huge potential, we need to get it right. Maybe we need to have this as an investment but that's a hard sell. A especially depending on where the markets are at the time and of course where the pricing of startups is. Although it can Be very pricey times or maybe a discounted time. So maybe you have a better chance of selling. This is going to take a couple of years when the prices are low and maybe are a bargain. Maybe your P and L is going to allow you to have more time versus the prices are really high and people are like, wow, this return better come quick because it's pretty expensive. That also probably factors in. But if you can get the parties aligned on where the value is going to come from, which is different than the strategic rationale for the deal. By the way, sometimes people put, especially Corp Dev people, they'll say the strategic rationale for the deal is X, Y and Z. I'll give you an example. So what if you had a scenario where the value driver of the deal was retention, it was the people, it was the talent. A strategic rationale is we're going to get some great talent. That is not a description of a value driver around talent. A value driver around talent would be the value of this talent to this deal and the company is that they have unique artificial intelligence staff. So that's one value driver. That's a value driver. Saying, I got great talent, they're going to do cool things might be a strategic rationale, but the value driver is I'm going to get unique talent in AI. But what if I said that there's a second value driver of this particular company's talent, which is they are very connected to the university system and they are very connected to the pipeline of AI PhDs. Oh, okay. That's an important value driver. They're going to give us a pipeline in there. Now that you've identified that value driver, how you work with the team and what kind of hiring arrangement you make with those people could be different because you're factoring in that pipeline. So as an example, I suppose in one scenario you could say, yeah, that guy's teaching at that college, but I want him full time because I want all that AI knowledge. Okay, so he quits his job there and you have this guy with AI knowledge. But if you recognize that there was a second piece of value driver which was a pipeline, you might go, oh, wait a minute, I don't want that guy to quit. That's my where the pipeline is from. So maybe there's something I can work out where we can do something, maybe even work with the university to come up with some sort of an arrangement or something about that person. What I'm trying to stress there is value drivers. They have to be able to answer the question how am I going to get that value? Whereas strategic rationales say the value is this. The value driver says, this is how I'm going to get the value out of that. And the same holds for revenue. Am I going to get the revenue just continuing to sell this product standalone? To be honest, if that product has an average deal value that is 1/100th of what your reps are used to selling at. No, they're not going to sell it. They're not going to sell it. Even if it's only a fifth of what you have. You're saying my strategic rationale is that we're going to be able to sell a lot of these things. I remember actually a company I worked for early on bought a company that made a little blue box. So that company made a little blue box that sold for $1,000. And the CEO of Post Company said, this is great. If every one of my. This is a quote. If every one of my 10,000 reps sell one of these, that will be great. I'm sorry, that was just like ridiculous because none of those reps are going to sell one thing worth $1,000. What should have happened is we should have identified 100 customers who were going to buy thousands of these little blue boxes. That should have been the strategy. So again, talking about these factors that we talked about before, harder, easier to sell price. Why would a rep who's used to selling things that sell for hundreds of thousands of dollars sell one of those blue boxes? Not going to happen. And didn't happen. Did not happen.
If we're trying to shape that into a value driver, are we trying to build that specific of a goal and saying our value driver would be to take that blue box, sell it to.
A hundred customers, sell thousands of them to the top customers. That's how we're going to get the value. That's the how. So they're going to say, we're going to sell a lot of those boxes. Yeah. Okay. The value driver is we're going to sell a lot of those boxes by selling them in volume to customers who would want them in volume. Not honestly every rep is going to sell one.
Let's go back to our deal timeline because we're loi. We got a lot of this information. Team puts model together. We've thought through if we're going to wait to integrate or not. And some of these things. How does that progress, how does planning for go to market integration progress? As the yield timeline continues, you get.
Into due diligence and you find out a Lot more. And you might have to fine tune and, and in the area of go to market, frankly, there are often things that you can't see in advance. They're just too sensitive. Pricing and contracts and some of that stuff. So you will not have perfect information until after close and you need to factor that in. But the due diligence should definitely give you ideas on more insight on the reps. Are they achieving their goals? Are they way behind? You're interviewing them, you're talking to them. How technical or not technical are they? It's a learning thing all through diligence. And then you're saying one of the challenges for sales. Actually now that I'm thinking about this, when you come out of diligence, assuming you're not doing regulatory approval, you're going to close pretty quick. And unlike some functions that don't actually have to do anything different on day one, the sales organizations and the customer facing people at both companies need to know exactly what they should say, exactly what is their engagement model with each other. Is there compensation? Do I get comped on their product? Do they get comped on my product? Who's the lead? As we go into the account, there are like a hundred things that a field facing person would like you to tell them on day one. So during that due diligence, you have to be working on those answers because you don't want to look foolish in front of the customer. We had one scenario. It turned out that the host company had a product in this product area and the inbound company had a product in exactly the same area. So there are direct overlaps. And so we said, okay, the enterprise rep for these accounts is the quarterback and the host company specialist is on the team and the inbound company specialist is on the team. So I've now got three people who are on the team. They're going to go into the customer together and frankly they're going to let the customer decide which option they want. It's customer's choice. We're going to be neutral about it. It's going to take us some time to integrate the products. We're going to guarantee that path is there. But in the short term, either one is fine with us. Let's leave it to the customer. So of course what you have to do then is you've got to cross comp. All three of those people have to get comped. If any one of those people is out of the comp, then they're not going to do this neutral thing. They're going to lobby for their product because that's the only way they're getting paid. So the first thing you have to admit is I'm going to pay them all. And finance is heartburn. I don't want to pay all those people. You quoted them all and you pay them all and it's not quite as bad as it sounds. So I remember hearing that somebody from another part of the company was at one of these big executive meetings and he said, I was just visiting customer A and three of our people came in at the same time to pitch this solution. There was an account manager and then there was a person who represented this and then there was the person who represented that. There were three people in there. And I was like, oh my God. It actually worked all those. It was a per. But this person was like complaining that there were three people in there. And I was thrilled that there were three. I wasn't in the meeting, I heard about it later, but I was thrilled. Yes, that was the plan. The plan was to have them do that. So they really need to know that stuff right away. So you have to be working on that during due diligence.
Where are the big ticket items to make sure you get clarified? I know commission's a big one.
Commissions engagement model. Who's going to do deal approval? Sometimes the host company wants to insert one of their finance people into the deal approval process of the inbound company. Kind of fiduciary thing. Or they just want to have a little bit of influence there. Training. Even if their rep is still just selling their thing and your reps are just selling your thing, they should at least be familiar. The inbound need to at least understand your general product line and the host company needs to at least be familiar enough with the new product to be able to pass a lead or something like that. One time there was a very large acquisition and the inbound company was supposed to take training on the host company's portfolio. It was like a two hour online training. We had actually hosted this training with a third party. So we created the training, we gave it to a third party to host and we told the 1500 reps of the inbound company to take the training. The week went by and frankly you could tell by GEO who was actually doing it and there were several large groups that had not done it. So the head of sales sent out this scathing note to his team. Folks, I want you to get this done in the next two days. It's two hours, just do it. And the next thing we heard, of course is they all went online and at exactly the same time and it crashed. The third party hosting company site. So the site went down and then it kept crashing because, you know, reps, I was told to do this, I'm going to do it. I couldn't get in. I'll try again in 10 minutes. But eventually they all did it. So that's a good one.
A lot of good information that we got to pick through in diligence. The people involved with this, the stakeholders. I feel like the thing you hear that you got a LOI signed or you closed on the deal and there's no go to market integration plan. How do you do the opposite? How do you make sure you got the right people thinking through so that there is a good go to market integration plan.
You have to have someone on your integration team who is helping drive that. They can't. It belongs to the product team, the engineering team, the marketing team, the sales team. It belongs to them. It's their plan. But to be honest, they're not very experienced in writing a plan for a product that they didn't build in house. Because when they build it in house, they've got an entire infrastructure. Most companies have, you know, these, how do you design the product? And you get a requirements document and then it goes through all these phases and everybody knows where they play and you've got a launch team and all that stuff is great and everybody knows how to do that. When you acquire a product, it's already in the market. So you're not gonna go back to ground. You're not gonna say, okay, let's hold everything. Let's start over here at step one. No odds are you're gonna actually do maybe step two and three quickly, which might be stuff around technical debt, stuff that might have been missed. And then you're gonna get into sort of launch area stuff that you have to do. And general business teams are not accustomed to doing that. And therefore you have to have someone who can guide them. At several of the companies I've worked at, they have people that are within the integration infrastructure. They're with functional teams. Usually they're not part of the imo. They're either from sales, they might be from marketing, they could be from product, and they have to drive that everybody else should be supporting them because everybody else's plans are highly dependent on that plan. How can you plan headcount if you don't know what the go to market plan is? You can't. How can you plan for it if you don't know what the go to market plan is and what the timing is likely to be. It's in everybody's best interest to support the people who are trying to get a go to market plan plan written. And again, it's not written in stone. You learn new stuff all the time and you have to be agile. You can plug your book now, so you have to be agile about it. You go back to that value driver. Is what we're talking about today going to get us there? Maybe something happens so dramatically that you actually change a value driver, but that's pretty rare. Usually those things are why you did the deal and you just have to figure out how to make it work.
In terms of the strategy for integrating go to market, does it fall into a specific number of buckets? Hey, we're buying a product and we're keeping their sales team. Where, I don't know. If you just buy the sales team and not so much of the product, you know, is there a certain, like common configurations you see in terms of a strategy?
Yeah, there are. But to get to them, you gotta have those factors. So you gotta have those factors. Then you gotta have those. What are your value drivers and what are you going to be required to do once you have those? You could have a scenario. I'll actually give you one. I'm going to give you the typical one. I'm going to call this scenario Accelerate. To leverage your sales machine, you need to have that really running in 12 months. So you get 12 months. So what are you going to do? So the first thing you're going to do is you want their engineers to really focus on getting the product on the price list and getting it qualified to be sold from you, either as part of a suite or standalone. You're going to continue selling through their reps so their reps will continue to sell it, knowing that if you're going to put it in your product and not charge for it, you might have to do some refunding or something along that line. You should consider comping your reps on sales of the newly acquired product. And you might say, why am I going to do that? They're not helping with the sale. Why would I comp my reps on the newly acquired product? You want the two sets of reps to get to know one another and start strategizing on joint activities. Your reps aren't going to do that if they're not going to get any comp for it. Likewise, they're not going to pass any leads to those people. Maybe altruistically they will, but in general they probably won't because they're just not going to bother with it. And worst case scenario, the inbound rep is in an account already selling their offering. Your rep sees them in there and actually starts to block them. They block them because they're nervous that might add time to their sale skills schedule. They're blocking them because that's going to eat up share of wallet that they want. So there's a lot of reasons that you actually do want to comp your reps on sales of the target product and you don't even require them to prove that they help because it's a paperwork disaster. And why waste your time on that? To be honest, to do that for the part of the year that's left before you can actually goal your your reps on their product, it's not that expensive. It takes them several months to even engage. So I like that we did that at several companies. I know the finance people do not love that because it's a lot of paperwork for them. And you of course want to train your sellers on their product and then their sellers again, they're selling somewhat overlay, but somewhat independent. And then once the product is released under your system, they are pure overlay.
How easy it is to do that, like just train on cross selling. I often hear that's where things typically fall short in terms of estimates.
Cross selling, I'm not sure. I don't know if I really use the term cross selling. Again, my experience to a large extent is large enterprise companies acquiring smaller companies. So it usually does not make sense to have the inbound company turn into generalists because usually the other company has such a huge portfolio and it doesn't necessarily make sense for the large company to deeply train their generalists on one product, which is why the specialist overlay model tends to work. I guess if you've got two products like we had with that scenario I mentioned earlier, where we had the three, we had the account rep and the two specialists. Obviously once we got the inbound team's product on our price list, the two specialist teams blended, but they already knew that product line very well. Okay, you did it slightly differently than we did, but maybe people use cross sell a bit as a. They're really talking about the acquiring company selling the inbound company's product, not really the reverse.
How do you know if you're successful in integrating?
Go to market One, the revenue's coming in two, the sales team is staying. A lot of times people think those sales teams Leave real fast. That's not been my experience. If you give them a decent comp plan and you line up the comp structure, the engagement model, the training correctly, they're making money. They're not going to leave some of them again. You've got hunters and farmers. I suppose your high flying hunter reps want to go slay the new dragon at the new company and you're not going to keep those people anyway. And sometimes, frankly, your head of sales, you're not going to keep because they're all about building, they're all about building a team. And sometimes you should even consider whether you're going to keep the head of sales if the number two salesperson is good and moving up in a larger company might be of interest to that person. Sometimes you're better off letting the person who's a builder go build somewhere else. You take the next person down who's. They'll view this as a huge opportunity to do something with the team that they've been working with. But they're not necessarily going to be chomping at the bit to build a new team. So that can be a good strategy.
You got any hacks to make sure all this works out well?
For people who worked with me at Cisco, they'll remember my very famous sales playbooks that were ready on day one for the sales team that had everything they needed to know about what was going to happen. And people would say to me, they'd say, pat, no one is reading your playbook. Nobody reads that playbook. And I said, the truth of it is that the playbook itself is a byproduct. The actual thing I'm trying to do is get all those teams that have to run one of those processes. They have to articulate it for the playbook, which means they have to have it. So you can't write down the engagement model if you haven't thought about how it's going to work. You can't write down how the commissions are going to work. You can't write down how the training is scheduled and when it will be if you haven't created it and done it. In fact, the playbook, I never cared if anybody read the playbook. It was all about getting it written. But you can't tell people that. Now I've given it away. Now everybody knows the playbook is a total ruse. But it was very valuable because it served that purpose.
Yeah, going through the motion of making it.
Got to have a deadline, got to have a critical in sales, you got to have a Critical event, an eminent event that forces decisions and production.
Pat, what's the craziest thing you've seen in M and A?
I'll tell you one and because it's a sales related one and this actually happened now, I learned from it. So first I'll tell you what happened and then I'll tell you what I learned from it. What happened was the head of international sales of a company that was acquired, he left right after he got his commission and bonus at the end of the first year he left and he took 100% of the international reps with him. The entire team. Disaster. Disaster. So what was the learning? We should have gotten to know that guy a little bit better. But find out if you're looking at a team and not a big team. It doesn't work with a big team. But if you're looking at a small team and you've got a serial sales executive, find out how many of the people that are on their sales team right now were on their sales team at their previous two companies. And if that's the case, you better be prepared. That person's going to go at some point because heads of sales just do that and oh my goodness, guess where the people are going to go. You might get a six month lag because that person has to get settled into the new role, but they'll go get them because they've done it twice already. So I learned that lesson and I've seen it happen. And then you go, okay, wait, point taken.
Definitely putting that one in the books. Yeah, this has been great conversation. I appreciate taking the time to come hang out.
I love this work. I love the people that do it. I tell people you just get addicted to trying to make it better. We're so self critical in this field of integration and I love that because it pushes us to constantly share with each other because we all know nobody has it totally figured out. I just love it. I love the people that are in it and I feel very blessed.
I'm appreciative that you took the time and shared some of your lessons learned from experience. Helped me become a better M and a scientist.
Thank you Kisan. Always a pleasure.
Hey those of you with us, thank you. Until next time, here's to the deal.
Thank you for taking the time to explore the world of M and A with our podcast. We love hearing feedback. Tag us on a LinkedIn post, add a review on Apple podcasts. We'd love to hear from you. If you need help standing up an M and A function or optimizing one that you already have. We're here to help, and if we can't help you, we probably know someone that can. You can reach out to me by email Kisan K I S o n a science.com or you can text me directly at 312-857-3711. If you just want to keep learning at your own pace, visit mascience.com for a lot more content and resources. That's where you can also subscribe to our newsletter. Again, that's mascience.com here's to the deal. Views and opinions expressed on M and A Science reflect only those individuals and do not reflect the views of any company or entity mentioned or affiliated with any individual. This podcast is purely educational and is not intended to serve as a basis for any investment or financial decisions.




