Go-To-Market Integration Planning Part 1

It is shocking how many companies are still getting scammed by per page price virtual data rooms. In the past 12 months, Firm Room has saved corporations over $80 million in per page fees. Now we're stepping it up big time with Firm Room's new 50 gig data plan. For only $1,000 per month, that's over 500,000 pages. You'd spend hundreds of thousands of dollars with any per page VDR provider for similar storage. Firmroom is trusted by top 10 private equity, IB and law firms for IPOs and M&A. If you're spending more than $10,000 on a VDR, let's show you the easiest way to cut your deal expenses. Visit firmroom.com There's a free trial so you can compare directly side by side with your current solution and see why the best in MA are switching again. That's firmroom.com, an M& A science company. 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 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 and a science, visit mascience.com, subscribe to our free newsletter. Every Monday we share highlights from our interviews and invitations to events as we build the greatest community of forward thinking M and A practitioners. And that's mascience.com also shout out to VRC for letting us use their office space in Midtown. You can hire any firm to do your valuation, but if you want to work with the best, check out VRC Valuation Research Corporation. I'm your host, Kisan Patel, CEO and Founder of M and A Science. Joining me today is James Harris, Principal Corporate Development Integration at Google. Those of you not familiar with Google Google it. Google's traded on NASDAQ under G O O G L. Today we're going to talk about go to Market Integration Planning. How's it going? James, welcome back.

Oh it's good to see you again Kisana. It's been a little too long so yeah, always good to chat with you. So looking forward to this conversation.

Hey, I'm glad you make it time between deals. Going from one multi billion dollar deal to the next multibillion dollar deal. I won't give you too much of a hard time. Do you want to kick off with your background?

I've been doing M and A for probably over 20 years now. The last 10 years I've been doing it here at Google and doing M and A at Google can be a wide range of deals. Am focusing on cloud deals. So there's a couple nice multibillion dollar deals here. But some of the more unique deals I've done at Google range from a kite company to a balloon company to manufacturing companies. The whole gambit which is one of the nice things about doing M and A here at Google. Before Google I did M and A also at Amazon and F5 and before moving into M and A I held roles in development management and program management, which has been very helpful in working in a tech heavy M and A integration. It's always good to at least understand enough of the technology to ask some basic questions.

It means you're good at engineering deals. Yeah, that's what I want to learn today. So this is an interesting topic too given you've worked on a diverse set of deals where I want to unpack go to market. I've talked to a number of companies and as their M and A function matures, it seems the biggest value leak is the synergies anticipated around revenues. And it's just always that the challenging thing to execute on is the go to market integration. And that's where things go awry. Don't hit those target numbers or it takes way longer than anticipated. Even for some of those more frequent acquirers become the bottleneck. They can't integrate these products through the go to market fast enough. So then you got that as the big slowdown.

It's a challenge. You would think engineering would be the place where it's hard because you're merging code bases and teams and building new products. But the go to market piece is the part that I think, as you said, is an area that people tend to have more challenges with. I actually think it's an opportunity for a lot of places to think about how to improve that end to end. You ask anybody about M and A, they always think we could always be better. But then you ask them about their go to market pieces and there's a few companies out there that say hey, we really have this working. But they also say it took us a long time to get there. It's a good conversation to start having. I really think it's very important. You mentioned synergies and I think about synergies in two levels. There's downside synergies which is like cost cutting and oftentimes GNA and go to market go hand in hand. And you're talking about systems and teams and resources and why do we need two marketing teams? Why do we need two sales teams? Why do we need two support teams? And I think there is a point there where you can look at that. But the downside with, I would say, cost cutting synergies is the only value you can get to is 0. You can wind down all the systems, but that's the net gain. It's zero. It's not a positive. I think that really shifts to the upside synergies. That's focusing on the now you have two companies, two teams, two sets of products, and it's one plus one equals two or three. What's a force multiplier that you can look at to apply there? That's where I think there's a lot of opportunity to think about how to improve your processes and think about how to get better at this, how you improve or bring value to the customer. Now you have two things. Is that two things that are really helpful? Is there two things? And you add a third thing that you've also had that can create real value. I think really focusing the conversation around that is way better than downside synergies. It's the upside synergies. As one of my favorite CEOs used to say, revenue solves all problems. And I think that is the more you can get direct revenue and address it, that just helps address all of your modeling, all your thought processes.

