Making M&A GTM Successful

Hello M and A Friends. This podcast is brought to you by dealview. M&A is coming back. Would you like to avoid wasting hundreds of hours managing Excel Trackers and building PowerPoint reports? Do you want to make your process more efficient? Well, I have great news for you. Deal Room is MNA management software to save you time, headaches and improves collaboration so you realize value faster. Learn more@dealroom.net here's to the deal.

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 MA Deals.

Foreign welcome to M and A Science Live, 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 Masscience.com and subscribe to our free newsletter. Every Monday we share highlights from our interviews and publications so you can continuously improve your MA skills. Again, that's mascience.com I'm your host Kisam Patel, CEO and founder of M&A Science. Joining me today is Gwen Pope, Head of Global Product M and A Strategic Partnerships at ebay. Gwen has 20 years of experience in enterprise software arena with a past 12 focused on M and A cloud technologies. Today we're going to talk about how to plan go to market for successful integration outcomes. How are you doing today Gwen?

Wonderful. Happy to be here. No, scratch that. Thrilled to be here. Honestly, there's nothing more valuable than talking with friends and colleagues about okay now what did that mean? What worked, what didn't, what was awesome, what was not, what represents an opportunity to maybe stick a pin in something for use later and iterate on it. I'm a absolute sucker for problem solving and of course M and A is chock full of complex problems. Super happy to be here.

We have that in common. Could you kick us off with just a brief on your background and your M and A experience?

As you mentioned, at the moment I'm heading up MM M&A and Strategic Partnerships for the Global Product Organization at ebay. I should probably mention a quick aside, I'm not talking today representing ebay or any of my past employers, but of course here to share more generically based on that experience and others. Prior to ebay, I have focused on M and A specifically for about 15 years plus and that stretched back through Google Cloud. Most recently I probably worked with some of your audience members or crossed their paths while I was at Google. If not, then try Deloitte for a couple of years on an M and A advisory team working with clients such as hp. Prior to that was with Microsoft for a number of years working also in M and A, but on another side of the cross functional table, so to speak. Before that my roles were they were going through a pivot, a transition. It's probably safe to say that most of us that end up in an M and A oriented career have arrived here through sort of a serpentine path, at least in my humble opinion. Most folks that succeed in M and A do so because they can look through multiple lenses, switch hats and think, okay, what does this mean from the product and engineering perspective? What does this mean through a business lens? How about commercial operations? How about contracting? Illegal, et cetera? So to have that multifaceted experience has been really both fulfilling and super valuable in approaching my current role. But if you stretch back more than 15 years or so, you would find me in increasingly technical roles. I spent some time at Apple focused on service oriented architecture, setting up a global center of excellence around that project. Prior to that was with Oracle for a number of years and that was focused on originally pre sales and consulting around solution architecture for SOA focused on middleware, application integration, et cetera. That was during the time of the BEA middleware acquisition and really represented the first point where I started to nudge towards the pivot for M and A work. So in the interest of time, I won't go back even more years than that.

I'm seeing a theme. You have a diversified operational experience that sort of lend to this comprehensive understanding of how these pieces through an organization come together and work together.

Exactly. Yep. And I was going to say that if you look back even farther than that, you would find me with hands on coding as part of my role. Nobody should test my technical skills specific to certain technologies necessarily. But I'm not that rusty.

Some of the best in M and A have engineering backgrounds. So, you ready to talk about go to market?

Yes, let's do it.

What's the difference between building a go to market plan for a new product and a go to market plan for integration?

