Acquiring a product or portfolio of products is an extremely difficult endeavor. A significant amount of money is being laid out and everyone involved has their reputation, ego, and even career on the line. It’s an incredibly complex process with many victories and defeats along the way—definitely not for the faint of heart.
There has been a significant amount written about this process, with most of it centering on selecting the right acquisition target and negotiating the deal. Those are both important topics, and the product manager should be leading the charge for those endeavors, or, at the very least, be heavily involved, but it doesn’t always happen that way. While it’s not ideal, product managers often find themselves brought into the acquisition process in the due-diligence stage.
Let me set the stage here. The CEO has decided that it’s time to buy a product (or product portfolio) from Company X. He and his reports have met several times with the CEO of Company X, preliminary terms have been laid out, the board has been apprised of the deal and it’s moving to the due-diligence stage. That’s when you, the product manager, are asked to join the effort. It may also be the first you’ve heard of this acquisition. You and your engineering counterpart are being brought in to ensure that the deal is valid, the product fulfills the claims made and the technology assets are solid.
You are also being brought in because this acquisition will fall into your product portfolio and, thus, you are responsible for acquisition success. It may seem that due diligence is an activity that ends with you presenting a report; but, in actuality, this is a handoff exercise from the deal-makers. You won’t be closing the actual deal, but for all intents and purposes, you now own its success or failure.
While it’s true that due diligence can kill or alter the deal, nobody wants that to happen unless there are extreme circumstances. Considerable time and money have already been spent and the deal-makers may have already emotionally committed to this deal, so they don’t want it to fail. What they really want to know is how to make this deal work. What resources will you need to make it successful and how long will it take?
Your due-diligence presentation to senior leadership shouldn’t be a list of facts with a buy/don’t buy recommendation. Instead, it should be an exercise in managing the CEO’s expectations on how the acquisition is going to play out. You should tell the story of the acquisition, not critique the product being acquired. You need to lay out all the potential pitfalls with proposed timelines and required resources to get past those pitfalls. Furthermore, you need to treat it as a living document that you update and recommunicate as the process unfolds.
Create a Successful Acquisition Strategy
There is a strategy that drives most acquisitions. Are you buying this product to round out your current product offering because it has features your product does not? Are you trying to enter a new market segment without cannibalizing your customer base? Are you absorbing the competition? Familiarize yourself with the acquisition strategy so that you can adjust your product strategy accordingly.
Years ago, at a SaaS-based company, we planned to buy a product to round out our overall offering. The acquisition target had a set of features that we had not built due to competing priorities, and the CEO felt that this was a key gap that needed to be closed. What the CEO didn’t tell me is that she expected this product to become completely integrated into our product relatively soon after the sale closed—and that integration was key to her acquisition strategy’s success. Someone told her it was a relatively easy process to integrate the acquired functionality into our product, and she didn’t want the customers to have to keep using the two products separately. I now had expectations to manage—I needed to educate the CEO on exactly what needed to be done to integrate the two products, which wasn’t news that she wanted to hear.
Whatever the acquisition strategy, you need to ensure that you understand it—and the corresponding expectations in detail—so you can properly prepare yourself for what you need to do. You will need to take action, and that action will cost money that the dealmakers probably didn’t expect to spend. Furthermore, you need to ensure that you communicate those needs early and often—never assume that management understands the complexity involved or remembers it between updates.
Address the Product Debt
Product debt is a newer concept with some ambiguity, so I’ll use Anthony Marcano’s definition: compromises in the external quality of the product. These are typically poor/confusing user interfaces, known defects, and poor performance. The good thing about product debt is that it’s typically easy to demonstrate. You can show your CEO the confusing user interface and poor performance and they will understand the issue.
The debate really is about which of these problems truly need to be fixed. Customers seem to be buying this product, warts and all, so do you really need to fix it?
This argument sounds reasonable on the surface, but it has two key flaws. First, your customers’ expectations may differ from those of the acquisition’s customers. Was the acquisition a startup? If so, people may forgive more defects than they would from an established company. Second, did the startup spend more time working with each customer to educate them to handle the product’s shortcomings? As a larger company, you might not be able to spend as much time with every customer.
Address this before the deal closes. Once the deal closes and the dust settles, product debt will be your problem and the CEO may forget about an unwillingness to pay to fix it if they see dropping customer-satisfaction scores or an increase in support calls. If you don’t have the resources to resolve these issues, you will have to take them from another area of your product.
The strategy to employ here is to get enough resources to elevate the acquired product to the same level of quality and usability as your current products. Your company’s customer expectations need to be maintained with this new product. Be sure to have a plan and schedule to go with the funding request so that you can illustrate how and when the product debt will be addressed. If you have case studies from your own product—such as a reduction in customer complaints when an interface was improved or response time was reduced—that will make your argument easier to make. If not, talk to your UX director. They often have third-party research that illustrates the value of resolving product debt.
Quantify the Technical Debt
The question isn’t if you’ll have significant technical debt. Startups always cut corners in order to get the product to market on a shoestring budget, and established companies don’t invest in a product they plan to sell. Instead, you need to answer how much technical debt you are willing assume and how much needs to be addressed in the immediate future. It doesn’t sound that difficult to estimate, but I’ve never met a development manager who felt comfortable trying to quantify technical debt.
The big problem with technical debt is that it’s invisible to anyone outside of development, and it’s extremely hard to quantify without looking at every line of code. Development managers know that if they overestimate the amount it will cost to resolve, their opinion will be written off as unreasonable. If they underestimate it, they’ll be held accountable for fixing it without the needed resources. There is no way for them to win, so they naturally punt on the issue and say it’s impossible to estimate.
The other problem with technical debt is that you never will address it all—it’s simply not cost-effective. All the products that you currently manage carry a decent amount of technical debt. The development team works diligently to resolve as much as they feasibly can, but they’ll never get it all done and deliver the new functionality that you demand. The same applies to this new acquisition—you won’t fix all its technical debt, either. You’ll fix as much as you need to immediately and then shave off a bit more each sprint, like the rest of your products.
There are tools that analyze the code and provide an estimate of what’s necessary to resolve the technical debt, but, at this time, I haven’t found any that are reliable enough to bring into a boardroom presentation. Further, I’m sure those results would be hotly contested by the management of the product that is being acquired. So, with no qualified human being to place a value on technical debt—and with the technology falling short—what are you to do?
When I worked at an automotive software company, the development manager and I used the same solution that proved effective for the product debt: Estimate what it will take to bring the acquired product up to the same technical standards as the current products in your portfolio. If you can create a new build of your latest code base with the click of a button, but the acquisition has a multistep manual build process, you need to estimate how much it will take to get them to a single-click build and deploy. If your software has 70 percent automated test coverage, you need to call out the effort needed to bring the acquired software to that same level.
Take this amount and add 20 percent for what I like to call “guaranteed unknowns,” and you have your technical debt estimate. However, you’re not finished yet. You also need to create a project plan to resolve this technical debt. The plan will help you manage expectations and ensure that time is carved out of the development schedule to resolve the technical debt. Invite the development manager to help present this to management. Clearly communicate that you are not resolving all technical debt, but are elevating the product to your company’s minimum standard.
Assess Your Sales Team
If this acquisition goes to completion, the expectation is that your sales team will sell this new product. Typically, no sales staff will transition to your company, so the success of this acquisition rests on two questions: Can your sales team sell this product? Will your sales team sell this product?
To determine if your sales team can sell this product, you need to look at a few factors. First, does your sales team have the right understanding of the product and the market to sell it effectively? Are they selling a similar product to the same customers or a new product targeted to a completely different market? If it’s the latter, you had better have a plan to bring the sales team up to speed quickly or add some new salespeople.
Once your sales team has the knowledge to sell the product, ask yourself if they have the right relationships to start selling this product. If they’re selling to a new market or are pitching to a different decision-maker in the same market, they might need six months to a year to build the relationships needed to start the sales process. You might need to budget for customer visits or new trade show presentations. You will definitely need to ensure that you adjust the sales goals to match this new relationship-building period.
The next question to address is: Will your sales team sell the new product? At first glance, it may seem like a silly question, but keep in mind that salespeople are experts at maximizing their commissions while minimizing their efforts. If they have to learn a new market and new product, will they make enough for it to be worth their time? If they sell this product to current customers, will it replace a product (and commission) that they’ve already sold? Do they already have such a large product catalog that this will get lost in the shuffle? Is this product trusted enough that they feel comfortable risking relationships they’ve spent years building?
If you don’t already have a deep understanding of how your sales team functions, have several off-the-record conversations with high-performing salespeople about the situation. However, this might not be possible if the acquisition isn’t public knowledge. If you find yourself in that unfortunate situation, the only thing you can do is take the product catalog, your understanding of the buying habits of the customers, and your overall sense of the market and try to put yourself in the salesperson’s shoes. Try to imagine, given what you know, how you would maximize sales potential while minimizing efforts.
Regardless of how you assess what the sales team will do, you need a plan to mitigate it. How do you change the game so that the salespeople will sell the product? Do you add incentives? If so, how much, and how will that affect the product’s profitability? Can you add some inside salespeople and focus them specifically on this product? How will the current sales staff react to that? Can you reasonably add some quotas for this product onto your current sales team, or is their plate way too full already?
Unless it is impossible due to confidentiality, you need to co-author this part of your plan with the head of sales. While you might control the P&L, they control the sales team and could kill this whole effort simply because they are unaware of what you’re proposing. In most cases, your proposal will help their effort to meet the sales goals this acquisition will force on them, so they should be happy to see these plans. However, nobody is ever happy when they’re blindsided. Because they can provide insight that you cannot, get them on board early in the process.
Finally, unlike product and technical debt, this is an area where creative and unorthodox solutions can really help. I worked with a business development executive who took the product on a six-month roadshow to all the company’s clients because he understood the software in detail. He handled the introduction of the new product and then let the sales team close the deal. In another company, a colleague who was the VP of sales created a new inside sales team that focused only on the acquired product for a year. These were junior sales reps looking for a chance to prove themselves and, after that year, the successful ones were brought on to the sales team.
Create a Customer Support Plan
Next, you need to determine if your support and development teams can reasonably support this product for your customers. You need do a few key analyses. First, does the current support model fit into your company’s support model? Are current customers used to calling up and getting a live person, while your support model requires navigating through an automated menu? Can their support reps handle 90 percent of the support items in the first call, while your company requires customers to go through multiple tiers of support? I’m not suggesting that you need to modify your support model for this new product—although that might be the right choice in some situations—I am saying you have to assemble a plan on how to manage this change for your customers.
Don’t switch customers over in a single brute-force effort; instead, gently migrate them to the new plan with messaging and training. I learned this lesson the hard way after switching support models overnight on unsuspecting customers. They all called their salespeople, who in turn, called me. Those were not pleasant conversations. Save yourself some trouble and work with the head of support to figure out the best transition plan for the given situation, and include the extra costs in your overall budget.
Second, is your development team able to support this product? From my experience as a developer, it can be difficult to support software that you didn’t build. There will be promises of documentation and technical guidance from the company selling the product, but I’ve found those to have marginal value when provided. Expect no technical help and budget developer time to learn the system, as if they have to investigate it themselves. If you shortcut this step, you’ll still have to conduct the investigation, but your developers will be building new features and fixing bugs while doing it, which will cause delays and make your developers hate your very existence.
Third, how much additional development and support staff must you add to manage this new effort? Typically, management assumes they can match headcount to headcount when they plan staffing for an acquired product. However, that rarely works, because the people who built the product and supported it in the early stages are experts in the product, while your new staff will be novices. They lived and breathed each line of code and every new function, so they can fix issues and build new features much faster than your team will be able to do. Make sure your plan addresses this knowledge gap with the right amount of staffing.
Building and Presenting the Plan
If you’ve carefully considered the points I’ve made, you will be in good shape to develop and present a balanced case to management that details the true costs of the acquisition. Build your presentation as a positive, forward-looking plan for successful product acquisition. Address the acquisition strategy in detail, using the dealmakers’ own words, when possible. It is the key to success. Don’t back down on your assessment of product and technical debt. Product debt will kill your customer-satisfaction scores and ruin your reputation in the marketplace. Technical debt will eat away at your development team’s productivity and morale; it might even cost you some of your best engineers.
Involve the head of sales in your presentation, and be sure your plan addresses any shortcomings in the sales team’s knowledge or incentives. Finally, ensure that you have the right staff in place to support this product going forward. If you don’t, you will spend your time calming dissatisfied customers and disgruntled developers.
Expect significant pushback. Your plan will be expensive and will probably alter the business case that’s being used to drive the deal. However, it isn’t as much about fighting the pushback as it is about creating a clear picture of what is needed to properly manage the acquisition. If management decides to ignore some of your requests, ensure that they understand and accept the risks your request was designed to mitigate. If that risk is realized in the future, it may be a card you need to play.