Not to start off with this is how we're going to cut costs on this deal and build our business case here. Before that, start from the top. Why is go to market important?

It's your interaction with the customer. Your customer is so critical and so key for businesses. And it's easy to assume that you know what the customer wants or understand what the customer wants. And you really need to have high customer empathy, high customer understanding, and really make sure that when you're doing the transaction, you're not internally thinking about what's best for the customer. You've actually listened to the customer and really you're delivering something for them that they want. That's a challenge. And we can talk a little bit more about that as where does product management think that this is a great cool thing and engineering think this is a great cool thing, but you need to go talk to your salesforce because they're the ones that are selling all those great cool things. And will the customer actually buy it? Is it something that they really need? That's a kind of an early test for me in a Deal. Who's driving the process? If the sales organization is not part of that conversation and even the support organization, you really may be fooling yourself into kind of, oh, this is all wonderful and great and we've created the greatest one plus one widget that we can sell to customers. And that reality check from Salesforce is really critical. They gotta write that check. They're the ones who gotta bring in the revenue. They say, you know, this is really hard and a difficult, challenging sales cycle. Then you need to listen to that, think about that. You need to walk in with that with your eyes open.

I'm hearing improve the process end to end and customer understanding them, empathizing with them.

Yeah.

Where does it start? Where is the very beginning of this start?

You start always with the deal thesis. And the deal thesis is always, hey, what are we trying to do here? And most of the time it's in a response to customer needs. It's a response to maybe a product gap or it's a response and a way to accelerate a product roadmap. Those are all great things to look at. I think. Then the next question is how do you make sure the customer sees that value, views that value as something that's an additional ad that is either and I mean by ad is that are they paying extra for this or are they going to buy more what you created so that they can. It makes their lives easier. I think having that conversation and testing it with the salesforce and I actually like to test the salesforce in two levels. There's usually an optimistic side of the salesforce, hey, this is awesome. We can sell it to a pessimistic side where it's oh wow, there's all these challenges or these headwinds to think about. It's really getting at that thesis and can we really deliver on it? Building detailed financial models and thinking about the projections is really important and a strong exercise there and making sure everybody's signing up for those projections. If you're predicting a hockey stick growth and you're assuming a bunch of engineering roadmap deliverables to make that hockey stick growth, well then engineering needs to be on the hook to actually get things done. It's not just a Salesforce thing. So I actually look at the strategy as the three legged stool. There's the sales team, there's the engineering team, and then there's the product team. And all three of them have to be thinking in the same line. And being aligning product is thinking kind of several steps out. What's the key Areas we want to do, the sales team is the rubber hits the road. How do we get something in the customer's hands and make money at it? And the engineering team is building all that. So you need all three to be aligned. If two are aligned and the other one isn't there, that's when alarm bells go off in my head.

The deal thesis is where this all starts. What's the format look like? How extensive does that look? Does it sort of evolve as you progress with the deal or you paint this picture on a one pager and said all right, let's build on this. To make the question more complicated, is the customer perspective, is that even added into that deal thesis?

Most companies all have some kind of high level deal thesis hypothesis. I always like if it's early stage asking the question what do we have to believe? Is it that we can upsell the product to 50% of our customers? I'm throwing out numbers here. If that's a core assumption, then that's something we need to make sure we're all agreeing to or understanding. As you're going through and doing the due diligence, you may find out that Maybe it's not 50% but it's 37 and 37 is fine, that's great. Then you need to adjust the reality there. If it's 87, that's even better. You just need to think about where that fits in the continuum of is it practical? I have worked in a couple companies where we built as part of the deal thesis an incredibly detailed financial model. And we actually took the time to think about modeling out each product sub product additive value that we could see. And that drove a lot of that financial decision making. And at that point it was really driven by a financial perspective of can we actually make these numbers? And as we're going through the diligence process, we would test all our findings against that model. And there was always kind of a error bars within those models that you could get to. That's okay. This is now getting too risky. If we figure that there's a swing factor of x percent, then that's fine. But if that swing factor is getting really high, where we realize maybe we aren't going to get the same upsell opportunities that we thought, then that's something that you need to step back and either rethink the core thesis and the kind of targets that you set, or do you even do the deal at this point? Cause it may be that it's you're chasing after something that's just Gonna be really hard to get the return.