So first I will play devil's advocate and say the Delta is not as wide as you might think. And really the goal is to, within the context of your own organization to understand each piece, how you as a company launch new products normally and then what makes sense for bringing in something that's acquired which just by the nature of it will entail some non standard elements, maybe infrastructure pieces or operating criteria, billing models, legal Terms, et cetera. There's many things that might be not what your company normally does, or maybe even things that you find need immediate remediation for compliance or other reasons. And so in many ways you're going to have to take that and then eventually end up closer to or maybe fully remediated so that you can then bring it to market and operate it in market as you normally would. That's my first call out is really think of it as it shouldn't be that far apart. But with that said, the planning for integrating an acquired product, the key difference is that you have to build that bridge. You have to envision, okay, here's the starting point. And of course you gather insights through diligence. You understand as much as you can pre close about how does this represent something that not only holds value for ultimately, but that to get that value, whether it's driving adoption within a certain customer segment or establishing your company as a thought leader, presence in a new space, et cetera, that you're going to have to get it to the endpoint to do the value capture. And what I mean by endpoint is as much as possible, business as usual, standards based, go to market. So that's the key difference. And I would say that to do that really requires a solid understanding of not only how you normally would bring something to market, but and what your go to market readiness and go to market launch process is, but also between the lines, what exceptions, what variances, what interim processes and policies will you probably be able to get approved and put in place? And that forms the middle of your bridge.

As you're talking about this, I keep thinking about building a new house versus buying a fixer upper.

That's an awesome observation. That's exactly it too. You're going to have to work with some stuff that maybe you, you don't love and that ultimately you could remodel that or maybe think, wait a minute, that's a legacy fixture that I love. It's this antique chandelier, what have you. That's an arch doorway that I might not have planned from the get go, but I want to bring that forward. And so in many respects there's technology, there's people, there's culture, there's elements where you might decide you're going to keep that. In some cases you might even think, I want to take that and infuse something new within the acquiring organization. So that's a great point.

Let's talk more about the challenges. What are some of the common obstacles for bringing an acquired Product to the market.

People that work with me know that I'm prone to stating the obvious to set the table for topics like this. Communication is key. Understanding the air traffic control job that you have as a deal lead or whatever your role is within M and A in your organization, chances are that part of your charter is to play air traffic control for the information that flows through your scope and that intersects other people's scope. So understanding from the get go, who needs to know what? Who's going to be responsible for really cycling through the inevitable cycle of decisions early on? It's really key to set the table with a minimum viable meaning, not over processed, not overanalyzed, and certainly don't have access to all of the inputs and insights that you want and that you will eventually have access to within post loi diligence, but that you form a minimum viable rationale. It's really just a thesis and you're saying, okay, from a product engineering and go to market slash leadership perspective, you sit down and you think, okay, what is the thesis here? Why would we do this? What does that value look like that we're after? If you don't do that early on and then iterate, for instance, if you wait until post loi diligence, or in my humble opinion, even worse, wait until after close to really fully understand why do this and what are we after in this and how do we capture that value, then you're really missing a key guardrail and I would argue a keyguard rail even in diligence. Because diligence is about, it's in the term confirmatory diligence. It's about confirming or adjusting your original thesis. That's the soapbox there that I'll start with. You've got to understand from the get go, at least a working minimum viable model of why. I would say another good soapbox topic is back to the bridge analogy. You need to understand where the gaps, the capability gaps, issues, and honestly, skeletons in the closet are right. Know where the bodies are buried. As far as your internal operations, from a go to market perspective, if you consider how you normally bring things to market, again, back to the bridge metaphor. If in that endpoint you know that there are serious challenges around certain aspects of maybe the fact that your company is going through a major shift in how you think about commercial operations, or maybe you're doing a big contracting strategy shift to move towards a more unified consolidated contracting model, which is fantastic, but in the midst of that, or maybe it's in the midst of a migration in Billing and payment systems lead to cash system, something like that. You need to know that's going to create some X factors and possibly some challenges for your integration path. So again, know where those bodies are buried. Understand the challenges for that endpoint. Because knowing the starting point, which is your rationale and how you think you're going to execute is only as good as knowing the endpoint.

