The combination of strong margins and subscription-based revenue potential makes software an attractive asset for investors. In a competitive M&A landscape, however, purchasers often have limited access to targets, making it difficult to gain a comprehensive picture of potential software investments. Whether due to limited access or incomplete diligence, many software investors have had to extend the hold period of these assets to remediate gaps or risks they did not discover up front.
If you are in the process of or considering acquiring software assets, focusing on these five key areas can help you approach the transaction with your “eyes wide open” and avoid risks that either extend the hold period, require additional capital, or both:
Software development processes
Product management function
Whether due to limited access or incomplete diligence, many software investors have had to extend the hold period of these assets to remediate gaps or risks they did not discover up front. ”
Purchasing software is like buying a house. A small hole in the wall will be an easy fix. But a cracked foundation, mold behind the walls, or a leaky roof could require considerable investment to remedy. Key aspects of software maturity—architecture platform and design, code quality, configuration capability, extensibility, data architecture, infrastructure and security—can affect your ability to scale the product and maintain it efficiently. If you build an application so that the different objects and methods each focus on separate parts of the application, it makes it easier to extend the product and modify existing functionality with little to no impact on the rest of the product. Poor architecture can have a negative impact on performance, which in turn will require more maintenance resources. If the product architecture isn’t sound, the required investment to remedy is more than patching that small hole in the wall.
One often-overlooked aspect of product architecture is “technical debt.” Technical debt accrues in two main ways: (1) conscious decisions by the development team to build a less than ideal solution to meet a deadline or budget constraint, or (2) uninformed choices made to fix issues or solve problems that produce a more fragile product. Over time, technical debt causes development drag, which can grow to levels as high as 35 percent for products that are not designed or maintained well.
Over time, technical debt causes development drag, which can grow to levels as high as 35 percent for products that are not designed or maintained well. ”
Every product has some technical debt, and “some” is okay— technical debt occurs as applications evolve and developers balance investment cost, modernization needs, time-to-market and quality considerations. Think of managing technical debt as maintaining a fence surrounding your yard. As it ages, it will require maintenance, typically in the form of a new paint job. The right way to fix it (and avoid technical debt) would be to sand down the old paint, fill holes, and maybe remove some mold or rust – all before you apply the new layer of paint. A lead indicator of technical debt is when the Product Management team doesn’t allocate budget to address technical debt and, instead, only allocates budget for new features. When it comes to assessing product architecture, it’s important to understand if the developers are only applying new coats of paint to the fence without fixing the underlying issues. Make sure that you have enough time to understand how the product has evolved technically, the approach toward maintenance and enhancement, as well as the underlying code. Indicators of technical debt include extended development times, large teams, and a high volume of defects with each release. Be sure to ask the target for its opinion and approach to technical debt. If developers struggle to identify the areas of debt and their impact, that should be a red flag and a signal to dig deeper.
Today’s investors are particularly attracted to Software-as-a-Service (SaaS) products. If you are considering investing in an asset described by developers as a SaaS application, you will want to make sure it is architected to take advantage of the efficiencies gained from a SaaS deployment.
Most importantly, determine if it is a “multitenant” product—that is, one where a single instance of software serves multiple customers. Multitenancy applies to more than just the platform itself; the database, code, and hardware could be shared as well. Not every software product will or needs to be fully SaaS, but you’ll want to understand what you’re buying, especially if you’re paying a SaaS multiple. Finally, it’s critical to assess how the new SaaS platform was built, particularly if the previous version of the product was ‘on-premise.’ How much of the old code was leveraged? Was it rebuilt from scratch? Is the business logic easily separated from the data access logic? Is the user interface (UI) easily configurable? What has been done to ensure that one customer can’t see another customer’s data (e.g., separate databases, data integrity, security logic)? The architecture for a SaaS-based product is different from on premise and, thus, understanding how the new platform was built is important.
This is the process for producing the software. If mismanaged or run poorly, it yields the same type of result as a bad assembly line—incomplete or defective products, coupled with frustrated customers. Broken or poorly run software development capabilities may not be a quick fix. This is especially true if the development team is large (more than 50 people), geographically dispersed, supporting multiple platforms, and includes offshore resources. It takes 6 to 24 months to fix a broken software development process and may require capital investment in outside assistance. This remediation can extend your hold period, require additional unplanned capital investments, and distract you from key projects.
In the end, the best way to evaluate a target’s development processes is peaking directly to developers and observing regular team meetings to see how well these processes are working throughout the organization. ”
A strong product management function pays dividends and drives efficiency, while weak product management may result in inconsistent, unsustained focus, and wasted investment dollars.
The first thing you should look for is presence of a defined product management function. For small software companies, the “function” might be only the chief executive officer barking orders informally at the team. This may work for a small organization (fewer than 10 developers in a single location), but it is not an approach that will scale well. As the organization grows, the product management function should become a dedicated team.
If you must acquire new leadership, that can add 6 to 12 months to the hold period, not including onboarding time for the new hire(s). So, it is critical to identify any hiring needs during diligence.
What is the chief technology officer’s (CTO) background? Has he or she run a software development organization before? What is his/her prior SaaS experience? Has anyone followed him/her to the current organization?
What is the CTO’s track record during tenure with the target? What are his/her key accomplishments during the previous two to three years (for example, hitting release dates, re-platform to SaaS, measurable change, reducing technical debt, reducing team size, increasing release frequency)? Recent accomplishments, or lack thereof, can be a predictor of future performance.
What is the CTO’s product vision? How customer-centric is he/she? How does he/ she approach the product management function?
How engaged is the CTO with his/her team? What’s the frequency and type of meeting interaction?
How tactical or strategic is the CTO? You can get a good indication by asking these two questions: What keeps you up at night? If you had a blank check for R&D investment for 18 months, how would you spend it?
Finally, evaluate current skills in the context of future needs. A $20 million software company will require different leadership skills, experience, and levels of support than a $200 million company.
This can be the most challenging area to assess, particularly if the buyer doesn’t have access to the target’s team beyond the top 3 technology leaders. Nevertheless, it is important to gather as much information as possible, since team reorganizations and hiring can be big distractions to progress during the holding period.
It is easy, relatively speaking, to assess product architecture during the diligence process. The other areas, though, can be more difficult to assess—particularly when access is limited—yet they are just as important in executing software diligence. Gathering as much insight as possible about leadership, team structure, product management, and software development is critical to developing a complete and realistic picture of a potential software investment. Diligence can feel like putting a puzzle together, and you’ll never have all the pieces. It’s about gathering as much information as possible, supported by evidence, to identify the puzzle picture, even without all the pieces.
Understanding what to look for and being prepared with the right questions to ask will transform a lousy software investor into a savvy one.
I am even more accessible than the other modals.