This is the million dollar question. How do you balance it out? Because when you are on the model it's easy to use your imagination and tinker with your variables there and to have a story. That's one approach. But then the other part is more around the discovery of your capabilities to execute on. Right. Like what can you actually tangibly do which is different. This is talking to people and really doing that level. How do you balance that out?

That's the age old problem. You're right. This is the tough question. You have to kind of look at it from a couple angles. Here is I'm always nervous about when I'm thinking about bringing on a new set of products or something that may be changing our back office systems. How much of that is internal back office system engineering optimism? Because I think engineers are biased that way and I think you have to kind of look at it from that perspective and that's great because that's they like to solve these tough problems and they like to do these things and that's awesome. So you have to figure out what is that factor. And I think that the big thing there is track previous history. If we if the engineering team and I mean just this classic engineering. If you've got an engineer who always says it's going to take five days and it really takes 15, you just know every time they tell you that it's a factor of three that you have to multiply it by and then that's probably realistic. When I used to be a program manager I usually asked engineering and I still think this holds true in this kind of state is I would ask engineering to provide me estimates. In a developer fantasy day that meant that you just got to code all day. You just got to work on the one problem and that's what you did. When you talk to people that are estimating that's how they're thinking about it. And then you think about layering in all the other work. There's existing work that you're doing, existing maintenance work and I think that gets to that other piece around bringing something in is you have to assess your own internal systems roadmap and where that's at. If you're platforming and changing your back office From Oracle to SaaS. Pause and think about that because you're going to drop an integration in on top of it. There's a lot of variables there that you need to make sure are actually going to happen. And do you start on Oracle and then move to SAS or Do you wait and move on to SaaS? What happens is the SaaS stuff is delayed. Those are the things you have to have these really heart to heart conversations around what do we think is realistic. And then I think it goes back to history. And then you have to add in a little bit of pragmatism of okay, we're making an assessment off of due diligence. That's happening in a short window. There's a whole bunch of other things that we don't understand yet. So you'd have to add some form of contingency. In the back of my mind is the X engineer. Whatever contingency I thought of that I would add in a non M and A integration world, I'll double it for M and A just because I think there's just stuff that comes out of the woodwork that you just can't predict. And it's just a high level guesstimate swag estimation process. But it's not hurt me so far.

All right, so you gotta be rigorous on both your financial modeling and your abilities to really validate and thinking all this stuff through the planning. Where do you start with planning?

Kind of comes back a little bit to modeling and thinking about okay, when do you think things are going to get done? The other thing that you have to think about is how long do you stay on interim processes. As we've talked about, you have to land on your internal systems and you have to kind of land with your sales organization at some point. But you do need to set some kind of general guidelines of is this something that we're willing to run in parallel for six months a year? Some companies I've known, they've been willing to wait multiple years for the kind of parallel processes to go because they just know that it's going to take so long to get into a core set of infrastructure. You kind of have to accept it. One company, I won't remain nameless, they had to move into a core set of operating processes so they could actually be fully booked and processed as part of the normal sales cycle. And that took three to four years. We knew that it took three to four years. As we tried it a few times, we realized that's how long it just takes. So then we would set that expectation up that this is how long it's going to take. So we need to be practical about what is that interim system going to look like and how does that process work. And always important is now you've figured out the back office processes, it's really important to step back. And this is again where your sales team comes into play. How's this going to work for the customer? We're going to present two sets of paper and they have to sign two different agreements. Is it two sets of billing? How do you make that really clear to them and how do you set that expectation? I think a lot of being on both sides of the transactions and cincom working in operations when acquisitions occurring. I'm willing to see a company, expect a company to take a year maybe to get things sewn together. And I think that's reasonable because there's a lot of work, even 18 months. But at some point, as a customer, I don't want to see that it's two companies. I don't want to do two companies. I want to do one company now. That's my benefit. So I think you have to think about how you get to that position really early. And that may mean that you have to do some things on the front end to present to the customer a single view, single point of view. But there's a whole lot of backend processes that you're doing that may be manual to create that better customer experience. You have to go back to the customer making sure that they see value in this transaction.

It's almost like we can break it down between front end and back end like we do in development. Right. We got stuff going on under the hood and stuff that's very visible that customers actually see. It's like thinking through go to market the same thing that there is a whole backend infrastructure that underpins all the operations. Then you got all the front end. What the customer sees and interacts with their experience.