I got a few questions on that. On the beginning planning part, you made a good point around it. I wanted to get an idea of when you should start thinking about it because you gave a good idea of what happens when you don't start early enough. But what's the best practice? I've heard extremes of this from. I think my favorite is Carlo Sesta, where after 20 years and doing retrospectives with CEOs six months post doing the deal, the number one lesson he learned was none of them were prepared for integration. So he brings his integration lead all the way to the front end of the process and has them develop an outline of a go to market before loi and says that hey, let's get aligned. So you at least start thinking about how you're going to be involved and what this is going to look like, making this happen. And then as they go through diligence, they create a work stream for integration planning and iteratively do it. What do you think? How have you seen it played out versus how you would have liked it to play it out?

I would completely condone that thinking, but I should quickly follow up and qualify. When we say start that integration planning and specifically right now we're talking about the go to market integration. But starting integration planning and understanding what that strategy is early on doesn't mean obviously a full blown integration plan. Not only is it impossible because you don't have all the inputs to flesh out a robust integration plan, nor is it feasible or even advisable to have a large enough tent and take up cross functional resources and bandwidth and internally to really operationalize your go to market strategy or go to market integration strategy. So what we're talking about is early on, as part of the rationale definition, you should be able to envision the execution path to capture the value that you're indicating within the rationale. So if you say this deal makes sense associated with this specific target because we're going to both drive adoption and grow revenue. And here's of course the underlying couple of assumptions around that means direct revenue, it means synergies, it means uplift to these existing product products, et cetera. But the Go to market integration plan. The strategy for that is essentially the vehicle to the value capture. So if you're not at least putting together a T shirt size idea of this is the execution path to that value, then that's coming up with the plans for the house that you pointed to earlier on without any idea how that might get built. Are you going to build it out of bricks? Is it going to be a tree house? If you don't have an execution path and have some sense that it's viable, we can do that. Not only from a cost and time perspective, which by the way, you need to then sanity check against. Well, does that then capture value within the timeframe? That makes the deal worth it. But you also need to understand, are we as an organization capable? Do we have the capabilities to do that? And sometimes the answer is not quite. Maybe you don't have the domain expertise to execute in a certain space or build a certain capability. Maybe you don't have everything you need. Again, just from an internal systems and policies perspective, to bring a certain offering to market. I would say start early but then plan to iterate and build out and eventually operationalize before close. That go to market strategy.

I like the word envision. Execution path. I'm going to teach that to my kids when I get home. That's the right way to look at it. I'm still stuck on when do you start doing that activity. Can we make up an example? I'm buying your company, I want to acquire your business. I got a general financial model and I put a price in front. But even before that, I'm giving you a glimpse of the idea of what we're trying to do and is there a rationale for buying it at a high level? But now we're getting to the point where, okay, how are we actually going to do this? Because there's things that really need to happen for this to work. And so I'm after loi. Right?

No, I would completely push back on that. Let's step back even further. Now, obviously there are different scenarios for how you get to the point that you just described. Sometimes there are opportunities that just emerge and you have to act fast and it's time sensitive. Maybe there's competitive bids, et cetera. You don't have a lot of time to jump in and quickly assess. Does this make sense? Okay, let's start talking about an loi. Let's go. Yeah, that's one very specific edge case that I'm going to set aside for the moment. But generally speaking, I would say there's inbound inquiries, right? Bankers, companies reaching out directly to a potential acquirer and saying, hey, here's this opportunity. Is this something that merits a conversation? There's that and then there's also the constant brewing pot of ideas, some of them good, some of them not good, around, hey, we're trying to solve a certain problem. And there's a varying degree of maturity around this thinking. Usually, sometimes it's directly mapped to a roadmap gap. And we say, hey, we know that we needed to fill this. Let's get going and start thinking about, not specific to a target yet, a potential target, but how do we solve this problem? So that's obviously very early stage. And so when you start thinking about how do we solve this problem and it's about Capability X, or it's about how do we drive adoption in this space, then it's at that point that you start thinking, okay, here's the rationale. We want to drive adoption, we want to grow revenue, enter the space, et cetera. And here's how we would execute at a very high level. It's this multifaceted package before you're talking to anybody. That's right. Ideally that doesn't always happen, but that's the ideal. Now, at a point where invariably and also internally, as the starting point, someone says, hey, you know that problem that we've been knocking around and thought that we needed to solve with some emergency, here's an idea, how about Company X? And then maybe it's compelling and it starts getting some momentum and traction amongst leadership. And they think, yes, let's put together a business case, let's put together a brief that says, here's what we want to do, let's run it up the flagpole with some urgency, let's get going. So that's target specific, but there too, you need to have that business case, even if it's just two pages. Here's why we would do it, here's how we would capture the value. The how should include what is the offering that you think you're bringing to market? Is it a standalone thing? Is it a add on an upsell to something that you have existing? Is there a services piece? Is there a premium support offering? So think of it from a, from a holistic offering perspective. How would we sell it? Is it something we charge for? Is the services piece really the hook, but then the licensing is where we make more of a margin, or is it the reverse? So really understanding what is that that you think you're bringing to market and how are you moving the needle based on the monetization approach? That's the piece that I'm really pushing everyone to think about about how can that be at least drafted at a high level, envisioned at a high level really early on. Again, aside from that urgent specific track that you mentioned in the beginning.

