Making M&A GTM Successful

‍Text Version of the Interview

GTM plan for New products vs Acquired Products

I will play the devil's advocate and say that the difference is not as wide as you might think. And the goal is to understand, how you as a company normally launch new products, and what makes sense for bringing in something that's acquired, which will entail some non-standard elements.

• Infrastructure pieces 
• Operating criteria 
• Billing models
• Legal terms, etc.

It will come with many things that are not standard to your company, and you're going to have to remediate them to bring them closer to or be the same, as to how your company brings new products to market. 

But with that said, the key difference between the two is that you have to build that bridge in an acquired product. You have to envision the starting point - how does this represent something that holds value for you, and how do you get it to the end-point to capture the value. 

And what I mean by the endpoint is business as usual for your organization. So that's the key difference. 

And that really requires a solid understanding of not only how you normally would bring something to market 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 input in place and that forms the middle of your bridge.

It’s a lot like buying an old house that you need to fix. You're going to have to work with some stuff that maybe you don't love and that you need to remodel. Or you could find something that you like that was not in the initial plan. 

Challenges

Communication is key. It’s all about 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 rationale.

From a product engineering and business leadership perspective, you sit down and think about the thesis. Why would we do this? What is the value that we're after? 

If you don't do that early on and then iterate later on, for instance, post LOI or even worse, wait until after close, then you are missing a key guardrail. And I would argue, a key guard rail in diligence. Because diligence is about adjusting your original thesis.  

Back to the bridge analogy, you need to understand where the capability gaps issues and where the skeletons in the closet are. Know where the bodies are buried as far as your internal operations from a go-to-market perspective. 

Consider how you normally bring things to market so you can understand all the X factors and the possible 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 as well.

Integration Planning Before LOI

I would completely condone that thinking. But I should clarify that starting integration planning that early does not produce a full-blown integration plan. Not only is it impossible because you don't have all the inputs, but it’s also not advisable to have a large enough tent and take up cross-functional resources and bandwidth to operationalize your 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, the go-to-market integration plan and the strategy for that is essentially the vehicle to the value capture. 

You need to create an idea of your execution path to that value. Back to the house analogy, you need to have an idea of how that might get built. Are you going to build it out of bricks? is it going to be a treehouse?

Having an execution path will help you check the viability of your plan, not only from a cost and time perspective to see if that deal is worth it, but also to check if you, as an organization, have the capability of doing this. 

And sometimes the answer is no. 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 from internal systems and policies perspective to bring a certain offering to market. 

So I would say start early, but then plan to iterate and build out and eventually operationalize before closing that go-to-market strategy. 

When to Start GTM Planning

Let's step back even further. Obviously, there are different scenarios for every acquisition. Sometimes there are opportunities that just emerge and you have to act fast. It's time-sensitive and maybe there are competitive bids and you don't have a lot of time to assess if it makes sense. You just go straight to LOI. 

That's one very specific case that I'm going to set aside for the moment. 

But generally speaking, there would be inbound inquiries. Bankers start reaching out directly to a potential acquirer and float the idea of an acquisition. 

And then there's also the constant brewing pot of ideas. Companies are trying to solve a certain problem and it's directly mapped to a roadmap gap. They are trying to fill a gap and start thinking about potential targets at a very early stage. 

So when you start thinking about solving a problem, it's at that point that you start thinking about how you would execute at a very high level. Before you even talk to anybody. That doesn't always happen, but that's the ideal. 

Now at that point, you can start thinking about a target company that will solve that problem. You can start putting together a 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 an add-on? 
• Is there a services piece? 
• Is there a premium support offering? 
• How would we sell it? 
• Is it something we charge for? 
• Are the services piece really the hook, and the licensing is where we make more margin? Or is it the reverse?

So really understanding what is it, that you think you're bringing to market and how are you moving the needle based on the monetization approach. 

Working with the Target Company

Something that one should always keep in mind as you step into confirmatory diligence is the deal type. 

• Are we just carving out an asset from a larger organization? 
• Is this an acquihire?
• Are we going to take their products and transition them to products that we directly have in the market? 
• Or are we integrating them with our existing product set? Etc.  

That's going to guide then the necessary approach to how you engage the target leadership in crafting the preliminary integration plan and to set expectations. 

Because part of it is planning and getting their invaluable expertise and perspective in thinking about the eventual post-close go-to-market strategy, but it's also about setting expectations. 

They need to understand the baseline objectives of your thesis and you want to engage with them and demonstrate that you care very much about collective success. But the sensitive part is around scenarios sunsetting a product. That is something that you want to communicate with them during the integration plan. 

So when you get to day one and integration execution, you don't end up wasting time debating on whether or not you really need to sunset this product. Is that product really more trouble than it’s worth? 

These are all considerations that are best orchestrated if you start to plan jointly within diligence.

Proprietary Deals vs. Auction Process