Yeah. And there may be a whole. As one of my favorite engineers, just to refer to it as the kludge layer that keeps the front end looking nice and the back end system not working so well yet.

Can we talk through the planning steps between the two? I want to know. I don't know how it's done.

It's an iterative process. I think you have to go back and look at how much you think is going to take, really no nonsense to get into the systems. And then I think you have to go back and then look at our revenue goals, our customer goals, our sales targets. And there's always a little bit of engineering work that also has to go on to get into any product systems or back office systems. So what are those three things? And I think you circle back and forth on this to get to a plan that is really clearly understood. Because I'll play out one extreme here where it's okay, it may take back to that company that took multiple years to get into the four product infrastructure pieces. How do we manage the customer, how do we manage sales, how do we do joint products during that period of time and really be thoughtful about it. Day one, you want to have what I think is typically a swivel sales team where you basically both teams are heavily coordinating and you have what I affectionately refer to as three legged sales calls where you got both companies coming together, but they should be tied together at least with one leg. So they are kind of looking coordinated. How you go from that, which is really rough, to a more polished system as in an interim stage, and do that in a way that you're not creating new features or new products that eventually fully impact that back end system that may be burdened. You need to think that through and really be clear and plan that out and talk about what's the financial impacts to those decisions. It may be that you can't offer discounting across multiple products because both products have different kinds of discounting models at some point. So you can't harmonize that until further down the road. You have to be honest with yourself. And I think that's the challenge because nobody really wants to talk about the fact that back office systems and back end systems drive front end interactions. It's really important to have a really strong technical team who can talk to these pieces but also speak the truth. This is easy we can do and that's hard we could do. Going back to the key, I want to say revenue sponsor, which is the sales team. Okay, we're going to do this. It's going to be a little clunky. How's it work? Does that affect your sales? Does that mean that a certain percentage of our sales, our customer population is just doesn't want to mess with two contracts or just doesn't want to mess with two invoices. What is that? Help me understand what that impact is because that ultimately gets back to whether or not you're thinking about resetting your revenue targets practically early so that you don't have a surprise as you go into the integration. And then the sales team goes, well, of course they're not, you know, we've lost 20% of our sales opportunities because the customers don't want to be invoices. I'm just picking on invoices today. But it is kind of amazing sometimes how some companies just don't want to deal with that, which is fair.

You're not making this easier said than done.

It's not. I think that's the piece that I think everybody's oh, this is going to be straightforward and it's pretty intricate. Having a really detailed cross functional team that can step in and do the M and A work, who knows how things work is paramount and unfortunately those are the same people that are doing the replatforming work. It's a tough thing to build the case that you have to invest in your systems team so that you can go faster because it's not directly driven to revenue. It's oh, I can invest in engineering teams because that makes new product and that makes new widgets and then we can sell more of those. The thing that I have seen for those companies that I had touched on that do this really well is they really have invested in building that infrastructure so that it is multifaceted and can support different sales models fairly quickly. And that takes time and effort and it's kind of hard. You have to build the case with multiple deals. In some cases that this is something that worth investing.

Well, you're not talking about an imo, you're talking about something else.

I'm talking about core resources within the engineering team who then can help onboard and build those new APIs for the new companies that come in.

Also building the muscle within the engineering team to do integration which essentially speeds up your ability to integrate infrastructure so that you can really get to the ideal North Star experience or get the idea the closer to it faster.

I like using the API model because not all APIs work great, but the API does the job when you're doing some kinds of sales. You may say that we can support this type of sale very easily and oftentimes most of these companies are smaller and have more bespoke sales processes. That's where you have to be honest with them about. You can't just edit out a simple set of clauses in the contract. You actually have to make sure that you're keeping all those terms because they're systematic that are tied back to those terms. And that's always a tough thing to get across. To what I would say smaller company sales teams. This is that it was just so easy. We could just change the terms and it's. We can't change the terms because we're actually promising something on the back end as far as an audit or compliance standard. It gets to the crux of a little bit. Oftentimes with acquisitions, big companies, small company problems, big companies have a lot more standardization move a Little slower. Small companies, hey, we're fast, can make these deals. That gets to. Something I think is really important to talk about with the sales organization is change management. It is a huge piece that the selling motion may be changing. When you're a small company, you have to get out there and be scrappy and get your name out there and do a lot of cold calling. When you're a larger company, that's all easy now. You have to then figure out how to fit into the system to sell your product. In some ways, being honest with the salesforce that there's different ways of doing sales, you have to be prepared to make the shift, or if you don't want to make the shift, then maybe it's not the right place for you. I think that's a tough thing to have a conversation around, but I think it's really important to be honest with people that, yes, you have to go and have a lawyer review your contract. You can't just mark it up yourself. I'm picking on, picking extreme here. But there's processes. And when you go to have the lawyer review your contract, there's a process to go through that piece. You just can't run down the hall and sit in the lawyer's office and say, hey, can you mark this up?