No, this is better. This is way better. Because you have rationale. I understand that. And there's a whole talk track around making sure you get the clear strategy and you know what you're going after. But defining the execution path that early as part of it and saying, all right, let's, you know, shape this in mind a little bit. Let's take our vision but walk through a bit of a journey to get there. Yes, I like that.

Be provocative. It's not always possible. And we've all found ourselves in the position of rolling with the punches, especially for a top down acquisition initiative. I've even been plugged into a initiative that was literally two weeks from close. Hey, guess what? We're doing this. Most of us have had to work with that. And you just do it. And you find yourself putting together a capture of the rationale, usually going back to the top line executive that started the thing in the first place and saying, okay, look, I need half an hour. We're going to sit down and I'm going to capture your pearls of wisdom because we need to capture the rationale to help us plan, et cetera.

We're buying this. Nope, I don't care.

And that does happen, obviously. Yep.

Yeah. Okay. So we got through this front end. There's a variable too from there where you think about it and then you have at least something to build off of as you identify a specific target. I'm curious how early you would possibly get involved to try to shape that with the target company. Because I feel like that's a whole other thing is now we got this off the rack sort of thing, something to start with, but then really tailoring it the deal that we're working on.

Something that one should always keep in mind as you start step into kicking off confirmatory diligence. So as of LOI is based on the deal type, are we carving out an asset from a larger organization? Is this essentially an aqua hire? Are we going after this looking at a complex multi product line operating model where we're going to take most or all of that product line and then transition it to products that we directly have in market or integrated with existing products, et cetera. That's going to guide then the necessary approach to how you engage the target leadership in crafting the preliminary integration plan. And obviously there needs to be some necessary partitioning. Particularly when it's a deal that's subject to regulatory review. You need to be very careful about partitioning how you discuss, for instance, pricing strategy or what you're going to do with transitioning customers or partners into a go forward state. But that aside, generally speaking, if you consider the type of deal and then also the go to market scenario, what I mean by that is when you consider the go to market integration strategy that should have ideally been considered and at least high level envisioned very early on, you could be looking at a situation where it's going to be a new standalone product. It's going to be a new feature that's tucked into and integrated very tightly into an existing product you have, or maybe a new one that you already have in motion and are intending to release. But it needs that special sauce of that feature that you're acquiring. Or maybe it's an acqui hire. You're looking at really key talent with deep technology expertise or some other domain expertise that you want so that they can help you build whatever it is you're intending to bring to market that's going to guide how you think about engaging that target leadership to set expectations. Because part of it is planning and getting their input and obviously their invaluable expertise and perspective in thinking about the eventual post close go to market strategy. But it's also about setting expectations. You need to think about where might you need to diplomatically be prescriptive so that they understand. Well, given the parameters of the deal and given the really the baseline objectives here we're looking at collective success. You want to engage them and demonstrate that you care very much but about how you're bringing things forward. But the sensitive part is, the delicate part is often around scenarios where you intend to sunset something. If you're deprecating and then eventually winding down a product, that post close becomes a legacy product, then that's something that is really best executed. If there's a way to start setting those expectations and sharing awareness and collaboratively drafting that integration plan with the target leadership so that once you get to the point of day one and post day one, kickoff of Rubber meets the road, Here we go into integration execution, then you don't end up spinning your gears and wasting time on debate and pivot and stall around. Do we really need to do this? Are we really sunsetting this? Do we really need to stop charging for this? Because the larger acquiring company it's more trouble than it's worth or more cost than it's worth to charge for it, et cetera. These are all considerations that are best orchestrated if you start to plan jointly within diligence.

