The go-to-market encompasses all the functions from marketing to generating leads through customer-facing roles like the sales team, support team, and professional services. And then, a whole slew of back office roles support that. But it is the whole soup to nuts. It prominently includes the product and engineering group's plans.
Maybe you put the product managers into the go-to-market channel, not so much the engineers because it's that product marketing person who's the bridge between the two, which is why that job is so hard because everything that somebody else doesn't own is owned by product management.
Importance of GTM
Companies need to generate revenue. And often, deals are justified on revenue. Even on talent deals, you're bringing talent to make products to sell. So unless you're in an altruistic endeavor, revenue is the reason for the deals.
And it's all about the customers. It's very disruptive to customers when there's an acquisition and integration, and so many things can go wrong.
- The team is not motivated
- Sales Reps don't like the deal
- People starting poaching your team
- A competitor starts to generate FUD
It's a very dangerous time. But on the other hand, you can knock it out of the park. Especially if your customers are telling you to buy the target company, that's a big win.
GTM integration gone wrong
So in this case, the host company and the inbound team had been working together as partners, and the customers liked using the products together, even though they are separate products. The teams knew each other, so the host company decided to make the acquisition. And they needed time to get the product into the host company's suite.
So during that time, they kept the salesforce selling and worked hard to integrate the products quickly. They found that if you keep selling the product and you're eventually putting it in your suite for free, people who bought it in the last six months will not be happy. So, in that case, they will have to refund those.
So if you're doing a business model and following that format, make sure you put the refunds in your business model.
But in the meantime, it kept the product in the market, it kept Salesforce motivated, and it got the customers on board. So realistically, there's no negative besides the commissions paid without any revenue.
Meanwhile, the sales team was excellent and much broader than their standalone product. So while they were still selling their standalone, they were ramping up on the larger hosted product so that those reps turned into representing the full suite by the time they were integrated.
So it worked out well, and I would attribute the things to the fact that they understood exactly where they wanted to go, they focused on that, they managed the sales team well, and the thing that it went into has been a huge success. That was a great story.
One of the worst-case scenarios I've seen happen a couple of times is when you acquire this product, and it's more complicated than what you sell standardly. So your general host account rep cannot sell this product by themselves. They have to have someone helping them. If you get rid of all the sales reps from the inbound company, you will have nobody to do that.
If you turn the inbound sales reps into generalists and your product is easier to sell than theirs, they will start selling your product, which is great for your product, but you just tanked the acquired product.
Even worse is if there's a competitive product in the market and your account reps have no help to sell the acquired product, they might actually tell the customer to go buy the product from a third party because they can't sell it and they can't represent it.
If they try to sell it to your customer with no support, odds are it won't go well and it might mess up their deal. So it's easier to tell the customer to buy the product from another company and let that company take care of it.
That's like your worst nightmare scenario, but I've seen that happen. Maybe people got their eyes set on a different part of the goal or they actually don't believe their product is so hard to sell. If it's really hard, they might not.
The difficulty of GTM
Many people in business functions, in sales, and even in marketing and engineering don't understand how sales works. Some of them tend to make assumptions about sales and how sales works. The smart ones bring salespeople into all their product planning meetings and pricing meetings. They are such a source of a reality check because they just have insights into the real market that are super helpful.
Before LOI, you make a P&L. You're making the business case to justify whatever price you will present and negotiate in the LOI. Of course, that business case has got to have elements of revenue, headcount, etc., so you must have an idea.
And as an integration lead, there are six questions that I want to be answered:
How many customers does the inbound company have? How many of those customers are my customers? Sometimes customer lists are confidential, but most larger software companies put their logos on their website so it's not like it's a big secret. I want to know if they have the same customers I have and if they are the same customers.
It's important to know that because if it's a volume of customers and I'm going to do something dramatic, that's going to affect my timeline and my costs.
If they have a small number of customers, maybe moving them onto something new isn't that hard. But if they're key customers of mine and what I intend to do with the product does not actually achieve parity with what they have today, they'll have a more significant influence on what I'm allowed to do. So, understanding the customers is important.
2. Product Plan.
Sometimes you don't know exactly what you're going to do as early as pre-LOI, but you have to take a guess. For example, you can guess if you want to continue selling the product standalone. Or, if you want to put it inside something you already sell, and if you will charge separately as a module or increase the price if you do that.
Part of that is thinking about how long that's going to take. If you decide that you want to stick it in a product. If you're a large enterprise company and you're acquiring something from a smaller company, there's a huge technical debt because there's security, privacy, even the way they manage the code might have to be modified in order to meet the larger enterprises criteria for putting their brand on the product.
So, knowing what you want to do with it and how long it might take is important. There is a big debate between optimists and pessimists about how long these things take.
Sometimes, one factor that weighs in on that timeline is that you can't just hire a bunch of contractors to fix the things you need to fix because it's the people who designed it who can fix it. But then you also want them getting into your product and fixing these things, and it's tough.
I mentioned earlier about product parity, which is understanding whatever you do with the product. If you have to make it the same or just make it what it should be, recognize that migration path because it might be uncomfortable for some customers and you might have to help them adjust, which adds cost. So, think about putting it there.
3. Sales team
Who is the sales team? Are they account managers who sell all of the products of the inbound company and go directly to the customer? They are the single face to the customer for that product.
Is it a technical sell? Are these people technical or are they classic account reps handshaking, back-patting guys and they have Sales Engineers that help them with the more technical aspect? Understand what kind of rep they have and whether they have SEs.
4. Do you have a place to put the reps?
This is an interesting dilemma for many companies. Most companies have account reps that sell the whole portfolio. And if you have just one unified thing, then you just need those types of reps.
But if you get more complex products, more specialized products, or even products that map into a vertical, then you have to have specialist reps. Specialist reps go out with account reps.
So if you acquire a team of sales reps that know their product well, you have to rely on your account reps to be the face of the customer, but you need these specialists to support you.
The first thing you can do with them makes them overlay specialists. This is a common format. They don't want to be called overlay so you might want to avoid that word, but that is what they are. In a way, they're not thrilled about that because they're not the single face to that customer anymore–they're part of a team.
So where do you park those specialists? I have three places you can park a specialist.
a. The ideal is in an incubation sales specialist organization. They're organized worldwide so all the people report to the same leader in the incubation sales area, and you farm them out to support the team.
b.The second scenario is in the business unit, which has engineers in it, doesn't have incentive compensation, might have some business development people in it, so you turn them into business development people who aren't on quota.
Sales reps like to be on quota. So now you put them in an engineering group where what they like to do and the care and feeding that they need isn't really available. You can probably park them there for a short period of time but it's not ideal.
c. The third place you can park them is in the geographies. You can send some guys in APAC, others in Europe, and what will happen is, the next time there's a layoff, those people are the most vulnerable because they don't carry big quotas. They carry a specialist quota.
4. How hard is their product to sell versus yours? What requirements are on me as far as when I have to generate revenue, and what can I do?
a. So scenario one is, finance has said this deal has to be accretive in the first year. We need that revenue to continue without slowdown. That's fine, but you should know that you will need to run that business off the inbound teams' whole infrastructure with their sales reps to generate that revenue.
That has a big impact on your plans for headcount–who you're going to keep and not keep. You can't get rid of the finance people running quotes to cash. You must keep that team because you need to keep that revenue going.
The problem with that is, if your end goal is to have that product inside your product, those engineers aren't 100% free to focus on that because anytime you're still selling, they're still involved. So your engineers are going to be occupied helping those customers.
a. The next scenario is that your company is willing to wait 12 months for you to get that product on your price list. Twelve months may not be enough time for it to be fully up to speed and perfect, but it's enough for you to get it on the price list. You might start by having them continue to sell it on their systems and then prepare to cut it over in a year.
b. The last scenario is you're really focused on the long-term. In that case, depending on where the product is, you might actually stop selling the product to new people. You might actually say, it's more important for me to get these pieces in there and make them perfect than to keep selling.
That takes a lot of guts and it means that the products you're acquiring are early-stage enough that stepping out of the market for a period of time is not all that disruptive. If a product has a brand in a run rate and things, you probably can't play that play. But if you really want to build the perfect product, and with all these little pieces, that's one strategy.
And I haven't even talked about back-office compatibilities, which also has to be factored in. I just talked about the front-facing part of the product. We all lived through this where we were working for companies that sold on-prem software, and all of a sudden we started acquiring companies that were software as a service. Of course, the systems have no idea what to do with those. And it took years for many companies to cut over from on-prem to SaaS. That's a major lift. You can't discount backend compatibility.
It helps a lot if the teams, including the finance leadership, the engineering group, and the sales leadership all come together and say the value driver of this deal is X. What is that? Is that something short-term or something that has huge potential? We need to get it right.
Maybe we need to have this as an investment, but that's a hard sell, especially depending on where the markets are at the time and where the pricing of startups is. It can be very pricey or a discounted time, so maybe you have a better chance of selling.
This is going to take a couple of years when the prices are low and are a bargain. Maybe your P&L will allow you to have more time versus when the prices are high and people want quick returns. You need to get the parties aligned on where the value is going to come from, which is different from the strategic rationale of the deal.
For instance, you have a deal where the value driver is the people. So the strategic rationale says we're going to get some real talent. That is not a description of a value driver around talent. A value driver around talent would be "the value of this talent to this deal and the company is that they have unique artificial intelligence staff."
A second value driver of this particular company's talent is that they are very connected to the university system and they're very connected to the pipeline of AI PhDs. That is an important value driver because they're going to give you a pipeline from there.
Now that you've identified that value driver, how you work with the team and what kind of hiring arrangement you make with those people could be different because you're factoring in that pipeline.
Value drivers must be able to answer the question, how will I get that value? Strategic rationales only say, "well, the value is this." The value driver says this is how I will get the value out of that. And the same holds for revenue.
Am I going to get the revenue just by continuing to sell this product standalone? If that product has an average deal value that is only a fraction of what the reps are used to selling, they're not going to bother selling it. So it's a problem if your strategic rationale is that you will be able to sell a lot of these things.
You get into due diligence, find out a lot more, and then you need to fine-tune. Frankly, in the area of GTM, you often can't see things in advance. You will not have perfect information until after close, and you need to factor that in. The due diligence should definitely give you ideas and insight on the reps.
- Are they achieving their goals?
- Are they left behind?
- Are they technical or not?
It's a learning thing all through diligence. One of the challenges for sales is when you come out of due diligence, assuming you're not doing regulatory approval, you will close pretty quickly.
And unlike some functions that don't have to do anything different on day one, the sales organizations and the customer-facing people at both companies need to know exactly what they should say and what their engagement model is.
- Is there compensation?
- Do I get comped on their product?
- Do they get comped on my product?
- Who's the lead as we go into the account?
There are a hundred things that a field-facing person would like you to tell them on day one, so during due diligence, you have to be working on those answers because you don't want to look foolish in front of those customers.
There was one scenario where it turned out that the host company had a product in the product area and the inbound company had a product in exactly the same area, so there was direct overlap. So we said, the enterprise rep for these accounts is the quarterback, the host company specialist is on the team, and the inbound company specialist is on the team.
They need to go to the customer together; frankly, they will let the customer decide which option they want. Again, it's the customer's choice, and we're going to be neutral about it because it's going to take us some time to integrate the products and we're going to guarantee that that path is there, but in the short term, either one is fine with us.
So what you need to do is all three of those people have to get comped. So if any of those people are out of the comp, then they're not going to do this neutral thing, but lobby for their product because that's the only way they're getting paid.
Big items to be clear on
- Engagement model
- Who's going to do deal approval?
- Sometimes the host company wants to insert one of their finance people into the deal approval process of the inbound company. It's a fiduciary thing, or they just want to have a little bit of influence there.
- Training–even if their rep is still just selling their thing and your reps are just selling your thing, the inbound need to understand your general product line, and the host company needs to at least be familiar enough with the new product to be able to pass a lead.
Involving the right people
You have to have someone on your integration team who is helping drive the GTM integration planning. It belongs to the product team, the engineering team, the marketing team, the sales team because it's their plan.
But to be honest, they're not very experienced in writing a plan for a product they didn't build in-house because when they build it in-house, they have an entire infrastructure most companies have. So everybody knows how to do that.
When you acquire a product, it's already in the market, so you won't go back to step one. Oddly, you're going to actually do maybe step two and three quickly, which might be stuff around technical debt that might have been missed. And then, you'll get into launch area stuff that you have to do. General business teams are not accustomed to doing that. Therefore you have to have someone who can guide them.
At several of the companies I've worked at, they have people that are within the integration infrastructure. They're with functional teams, usually, they're not part of the I M O. They're either from sales, they might be from marketing, or from a product, and they have to drive that. And everybody else should be supporting them because everybody else's plans depend highly on that plan.
You can't plan a headcount if you don't know the go-to-market plan. You can't plan for IT if you don't know what the go-to-market plan is and what the timing is likely to be. So it's in everybody's best interest to support the people trying to get a go-to-market plan written. It's not written in stone. You learn new stuff all the time and you have to be agile.
You go back to that value driver, is what we're talking about today going to get us there? Maybe something happens so dramatically that you change a value driver, but that's rare. Usually, those things are why you did the deal and you just have to figure out how to make it work.
Common configurations in terms of GTM integration strategy
You need to have 12 months running.
- You want their engineers to focus on getting the product on the price list and getting it qualified to sell from you. Either part of a suite or standalone.
- Continue selling through their reps, knowing that if you're going to put it in your product and not charge for it, you might have to do a refund.
- Consider comping your reps on sales of the newly acquired product. You want the two sets of reps to get to know one another and start strategizing on joint activities. Your reps aren't gonna do that if they're not gonna get any comp for it.
- Train your sellers on the product
Measuring GTM integration success
Well, one is if the revenue is coming in. The other one is if the sales team is staying. Many times, those sales teams leave fast. But that's not been my experience. If you give them a decent comp plan and you line up the comp structure, the engagement model, the training correctly, they're making money and they won't leave.