Okay, I want to make sure I'm not losing anything here. I got three key areas. We're talking about one, sales readiness, which we're going to expand on the customer, and then the systems. Having the capability to integrate systems or thinking about your operations. The big takeaway that we covered was building the engineering muscle to integrate systems faster. That's one key thing. The sales readiness part, how do you bring that conversation up? What does that sound like?

Being really clear on how you view the new joint product and how you view that, what value that is the customer. Hopefully the inbound sales team doesn't say, wow, that's crazy. That doesn't fit. That's a warning sign there.

That's a dumb idea. I don't like it.

Yeah, exactly. Alarm bell should go off there.

Now, this ties back to what you said earlier was test with sales. So maybe give me a sense of is that happening in parallel. Where does that fit in? Give me some good examples.

When you think about packaging things up, I'll use an example of like, we wanted to sell 1, 2, and 3, and when we sat down and talked to the inbound sales team, they're like, oh, nobody buys three until six months later. So you should just focus on selling one and two. And then as a follow on have sell three because it's an upsell. That's the stuff that you just, you know when you're looking outside of the business and you're looking at the financials, oh, they sold 1, 2 and 3. But you didn't realize that it's a phased approach or that there's a follow on sales call or a follow on message. You can also have a conversation like, hey, when we're in these types of accounts, we see this kind of friction because they said you have this feature and it's like you have that feature, we want that part of you. And it's like, oh yeah. But when we sell those features to that company, they also want this feature and that feature and we don't have those yet. So making sure that you understand that when you add a new feature to your stack or your offering, there may be other hidden features that you have to add future because that's also what the customer wants. Because you're taking the product maybe in an adjacent direction. So you always tested the salesforce, always ask the question, how does this fit? How do you go about selling it? Asking those questions, it's really challenging to do when you're in overlapping areas. Neither company wants to share, this is my customers or this is my process. So you have to think very carefully about like how's the motion? That's the conversation to have. And when you say hey, we're going to change the motion to this, then that's a way to have that conversation without running a file with sharing customer information or customer price points or all those lovely things. Because you can't and shouldn't share them to your one company. You kind of have to work through some high level assumptions and then ask leading questions and then listen very carefully to both sales teams. Those people aren't shy. They'll tell you what they think they can do.

What questions you use.

If we're bundling these together, is that a fast sell or a slow sell? What other follow on materials you need to sell that product? Do you have to have a proof of concept? Is this a reference sale that you can say, oh, company down the street bought the same thing, I should just do the same thing? Asking what's next? When you do that first sales call, I think those are all good questions to ask and figure out. Do they buy solution one and then six months later they need to buy solution two and three? Then you just know that's a multiple step sales process. There's a lot of companies that in Some technologies that people will say, oh, we'll do a proof of concept. We'll set up a small team, we'll do a proof concept and we'll test it out. And so you get the proof of concept team there and then you have an internal sponsor in the organization and then you may have another conversation or an uphill challenge like how to become an industry standard. You have a group that goes off and I'm just something out, just that we're going to go use a different email client and they're like, hey, this is awesome and great. Now they have to go talk to the core IT team and say we're going to, we want to change the company standards because here's all these great things. Then you need to know how to sell into that organization and sell what the core IT team's concerns are. And what are those follow on questions that they are important to do. Looker was a great example where they did a lot of proof of concept work on data analytics and sources. People said, oh wow, this is great and helpful. Then as they started expanding, then the questions got deeper and broader. Looking at financial data, that was one set of issues. Now all of a sudden, if you're starting to handle customer data or PII data, then there's a whole set of security questions that they want to ask. And so you have to think about how that full sales motion goes across an organization, if that helps make sense.