Collaborative success, yes, that should be your play. Collaborative success actually worked together with the target company. Every time you give these examples, I keep getting in the back of my head that this is another reason why auctions are dangerous. Auctions are dangerous because you don't have time for any of this. Especially now in this market. You don't literally have time at all. Yes, along the way you're building a case of why you should have proprietary deal flow a lot more than your inbound stuff.

Yeah, that's not to not inbound channel. There's certainly opportunities there that can be unexpected gems and that's another reason why it's really another indicator that highlights the value of at least to a rough draft expense. Having your own house in order with a capture of the thinking around what are our priorities right now, around roadmap gaps, around execution gaps, where it might make sense or maybe even explicitly make sense to pull that inorganic lever. Because one thing that I'll just circle back to the very top level early stage thinking to highlight is that buy is just one strategic lever, obviously. And one of the things that you need to be prepared to walk your leadership walk your potential prospective deal sponsors through early on is how does this make sense as a path overall? Does it make sense to buy and does it make sense to build instead or to partner instead? Or maybe it's a combination and often is a combination. If it's a more complex, broad scoped initiative, let's say that you want to enter a certain space that you're not in. And to do that you're going to build some baseline components, some fundamental pieces of that capability. But you really don't have the domain expertise internally to build all of it, nor do you have representation as a thought leader, as a operating player in that space. So then you have to go think about do we acquire certain players that have a brand name, that are well known in the space, that are thought leaders and also have the domain expertise to help build and operate that sort of technology or offering? And then you also think and does it make sense to partner either instead or pieces of that? That's part of the value of the early on early stage validation of what are we trying to solve and how might we do it. Part of what this takes you down is once you get to the point of kicking off Confirmatory diligence, even if you are on a fast track and you were rushed to that point because to your early example, okay, we're doing this right because of an inbound opportunity that was time sensitive or top down initiative, then you have that cheat sheet of priorities. And how does this line up with and make sense with what's already in our roadmap? Because that's so crucial to understand how that makes sense. How would this acquisition or any other make sense against the backdrop of what we're building and what we intend to build next year? What's on the horizon and where do we really need to buy or acquire to meet these needs in parallel? I think that's a really key piece. And then that of course takes you into, okay, then what is in your go to market integration plan? What is the scope of it? And I know we were going to get to that at some point, but.

I liked where you're going with it. The moral is you can't be lazy in this market. You need to do a lot of work upfront, build out these templates so that way you're prepared even if you're in a high pressure sort of type of sale. Probably could say it's better to be in the latter side. So be proactive on your deal sourcing as well. But let's get into how do we build this plan out. What are the factors you should consider when building your go to market integration plan?

