Are you a savvy software investor?

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:

• Product architecture

• Software development processes

• Product management function

• Leadership

• Team structure

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.

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. 

When assessing software development, these are some important questions to ask:

• How strong or well-defined are the software development artifacts and tools (user stories, test cases, burn-down charts, acceptance criteria, status reports, etc.)? This is a key indicator of the maturity of software development capabilities. Less formal processes typically yield unpredictable results. Smaller development teams can get away with less formal processes, but as they grow, these assets are important to ensuring quality and meeting deadlines.
• How involved is the product management team? Are there consistent communication channels for the development team to receive feedback from product management or even customers during the development process? While good business requirements give developers direction for creating new features, software concepts can be abstract. It is difficult to evaluate if new features will meet customer needs until working software is available. Look for processes that incorporate agile development practices that encourage a high degree of collaboration throughout the development process. Developing the wrong features wastes investment dollars and time.
• How is testing performed? What tools and processes does the target use? What is the blend of manual versus automated testing? Too little automated testing typically results in a bloated Quality Assurance (QA) organization and slower processes. It can also result in overall lower quality as automated testing can be executed more quickly and often with less human error. The specific amount of automated vs. manual testing will vary depending on several factors: complexity and type of product, frequency of releases, current defect rates, and QA team size. Any combination of high frequency of releases, high defect rates, and small QA team size would suggest a need for higher levels of automation – in particular, for regression testing. Generally speaking, if your automated testing is less than 25% of your overall effort, you’re probably relying too much on manual results. It is also important to validate the presence of all forms of testing—unit, system, integration, regression, and stress—and to understand how the target handles each. Finally, make sure to ask to see the testing results. It’s not enough to have the plans – the results should be analyzed for thoroughness.
• What are defect levels and trends? How many high-priority bugs exist? What are the historical defect rates per release? Where in the development cycle are defects being introduced and where are they being discovered? This data is critical to understanding overall development quality. If the numbers aren’t good, then you may find that developers spend too much time on maintenance/support and struggle to complete development tasks in a timely manner. Specifically, ask how much time developers spend on new development versus maintenance. Anything above 25 percent of time spent on maintenance should be cause for concern—or at least further investigation. And, if the target can’t produce metrics around defect trends or bugs, that’s an indicator of immaturity. The target should categorize the defects and “high” priority bugs shouldn’t be more than 20% of the total defects. Finally, a large gap between when a defect is introduced and when it’s discovered can also create a drag on the team’s ability to deliver.
• Does the target have a definitive definition of what “done” means and when a release is ready for deployment? This is a simple question, but it is surprising how many organizations cannot answer it. Ensure a formal release plan exists and that the target has defined what success looks like prior to release. Imagine building a house and not knowing, once it’s complete, whether it will have 4 or 5 bedrooms.
• How effective is the “dev ops” group (the team responsible for moving new code into production)? This is a lot like picking products from a warehouse shelf, packing them, and shipping them. The products may be great, but if they are mishandled, mislabeled, or damaged, quality and customer satisfaction will suffer. Try to determine the extent to which the target uses release automation and the process for code promotion and release management. A mature process produces fewer code-to-production issues. The software development processes can be a particularly challenging area to assess during diligence, due to constrained access. The more metrics you can assess around release history, bugs, defects, and other areas, the better informed you will be. Mature organizations should be able to reproduce test reports and pass/fail rates by functional area or release that provide a view into quality problems. For example, was there one release with particularly high fail rates? Why? How did the target correct the issue and learn from it? In the end, the best way to evaluate a target’s development processes is speaking 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.

Assess these questions can help understand the target’s current leadership capabilities and any gaps that may need to be filled:

• 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.

These are some key questions to ask:

• What is the development team’s structure and model, including the mix of onshore, offshore, and near-shore resources? There is no right or wrong answer, but if diligence indicates problems with the development process or development operations, team structure may be a contributing factor. Managing offshore relationships adds complexity. Ensure your leader isn’t doing it for the first time. Also, become knowledgeable regarding the offshore options, as there are considerable differences (rates, dialect, time zone support) based on the region.
• How is the team organized? Are there separate teams per product? Are teams cross- trained by product or technical platform? Look for development teams that embed business analysts and quality assurance professionals into the development team. This helps create efficiencies with fewer hand- offs and clearer communication between product management, quality assurance and development resources. Also, be sure to track developer utilization. If the overall team size is large and pockets of low utilization exist, there might be an opportunity for cross training.
• What is the average annual turnover rate? The technology market is hot and retaining talent is a challenge, especially in specific markets. Although rates differ by geography and target size, consistent annual turnover above 20-25% is considered high. No surprise, high turnover will slow development, reduce quality, and extend release intervals.
• What is the ratio of developers to quality assurance/business analyst personnel? While test automation reduces the overall quality assurance team size, business analysts and testers are still required to create test cases and validate system functionality. Typical ratio ranges should be 3:1 – 5:1. It’s important to monitor the development quality and utilization of automated testing - and tweak this ratio accordingly if the results aren’t optimal.

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.