Not to knock inbound channels because there are opportunities there that can be unexpected gems. And that's also another reason why you should have your own house in order with a rough draft of your priorities around roadmap gaps, execution gaps, and where it might make sense to pull that inorganic level. 

Because one thing that you also have to consider is that, buying a company is just one strategic lever. And that’s something that you need to be prepared to walk your leadership through very early on. What is the right overall path to take?

• Does it make sense to buy?
• Does it make sense to build instead?
• Does it make sense to partner instead? 
• Or maybe it's a combination?

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 fundamental pieces of that capability, but you really don't have the domain expertise internally to build all of it, nor have representation as an operating player in that space. 

So then you have to go think about, do we acquire certain players that have a brand name, that is 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 about, does it make sense to partner instead? 

And that's part of the early-stage validation of what are we trying to solve and how might we do it. 

So even if you are rushed on your timeline because of that inbound opportunity, you have a cheat sheet of priorities. You already have a roadmap of what makes sense to your company. 

Factors to Consider When Building your GTM Integration Plan

Most organizations don't have a whole lot of dedicated M&A-focused resources. They have a few folks or a few teams that are dedicated to M&A work, and then they have a bunch of volunteer fire departments.

These are folks that have worked on deals before and you just rope them in to advise on some aspect of the deal. 

So aside from the importance of understanding how you bring things to market, the key is to take the time to get these people’s inputs, from folks who aren't necessarily M&A specific. 

People that are focused on sales ops, commercial, legal, HR. And to understand here's the common pieces that typically tie into an acquisition within your company.

And I usually refer to this as baseline deliverables. Know the common denominators and the things that you need to plan around. 

• Work with the commercial legal team during a certain point of confirmatory diligence
• Outsource team that’s going to scrub off stuff that’s in the data room from the target company

If we close this deal, there’s going to be a new product, or at least for some period of time depending on the integration path. And we're going 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? So these are all things that are just rough examples of common denominator, baseline deliverables. 

If it's something around an acquired customer transition plan: 

• Contracting transition plan
• Sales activation enablement
• Who's going to sell it? 

So all of these are workstream-specific function plans that are like a double click below the layer of your overall go-to-market integration strategy and your 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 workstream and function-specific integration plans. And that's where you see the baseline deliverable.

What I’m suggesting is that, in parallel with the pipeline and the in-flight projects, the trick is to start to build and capture those baseline deliverables. That will let you literally build a spreadsheet of checklists.  

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 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, for instance, transition a consumption-based product into a subscription-based.

So you really need to understand the baseline deliverables first. 

If you take yourself back to the kickoff confirmatory diligence, whether they're dedicated resources or not, you end up with this SWAT team of cross-functional delegates.

And those folks are going to be on the hook for providing you estimates in terms of timeline, potential notable risk issues, X factors of the deal, and they'll start to populate that high-level spreadsheet for you.

At that point, we're really talking about five or six line items max 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 in another way, figure out what the critical path is for each of those functions to be fully integrated, whatever that end state is that you're aiming for. And again, it depends on the deal scenario and the go-to-market strategy. 

When to Start Doing This?

It's a tricky balance, but I like to kick off internal working sessions on building out the integration roadmap assumptions, one to two weeks in confirmatory diligence. 

It's 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. And at this point it's not exactly operationalized. 

But you have this meaningful model where you think you have enough substance to lead it up to the senior leadership. Get buy-in from them and make sure there's alignment on that and then start to kick off the joint discussion. 

So you have to be heavily dependent on what the scenario is. How prescriptive do you need to be with setting direction for what that integration path is? 

But start having joint discussions with the target leadership about 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.

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 signing the definitive agreement, shortly before the close, where you have a relatively baked integration plan. But there will always be course adjustments.

Do You Work With the Target Alone?

It depends on the scale of the organization. It also depends on factors like if there's a regulatory review in the mix. There might be factors that require the tent to be small 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 discreetly and generically, hunt for insights.

So you're going to have some constraints around who you can bring in, 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.

How Do You Pressure Test the Rationale? 

I learned a long time ago that you're never going to get all the time that you want, nor the dedicated attention that you want from the internal leadership that represents your deal sponsors.  

So in parallel to supporting things that are already in flight, you need to start thinking about a core set of questions that will get you to understand the rationale. If you only have 20 to 30 minutes from that product or engineering leader, how do you extract information from them? And you need to come up with 5 key questions:

1. In what form would we bring this to market?
2. Why not build it ourselves or partner up? Or maybe both?
3. How is this worth it? What is the value that this brings to us? 
4. What would kill the deal? If something significant came up during diligence that has the potential of just unplugging the whole idea, what would that be?
5. Where does this sit in your priorities?
   

It’s invaluable to have this set of core questions so that you don’t demand too much time from your sponsors, and you can go ahead and share the questions in advance. 

Eventually, you 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. Outline those scenarios so that then you can further hone and focus on that guided interview.