Yeah, and here I want to be sensitive to the fact that most organizations, I would argue, don't have a whole lot of dedicated M and A focused resources. Most organizations are in some middle ground of you have a few folks or a few teams that are dedicated to M and A work and then you have a bunch of what many of us refer to as the volunteer fire department, where you have folks that have worked on deals, have contributed to deals, you wrote them in to advise on some aspect of integration planning. Or maybe you needed a subject matter expert around sales models or how do we operationalize for products that we launch in house. Again, back to the importance of understanding how do you bring things to market. But I would say it's really key to take the time to get inputs, gather guidance from folks internally that do have that knowledge who aren't necessarily M and A specific and in fact usually aren't. They're focused on sales ops, they're focused on commercial legal, hr, et cetera. And to understand, here's the common pieces that typically tie into an acquisition within your company, I usually refer to this as baseline deliverables. Know the common denominator, know what you probably need to plan around. Again, whether it's giving a heads up to the commercial legal team and saying, okay, here we are at a certain point within confirmatory diligence, we have this outsourced team that's doing the contract scrub of stuff that's in the data room from the target company. But here this comes and if we close that there's this going to be this new product at least for some period of time, right, Depending on the integration path. And we're going to need to invariably sell and operate it with maybe some non standard terms. What does that mean? Who's going to sell it, how do we contract? These are all things that are just rough examples of common denominator baseline deliverables. If it's something around a acquisition or an acquired customer transition plan, that's a usual suspect. An acquired partner transition plan usually have something around contracting transition plan, you'll have something around sales activation enablement, who's going to sell it? You need to start to enable your internal sales teams, usually at some point, assuming that you're bringing that product forward. So all of these sort of work stream specific function specific plans are sort of a double click below the layer of your overall go to market integration strategy, your sort of guardrail assumptions. We're going to do X with product Y, we're going to sell it to this customer segment in this way, charge this way, et cetera. Those are the guardrails. But then the double click below that is usually the assortment of work stream and function specific integration plans. And that's where you see the baseline deliverables. And so what I'm suggesting is to as you of course in parallel support pipeline and in flight projects, the trick is to start to build that capture of baseline deliverables because then that will let you literally build a spreadsheet of checklist. Okay, at this phase we know that we need to do this with commercial legal, we need to do this and start to work with sales ops, do this and start to work with the support organization, etc. So I would think of it as building blocks on a per function basis and understand what usually is going to need to be in those building blocks. And then as you have the time and as you learn over the course of deals that get executed, you start to pick out patterns of the edge cases, the variables. What if we do this sort of deal, how do we need to transition? How do we need to. For instance, if something is billed on A consumption basis and we're going to transition that into a product that is billed on a subscription basis. That's just a random example. But the point being that there's some interesting and not common denominator deliverables, but some interesting variables that will prop up here and there that are good to pin. But again, the baseline deliverables you need to understand first.

Got it. Then what I'm curious about the whole part of you're learning this and you're creating the capture around this so that again you got this adaptive plan for the company that you're specifically acquiring, but then going to shift over to actually execute on all of that is a whole other thing.

If you take yourself back to the kickoff of confirmatory diligence, usually whether they're dedicated resources or not, you end up with this SWAT team of cross functional delegates, right? Someone who's representing the priorities and interests and planning considerations for support, sales, legal, finance, et cetera. And those folks are going to be on the hook for providing you really the T shirt size estimates for. Here's what we think this would take in terms of time, here's what we think about anything that is a particular or potential notable risk issue. Here's an X factor and they'll start to populate that high level spreadsheet for you, the integration tracker that's built around those per function assumptions. And at that point we're really talking about five or six line items mapped per function. What are the really high level pieces that you need to see defined and fall into place to be able to execute? To put it another way, figure out what the critical path is for each of those functions to be able to get to that integrated state, whatever that end state is that you're aiming for. And again, that depends on the deal scenario and the go to market strategy.

Agree. Let's say common deal is pretty sizable. When would they actually do that? How does the activity come in play with the diligence work they have to do and not screw up?