Yeah. So you're generally understanding it. What are the things you can't talk about? I'm not supposed to talk about specific customers, but can I talk about industry or.

I think you can talk a little bit about industry. I think that's fine. So first off, always get advice from your competition council. Competition council. If you have counsel, it's on how do you make sure you're not running afoul sharing your competitive information?

So competition council, you guys have a dedicated resource just for that?

We do internally and then we also use outside resources because I think it's always important to get for particular domains and businesses. The concerns are different.

Okay. Especially when you're global 5 organization.

Yeah. It's just important to check with that and understand it. The rule of thumb that I always like to use when I'm thinking this through is if the deal fell through, would either company be at a disadvantage if that information had been shared? So you've shared something that the other company now knows about you, that puts you at a disadvantage. That's my key litmus that goes to.

Like, what's the Biggest industry you guys serve.

Yeah, I think that's part of it.

That would technically be something you shouldn't really ask.

Yeah. How do you do discount? Do you blanket discount 50% regularly? That's competitive information that's important to not share. What's your price point? There's published prices and then there's corporate prices and there's different tiered pricing. So don't share. I never want to see anything around pricing.

But we want to understand the sales motion. What does that look like, the general goals around that customer experience?

Yeah.

Thinking about that back on testing with sales, how do you do that? Do you start telling your vision an idea to the sales team and just get the response?

I definitely think you test internally with your sales team, the host company's sales team first. And then yeah, there is a point where you either the process the transactions completing or it's done shortly afterwards. And then you say, hey, these are all the things we think about now that we can talk about this in great detail. You tell me how this works. Which does make an interesting statement in that when you. There's always a desire to let's get out there and sell jointly together. Take an easy softball layup for that first sales cycle. That it's like a forehead slapping event. Everybody understands. Super simple. Don't get too complex because as you start to ask some of these questions now that you both can talk across the table and share all the information, there may be things that you thought were going to be easy that are not and you want to make sure that you're really focusing on what brings the best value to the customer the quickest. This is like in theory and then in practice.

Yeah, that can easily get lost.

And there's also just be conscious of inertia. Let's do this. We just thought we were going to do this. Let's decide it. And that's. Yeah. But if we're really not making a delightful experience for the customer and generating revenue, then we really need to step back and think about that, which is getting back to testing again with the sales organization jointly now at this point and saying does this make sense? How does it work? Because there may be tweaks to that.

Well, we can talk in detail about a go to market together with other sales team.

You can plan all you want, you just can't execute.

Then you got that jump in the gun factor which you can't do anything. You can't execute any of it until it's all closed.

Yeah, you can't. But you can plan you can say hey, on day one, we'd like to go out with an announcement saying that hey, with both of these products we'd like to sell them at the, at this price point or something along those lines. You, the acquirer can set that.

Okay. Key people that are involved with all.

This, the inbound team, their operations team, their sales operations team is the key people that you want to talk to very early on around the systems and processes because you need to understand how they're working and what works well and what doesn't work well and why they chose to automate some sections and why they chose not to automate some sections. That gives you some very interesting data friction points. How to make the best experience for the customer. That's a key group of people to talk to. On the other side they had a sales and how they think about the sales team and how the sales teams are going to work together. There's a big change management. Now you have two sales teams working together. You have to think about territory mapping and you have to think about who's going to work in each territory. There's no company I've ever seen where we've done an acquisition where the territory is exactly overlaid. Never happens. Now you have to think about how you tune somebody that may have been selling in just a small region now has a bigger region because it's a bigger company because that's the way the company is organized. How do you make sure that if you have somebody who's been selling a small region now you just put them in a big region. Do you need to look at the resourcing for that one person? Because now you may have a bigger footprint that person has to cover. Those are things that you have to think through and work out.

That's a lot of problem solving and thinking around the corner, my friend.

Yes. On the acquirer side you really need a group of dedicated go to market integration folks that are staying constant with all the back office system pieces. But thinking around the corner, thinking those next two, three steps out around the corner as you even start the thesis so that they can, you can be ahead of the salesforce. When you get behind the salesforce then that's super, super challenging because the salesforce is we want to sell things, we want to do all these things and you can't, you're not allowing us to do it. And that just from an integration standpoint it's not a good balance.

There's different scenarios you could run into with generally integrating with go to market and I'm thinking underpinning it would be the distance from the core of your business.

