Strategic Acquisition + Tech Assets: the Good, the Bad, and the Underlying
💚 What Makes a “Good” Asset?
A paintbrush in the hands of a renowned artist can be a tool for endless production of masterworks; in the hands of a toddler, it is more likely to result in decreased home value. Is the paintbrush an intrinsically good or bad asset? Is the value of the old master’s tool the same as the toddler’s?
Sometimes, putting an asset in the right hands can unlock value where there was previously none. Assets that seem like nothing but liability can be transformed into profit. Whether through synergy, novel use, or simply better execution or resourcing, there are many examples of “failed” assets that found success after a strategic transaction.
Synergy
While “synergy” is frequently parodied for its overuse and abuse, it is also a real concept with true potential. Many software, data, or patent assets that are gained through successful acquisitions create value through synergies.
Simply put, tech assets typically create synergies when they make other products or services better. Normally, synergies are created when larger organizations with established products or services acquire assets from smaller organizations. In other cases, acquisitions occur when larger organizations spin out or “give up” on non-core activities. In both cases, when larger organizations acquire assets like software or data, the “synergistic value” is unlocked by scaling a capability across the acquirer’s product or service portfolio.
Here are a few examples of synergistic tech asset acquisitions:
Synergy on paper is one thing. In practice, however, realizing the potential value often depends on many details related to the asset and acquirer. For example, large differences in technology infrastructure, software architectures, programming languages, open source strategies, or brand can result in unexpected costs or missed opportunities. It’s key for organizations acquiring software or data assets to validate the assumptions in their financial modeling with proper technical diligence.
Novel Use or Licensing
The second common pattern among successful strategic acquisitions is novel use. In this case, an asset is currently being “underutilized” from a strategic perspective. Creative acquirers purchase the asset and then use it in new applications, new markets, or new commercial strategies. Software and data frequently fall into this category, especially when they are related to “behind-the-scenes” automation or machine learning.
Internal Use 🡲 Market
Technology solutions are frequently initially developed for internal use. Organizations might create software or collect data to automate a task as part of solving an internal pain point. These systems and records might successfully enhance margin or reduce risk within the company. For a variety of reasons, management often fails to consider whether such tech or data could then be leveraged elsewhere. Even when they do identify such possibilities, financial or operational constraints may prevent them from executing on these strategies.
These situations often present valuable opportunities for “spin-outs” or strategic partnerships. The seller typically receives ongoing license or preferential usage rights along with a cash payment, partial ownership stake, or future revenue share. The acquirer or successor organization can skip the research and development phase, going straight to market with tested, mature solutions. In cases where there is fear of competition or cannibalization, these deals may also feature geographic or industry exclusions.
Alternative Strategies
In other cases, startups or R&D groups develop a technology or dataset for a narrow commercial purpose. When they go to market, they may fail to gain traction or hit profitability goals. Another organization may identify alternative use cases for the assets, expanding the total addressable market or finding higher-margin opportunities. Sometimes, the alternative strategy is as simple as licensing or white-labeling. In situations like this, strategic acquirers can obtain assets at a substantial discount to their “true” value if the seller does not appreciate or hasn’t contemplated the alternative uses of their asset.
Risks of Moving the Inside Out
Vetting information security risks, maintenance cost budgets, and open source licensing is often critical for situations like this. Because many internal use applications were never intended to be redistributed or made available to third parties, some aspects of their design may create serious legal or business risk like potential litigation. Technical diligence can help identify and measure these risks so they can factor into the price or legal terms of the deal. In addition, the sooner the acquirer gains a technical understanding of the assets, the sooner they can plan for scaling or enhancing their team to support the acquisition.
Execution
Paradoxically, many good assets available for acquisition are paired with bad execution. To understand the paradox, you can think about why technology organizations or projects fail. One possible answer is that the technology did not meet a real need or that it was not properly designed or implemented. The other possible answer is that the technology idea and implementation itself was viable, but some other element of execution was at fault. For example, a product with great potential might be paired with a bad marketing strategy or poor customer support team, generating fatal early turnover or poor sales pipeline.
When evaluating failed tech organizations, identifying bad execution is often key to making good investments. This bad execution typically yields poor financial results, which creates a context for acquiring software or data assets at a substantial discount. Furthermore, identifying the “problem” areas prior to acquisition allows organizations to better plan and cost out post-acquisition financial models and strategy.
Technical diligence can help confirm the thesis of stories like this. For example, when project management artifacts show well-researched product-market fit and software engineering teams ship clean source code on good processes, it can validate the idea that root cause lay with sales and marketing, not the tech per se.
🚩 What makes a “bad” asset?
Conversely, there are some red flags for tech assets that should generate immediate concern. When these findings show up in diligence, organizations should make sure to take a conservative approach to bidding or valuations.
Sloppy IP practices
Intangible assets like software and data represent the majority of value in recent M&A deals and VC/PE investments. But when it comes to creating and protecting this intellectual property, there are many ways to slip up. For most acquisitions, diligence starts and ends with checking the terms of contracts for individuals and organizations that wrote the code. But are work for hire and IP assignment clauses really the only things that matter? While reps and warranties address these in almost all deals, recourse is practically limited when distressed companies or Section 363 bankruptcy sales are involved.
In reality, these legal tools are necessary - but not sufficient.
All too frequently, we see organizations with the right thing in their contracts but the wrong thing in their source control repository or machine learning models. For example, if the individual moonlighting as one of your software developers was working from their “day job” employer’s device, who owns the code? Can suing a single person for breach of contract or a company with no revenue really help solve a $10M liability? These risks can come up in a myriad of ways related to open source licensing, unauthorized data use in machine learning, or undocumented software authorship.
Standard technology diligence can quickly and easily grade IP practices and help document the provenance of software and data assets. When the IP practices around an asset seem off, there’s almost always more to the story if you keep digging.
Poor Tech Foundations
When it comes to technology assets, this one is the most obvious. Sometimes, good ideas have poor technology implementations. Software assets might be riddled with poor design choices, unscalable architectures, abandoned or unsupported dependencies, or countless security hazards. Machine learning models might be trained on bad data, wildly overfit, poorly specified in their targets or outcomes, or built on unreliable or unexplainable techniques.
Buying assets like software or machine learning models without adequate tech diligence might not end up being a failure, but it’s almost guaranteed that buyers pay too much or underestimate the timeline to return their investment. When tech diligence is done in advance, it doesn’t just result in better marks on the assets; it also helps the new owner make better strategic and operational plans for life after acquisition.
Flying Blind with Compliance and Risk Management
Tech assets that have been designed in a vacuum of compliance and risk management often fall into the “bad” asset category. Design constraints, metadata collection, or regulatory requirements must frequently be incorporated from the beginning of a project. When things go really wrong, they can taint an entire asset or business. Understanding these potential risks begins with diligencing the culture of compliance and risk management – or lack thereof.
To be clear, this doesn’t mean that you need to start with the headcount for compliance or legal departments. There are plenty of high-quality, valuable assets built without a full team of attorneys or a Chief Risk Officer. What’s most important is that the people who designed or developed technology or data products had an appreciation for risk management and regulation. While compliance and legal departments can certainly help, most risk is generated by the individuals making daily decisions about what features to build or what data to collect.
Traditional diligence approaches often identify some elements of this “cultural awareness,” like product design documentation, risk registers, or related policies and procedures. However, there is no substitute for technical diligence on the infrastructure, source code, data, and machine learning models. Even the best-intentioned policies and procedures cannot guarantee that software or data does not run afoul of regulatory frameworks like GDPR, HIPAA, or ITAR. While many of these topics may be covered in purchase agreements, acquirers do best to identify these issues before closing. Even when these risks don’t sink the deal or result in price adjustments, the parties can begin working towards risk mitigation or rep and warranty disclosures.
Making Strategic Strategic Acquisitions
Companies looking to make a strategic tech acquisition should go into negotiations with a clear assessment of where the technology assets actually stand. It’s easy to jump to thoughts of what the future could look like with the acquired technology or data, but acquirers should ensure that their hopes of the future are backed up by the actual state of these assets. If the diligence supports the hopes, then the outcome is “YAY! A great strategic acquisition!” If the diligence suggests that there are serious issues with the technology (whether technical, legal, or another high-impact area), then the outcome might look more like “Yikes! We dodged a bullet” or “Let’s talk numbers.”
One company’s tech trash may be another company’s treasure. Just make sure you look inside the treasure chest before you buy it.
Our technology due diligence services arm potential acquirers with the information needed to determine whether an acquisition is actually strategic, the state of the tech assets, and where to focus their negotiating budget. In some cases, an acquisition is beneficial, even if the tech assets are less than ideal or expose the acquirer to risk – the important factor is having this information prior to negotiating deal terms so that the valuation and reps and warranties are aligned with actual risk.