It's obviously a tricky balance, but I typically like to. This may sound counterintuitive. Hopefully I can explain the logic, but I like to kick off internal working sessions on building out the integration roadmap assumptions. Again, you should have some very nutshell idea of what those guardrail assumptions are at the outset. But building that out, starting to flesh out through debate and validation and testing the assumptions and figuring out what key inputs you need to be able to build out further, start doing that one to two weeks in confirmatory diligence so you fire up a series of working sessions and I'm usually very careful to qualify it as such to help people think more fluidly, to help them not get wrapped around the axle of hey, we're in diligence, why are we doing integration planning? And then as you start to build that out, you get to a point, usually about halfway through confirmatory diligence, where you have a meaningful enough model of what you think the go to market integration plan looks like. At this point it's not exactly operationalized, but you have this meaningful model where you think you have enough substance to then run it up to the senior leadership. It represents the deal sponsor, cross functional deal sponsor team, run it up to them, get buy in, make sure there's alignment on that, and then start to kick off the joint discussions. So you have then again heavily dependent on what the scenario is, how prescriptive you need to be with setting direction for what that integration path is. But start having the joint discussions with the target leadership and depending on the size of the company, sometimes it's the whole team. But start talking about here's the set of foundational assumptions that we developed internally, here's our directional thinking, and now we want to open it up to get inputs and get your help validating the viability of certain pieces that we have defined as either needed, maybe it's a compliance oriented thing, or you need to be able to bring a product up to certain remediation criteria, et cetera. And also maybe you have options, maybe you have scenarios around how are we going to get more lift out of that services model or how are we going to improve the margin around this specific product within your portfolio? Because chances are they're going to have some really valuable insight and probably know better than you about a lot of those pieces. So kicking off the joint discussions and then ending up at a point where you are ideally before sign of the definitive agreement, but you get to a point shortly before close where then you have a relatively baked integration plan. Footnote, there's always course adjustments when you're.

Working with the target side, you're working with somebody in like a functional lead. Are you just working with that person directly or do you have your functions on your side also part of it?

It depends on the scale of the organization.

Okay.

It also depends a bit on there might be factors around regulatory review of the mix. There might be factors that indicate the need to keep the tent small. Maybe the target company is a public organization and you can't bring everybody that you want into the fold. Then you just need to work with deal sponsors on both sides to then selectively cherry pick subject matter experts. And often in that case you need to be able to turn around and deal discreetly and generically go hunt for insights. I myself have had to do that many times where I needed to keep separate our go to market, organization and operations that are part of the business as usual world and an M and a project where maybe we needed to know, okay, what's the overlap between the target company's customer list and our customer list? That's a very recurring task, especially when you're looking at with a larger company, they might have some really top tier customers that you already have. And you need to consider the transition very carefully. You need to consider maybe just before close, giving a quick courtesy heads up to the enterprise sales reps or account managers that are handling those customers, that sort of thing. So my point being back to your question. You're going to have some constraints around who you can bring in.

Yep.

But the idea is to understand why you're bringing them in and then how does that feed into either building the integration plan or maybe some of the people plugged in are specifically for the purpose of approving it or gaining that alignment that's so critical before flows, that table setting for expectations that you'll need.

We have so much in our outline we haven't covered. We have how to get people aligned around goals and strategies in that part. And then we didn't talk about pressure testing the rationale.

I think we've woven through sort of a intersecting thread through a lot of these things, even though we didn't explicitly kick off with a leading question. So for instance, if you take how do you get people aligned around the goals and strategies? So back to the PSA about clear communication. Think about who's going to need to know what portion of the information around the plan, the strategy, who inputs into it, who makes the decisions on it. You build trust, target company, particularly the leadership. But then I would say that internal stakeholder alignment that we touched on before, ideally starting way back in the early stage discussions of why would we do this, what might we do, what target companies make sense, et cetera, that then also gives you a beacon with which to then go down a path and not only facilitate internal roadmap sessions around building out the integration plan, the integration assumptions, but then also to start facilitating the joint integration roadmap. That's just one example of how I think that we've gracefully sidestepped around a lot of these topics and Dipped our toes into it.

How about we touch on the pressure testing rationale?