Yes.

Where completely different product. Are they serving? Same customer. Different customer. All those factors. Do you have certain buckets that you think of that as where it's boom, this is a light thing. We're just similar solution customer. And I don't know, maybe you're sunsetting a product which Google has done before. I'm very upset about Songs. I used to love that app.

And anyways, I'll come back to sunsetting because I think that's an important thing to talk about. I definitely think you have to think about how close it is to your core and the further it is away from your core. The general integration thinking is that should be more of an a phased incubation integration so you may leave them more standalone for a lot longer because they're further away so you really understand their business before you bring them in. If it's really adjacent and it's you're just selling a widget with a different color, then yeah, bring them together immediately. That that makes sense. But if it's further out, yeah, definitely think about a phased integration. I think it's always important to be clear with the inbound company that ultimately integration is going to happen because if you say, oh, we're going to leave you alone, you'll just get funding, you can do all your other things. Then when you start to do the integration, they're like, wait, we didn't agree to this. I think you have to be clear that eventually you're getting folded in and we're working as one big team. But that may be a while. And I think that's important to set that. And I think it's important to set an understanding level of the other company's business, but also a time level so that there's both sides here that, hey, we're thinking that we're going to phase you in a year, but we need to understand these three things or these four things. I think that's really important to be open and very transparent about it because you may not understand all four things in a year, but at least you can then say, okay, we're going to move it six more months or hey, and you know, one year. We've understood all four things. Now we're ready to start this process. Let's get moving to it. I think the thing that I will say that's really important, I think people don't spend time thinking about it until after you've gone through it a few times is how you're clear around announcing an end of life product, you're phasing something out, you're taking something that was a maybe standalone product and then you're going to fold it completely, wrap it into your product and the standalone is going to disappear at some point. I think you have to be really clear with setting some clear end of life policies and the notifications and you look at some of these very large companies, they say we're not going to announce an end of life. Well now it's something that's going to be end of life but it's going to be maintained for 2, 3, 4, 5 years if it's hardware. And you have to be clear about that and you have to be very consistent so that as a company that's come in and has bought that product and you're eventually phasing it out and maybe for the company it's not the best decision to go onto your joint solution. You're giving them a very clear transition path and I think that's really important. Just have that set define and also resource it because I think that's it happens and I think it's important to do but I think it's really important to be very consistent otherwise they'll be hesitant to buy the joint solution if they know that the, maybe the joint solution goes away in two days or something like that.

Yeah, they're going to be like what.

They do do that once or twice and then people are like wait a minute. And that affects your sales cycle, it affects your ability to sell and that's an important thing. If you're in a consumer based product, I think the cycle's shorter. You're in an enterprise or an infrastructure product, the cycle is much longer. And you think really carefully about.

I was, I was just thinking about that. I think you guys only gave me six months on, on my apps. Very consumer one. But yeah, and then enterprise, you get that bumped out probably two, three years.

Yeah. Back to looking around the corner, thinking about things, planning in advance. Those are all things that when you're not doing deals you should really be working on setting those policies because that just helps you when it comes to deal. And you're setting it, hey, you know, we're going to keep everything in place for a year or two years or three years. That drives a lot of decisions. It even drives some direct communications with the customer which I think are really critical. Like hey, we just announced the deal, we just merged together and oh by the way, go ahead and spend that money because we're not going to take it all away from you particularly in enterprise stuff for a couple of years safe because there's always that kind of pullback of wait a minute I'm not sure I knew company X I don't know company. Yeah I think that's really something to have a very clear set of principles and that's something you have to work to set up early. The earlier the better.

Okay so the gist of what I'm getting is if further away from the core just inherently bigger scope and complexities what it's going to take to make go to market integration work. That's where you put more consideration in having a phased approach and then on that side sunsetting a product unique situation. Have you done that where you sunset a product and then you brought over the sales team or is it typically.

I'll go back to a lot of my M and A has been more in enterprise software and so you do keep the sales team and you keep the support organization particularly as your son sending the product because you're going to need to keep those customers well managed. In some cases I've actually had sales teams help that customer transition from the pre close product to another option. I think that's something you have to think through a little bit. In those cases it's more sales engineering or customer service kind of roles. Good salespeople are always hard to find. If you've got a company that had a great salesforce I don't know a company that is not actively recruiting for sales team members bring them on and give them a chance because I think yeah you just you're. I'm always amazed at how some people come in and it's oh this is the right place for me and take off. So I think that's really important to keep in mind.

