13-minute read
Product acquisitions can be intimidating for product managers, but with diligent planning and expectation-setting, you can smooth the transition for your team. Explore expert guidance for navigating product acquisitions.
Product acquisitions are extremely difficult, slow endeavors. 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—not for the faint of heart. While much has been written about the product acquisition process, guidance on navigating acquisition often leaves out product managers. Product managers play an important role because they help leadership teams accurately assess the benefits and costs of the acquisition and chart a strategic path forward.
Ready to jump in? Read on to learn how product managers can survive and thrive during product acquisitions. Or, use the links below to jump to the section that interests you.
- What is a Product Acquisition?
- Impacts of Product Acquisition on Product Managers
- How Product Managers Can Support Acquisitions
- Building and Presenting Your Product Acquisition Plan
What is a Product Acquisition?
Product acquisition refers to the processes through which a business gets the rights to sell, distribute, or use a product. This might involve purchasing the product outright, licensing the product from another company or individual, forming strategic partnerships to acquire or use the product, or mergers and acquisitions (M&A) where the company merges with or acquires another company to gain its products.
Product acquisition is no simple matter. It involves rigorous legal contracts and agreements, reviews of regulatory compliance concerns, and, of course, considerations of each business’s best interest.
Impacts of Product Acquisition on Product Managers
Although product managers aren’t wholly responsible for the success or failure of a product acquisition, these business proceedings may have massive impacts on a product manager’s daily work.
Here’s an example: The CEO of your company has decided that it’s time to buy a product (or product portfolio) from Company X. Teams from your company 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 time 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?
How Product Managers Can Support Acquisitions
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, proposed timelines, and required resources to make your acquired product successful. Furthermore, you need to treat this due diligence presentation as a living document that you update and recommunicate as the process unfolds.
Here are some actions you can take to support a product acquisition:
Create a Successful Acquisition Strategy
Acquisitions should have a strategy that connects to business goals. Is your company 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? As the product manager, you should familiarize yourself with the acquisition strategy so that you can adjust your product strategy accordingly.
Years ago when I worked 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. The CEO didn’t tell me 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 expectations tied to it—in detail so you can prepare yourself and your team. You will need to take action to ensure the product’s success, and that action might cost time, money, or resources that dealmakers didn’t anticipate. You should communicate your needs early and often. Don’t assume that management understands or remembers the complexity between updates.
Address the Product Debt
Product debt refers to a product’s external quality and any compromises a product team made to that quality. For example, product debt might include defective product behavior, clunky user interfaces, or workflows that take users longer than they need to complete tasks. When preparing for product acquisition, your job as a product manager is demonstrating product debt and identifying which issues need fixing to deliver a satisfying product. After all, if another company’s customers are buying the product, do you 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.
Be sure to address product debt before the deal closes. Once your company acquires the product and it falls into your product line, it will be your problem. If customer satisfaction scores drop or your customer support team sees an increase in tickets, your leadership team may be willing to address that product debt after acquisition. If you haven’t budged 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 for the new product to maintain your company’s customer expectations. That may mean allocating resources to elevate the acquired product to the same level of quality and usability as your current products. 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 can help you make your case. Demonstrating that you reduced customer complaints by improving the user interface can help you secure the resources you need. If you don’t have that type of data, collaborate with engineering or user experience teams to gather third-party research that illustrates the value of resolving product debt.
Quantify the Technical Debt
The question isn’t “Will you have technical debt?”. The question is, “How much technical debt will you have? Startups often cut corners to get the product to market on a shoestring budget, and established companies don’t invest in a product they plan to sell. So, if your company is acquiring a product, there’s a strong change it will come with technical debt. As the product manager, you need to understand how much technical debt you are willing to assume and how much needs to be addressed in the immediate future.
It sounds simple to estimate, but many development managers face difficulty trying to quantify technical debt. That’s because technical debt is invisible to anyone outside of development and is 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. They’ll be held accountable for fixing it without the needed resources if they underestimate it. They cannot win, so they naturally punt on the issue and say it’s impossible to estimate.
Another challenge 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 some 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 obstacle applies to newly acquired products. You’ll fix as much technical debt as you need to immediately and then shave off a bit more each sprint, like the rest of your products.
So, with no qualified human being to place a value on technical debt and 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% automated test coverage, you need to call out the effort needed to bring the acquired software to that same level.
Add 20% for what I like to call “guaranteed unknowns,” and you have your technical debt estimate. As a diligent product manager, you should also create a project plan to 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. 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 your company acquires the new product, your sales team will be expected to sell it. Typically, sales staff will not follow the product to your company, so the success of this acquisition rests on two questions.
- Can your sales team sell this product? You will need to examine 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 is this a new targeted to a completely different market? If it’s a new product or a different target market, you should develop a sales enablement plan to bring the sales team up to speed quickly or add some new salespeople. Second, does your sales team 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. Your company should also adjust sales goals to match this new relationship-building period.
- Will your sales team sell this product? Sales teams are driven by closed deals and commissions. If your salesforce has 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 understand 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. Given what you know, try to imagine 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 support them if the acquisition goes through. 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 your sales team reasonably add some quotas for this product, or are their plates 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 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.
First, does the current support model fit into your company’s support model? Are the customers of the product you are acquiring used to calling up and getting a live person, while your support model requires navigating through an automated menu? Can the other company’s support reps handle 90% of the support items in the first call while your company requires customers to go through multiple tiers of support? If there are major differences, you should develop a training and messaging plan to manage this change for those customers. After switching support models overnight on unsuspecting customers, I learned this lesson the hard way. 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, can your development team 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 it’s best to expect no technical help during this transition. You should budget developer time to learn the system and plan to thoroughly investigate the product. If you shortcut this step, your developers will probably still have to investigate the product while fixing bugs and building new features on a short timeline. This 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. Make sure your plan addresses this knowledge gap with the right amount of staffing.
Building and Presenting Your Product Acquisition Plan
If you’ve carefully considered my points, 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. When possible, address the acquisition strategy in detail, using the dealmakers’ own words. 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 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 manage the acquisition properly. 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.