That's a great one. I've long ago learned that you're never going to get all the time that you want, nor the focused attention, the dedicated attention that you want from the internal leadership that represents your deal sponsors or prospective deal sponsors. You need to again, in parallel, to support things that are in flight, you need to start thinking about a core set of questions. What are the if nothing else, if you only got maybe 20, 30 minutes from that product or engineering leader that go to market leader, et cetera, to figure out, okay, what is this rationale and why not partner or build instead, et cetera, what are those five questions that's going to ideally get at? In what form would we bring this to market? And that of course should open the can of worms of is there something that gets sunsetted? Are we integrating it? Is it a feature, that sort of thing? Why not build or partner or are there pieces? Is it an and? Maybe it's not an or, it's an and. Also considering how is this worth it? What's the value? Is it a hard dollar value or is it a compelling intangible domain expertise? And then my favorite, what would kill the deal to push the thinking around? If something significant came up during diligence that has the potential of just unplugging the whole idea, what would that be? Also, where does this sit in the stack of other competing priorities? That's a big one to understand for that engineering leader. Is this truly top of mind or is this just a bright shiny object? That's fun to think about. But then when the rubber meets the road for hey, we need all hands on deck, we need those resources, we need that headcount that was promised to flesh out this integration, execution, et cetera, to understand where this sits in priorities. And of course that then points back to what we've touched on a couple times, that the real value of understanding the backdrop of what are our strategic priorities, which of those do we expect to pull an inorganic strategic lever to execute? Because if something is on the table for hey, let's do a deal around live streaming video for whatever purpose, and you already know that's a hot topic as far as a roadmap gap, or it's something that is really top of mind for internal leadership, then you should already know some of the answers to the questions that you have on your hit list. Having that set of core questions invaluable, because then you can just say, you know what, I just need Half an hour and I'll walk you through it. Go ahead and share the questions in advance, but honestly, you'll get a muscle memory around navigating and guiding those deal sponsors through those questions. And last, I would say develop and leverage scenarios to help guide their thinking. To prompt them to think. Okay, this is what a scenario looks like and I'm just talking about two or three slides that highlights. Here's a standalone offering, here's something that's integrated into an existing product, here's a, hey, we're sunsetting it and we're just leveraging domain expertise and key talent, et cetera. Outline those scenarios so that then you can further hone and focus that guided interview, if you will, of deal sponsors. That, in a nutshell, is it.

What's the craziest thing you've seen in.

M and A without naming any names?

No names and dates?

Yeah, one of those. Hey, we're doing it. And by the way, we're closing in just a few days. Craziest thing is to close in a few days and essentially be doing diligence and integration planning after you close. Wow, I've done that. It's not fantastic, it's doable. You just know that you're going to stumble across things that it's like, if only we'd known.

Is that like a fire sale that triggers that? Why would you do a deal like that?

I'd say there's a number of mix and match possible ingredients that get you to that point. Certainly opportunity window is one of those. But also there's certainly competitive bid situations. There's an understanding that maybe certain target companies have extremely rare and compelling domain expertise or thought leadership and if that target company becomes available, then maybe it's a no brainer for that reason alone for the acquiring company. So it's like, nope, we're just gonna do it and we're gonna figure it all out later.

Hopefully nobody lost a bet at the bar. I enjoyed this conversation. Thank you so much for spending the hour with me. You're a tough first interview. I'll just be honest. That was a lot of fun. You're really good, you're really smart. So thank you so much.

Oh, thank you. It was my pleasure.

Here's to the deal.

Thank you for taking the time to explore the world of M and A with our podcast. Please subscribe for more content and conversations with industry leaders. If you like our podcast, please subscribe. Support us by leaving a five star review and sharing it. I enjoy hearing feedback and connecting with our listeners. You can reach me by my email. It's Kisan K I s o nealroom.net M&A Science is sponsored by Deal Room, a project management solution for mergers and acquisitions. Additional educational content is available on Deal Room's blog@dealroom.net blog. Thank you again for listening to M and A Science. See you next time. Views and opinions expressed on M and A Science reflect only those individuals and do not reflect the views of any company or entity members 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.