What about the marketing function? Where does that fit in? How should you think about that?

Marketing is really interesting because they actually think in my mind marketing ties to branding when you're changing the brand or you're thinking about migrating the brand that actually is the first step in kind of the marketing back to the customer base that you know now it's product X plus Y or brought to you by platform Z I think those are really important to signal the direction. The other thing that's really important to digest is that usually the acquiring company has more of a brand reputation and usually it gives the inbound team a lift from a kind of perspective and kind of presence. I think you should think about that who can lift who where I think is Always the question I would ask because usually the host company has the bigger footprint, but the smaller company may actually have a better inroads to specific market segment or group of people. And so you may need to think about, oh, they've got the ear of this population now we need to think about how we lift the host company's product into that population. Having those really clear conversations around like what's the center of the population and customer that you're marketing to, I think is really important. It's important to. We'll look to merging those two functions sooner than later. And the reason is that ultimately you do want to send the kind of or set that early tone of that there'll be one product at some point and that's the best way to start. That is in the marketing efforts. But I think it's something to think through very carefully. I definitely take a. There are cases when you want to do revolutionary market rebranding marketing. I think there's some cases where it's. I'd love to be have this large company's moniker on part as part of my logo that'll that gives me instant street cred and instant accessibility to customers. But there's often a lot of cases where it's not. It needs to be migratory and you need to think about this as a conversion period of time and you're letting signaling to the customer and even to the market that you're making this change. And sometimes marketing can be also a leading indicator that if there's a lot of pushback or snark or like disbelief that you can do two things together. I'll pick on an example of John Deere and doing AI work totally out of my field. But the fact that John Deere did merge AI into their tractors and they started showing how they were using the components in their tractors to allow tractor to run semi autonomous, pretty amazing. But as they were introducing AI to tractor people, it's like AI stuff. This is weird. And the AI organizations and companies were skeptical that a company like John Deere could actually pull this off. So I think you have to use marketing as a way to test that customer sentiment.

There's so much more we can talk about. James, I don't know if I can get somebody to sneak more time on your calendar.

Yeah, we should find more.

So we'll see. We'll hold that. Otherwise, for now, I got to ask, what's the craziest thing you've seen in M and A?

Oh, the craziest thing I've seen in M And a. The craziest thing, I would have to say CEO who had gone all the way down the process of getting ready to prepare to sell their company, that was kind of like, they put a lot of personal effort into it, and we needed clarification around legal matter. And they clearly used that legal matter as the excuse to kill the deal. They basically said, oh, we did all these horrible things. And that just killed the deal immediately. Because there was just no way we could just do it because they put it in writing. It was kind of the craziest thing. It was just. To me, it was like, how do you kill a deal in one email? And that had to be it, where it was like, you do this. You do not do this. How do you manage this customer data? He's, oh, yeah, we do all these horrible things.

That's literally what they said was, hey, this legal mess. You want to clarify? Yeah, we do a bunch of things. Deals off.

Yeah, they basically said, we do all these things. And they knew immediately that we would just have to walk at that point because it was just like, oh, they.

Knew that you wouldn't be able to go through the deal because of that.

Yeah. It's probably the craziest thing I saw was just, you know, and this is days before signing. That had to be, like, the most unusual exit I've ever seen.

Yeah, it would have been ideal to just bring that up from the very beginning, at least, like, second or third meeting in.

Yeah, we've been working through it, the whole process, But I think that my hypothesis is that the CEO got cold feet because we never, ever heard from him again. The point that kind of makes me scratch my head is that there's some documentation that they probably really shouldn't have out there as far as something that could be misviewed by a regulator that just. Yeah, I just would have. It would have just been easier to say. I just don't think this is a good deal to do. I think they could have done that.

Wow.

Yeah.

That was crazy.

Legal, kind of. I wouldn't say breach technicality. Using that as an excuse to kill the deal.

Yeah. Interesting. James, Joy speaking with you. Thanks so much for coming back. I don't know. There's a whole other half of this interview. There literally is.

I wrote up a bunch of notes here, and we definitely need to do some more here.

We can. Sweet. That'll be fun. All right, Part two.

Good seeing you.

Thanks, James. We'll talk again.

Foreign.

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.