Previously published on Forbes Technology Council – April 26, 2022
In a prior post, Lessons Learned From 50 Technical Due Diligence Reviews, we offered information and advice to founders, CEOs and CTOs on what to expect from, and how to approach, technical due diligence review (tech DD). In this post, we cover how founders, CEOs and CTOs can prepare for tech DD.
In our prior post, we emphasized that tech DD is forward-looking. Investors want to confirm that as a management team, you will master the future opportunities and challenges on both business and technical fronts. Furthermore, an injection of capital usually comes around an inflection point in the growth of the company. For example, when the primary focus shifts from developing the product to increasing revenues, or when adding a major product line extension to conquer new markets. This period is conducive to a strategic reflection on how the company will win in this new phase, under the Marshall Goldsmith adage “What got you here won’t get you there.” After gaining a baseline for where the technology is today, the focus of a tech DD review will, by and large, be very similar to the questions addressed in a strategic review.
Below, we share the most common questions that we ask during tech DD in the hope that they help you prepare your strategic review as well as the tech DD itself.
We always start our reviews with the business context because the role of the technology team is to deliver the products that will enable the business to reach its goals. The product road map for the upcoming 24 months is, for the purposes of tech DD, the materialization of the business objectives. In this context, the product road map must include noncustomer-facing features such as performance, scale, security, business resilience and continuity.
The focus of the tech DD is to determine how well prepared the technology team is to deliver the product road map as promised and the associated revenues or other business metrics.
At the risk of simplifying, tech DD will ask the same questions, listed below, for all areas related to technology (see list further down), which we will later illustrate with examples:
• Is what you are doing today working?
• What are your plans for fixing what’s not working?
• Will the next 24 months create a discontinuity compared to the past year?
• If so, do you have a plan? If not, do you have a plan for a plan?
• Are there areas where you need to acquire competence (learn, experiment, hire, buy)?
The standard areas we investigate, and to which we apply the questions above, are:
• Software architecture and data architecture.
• Technical stack: frameworks for back end and front end, data stores, APIs.
• Performance and scale.
• Security, compliance, data privacy.
• Operational management: deployment, management, alerting, performance.
• SDLC process and toolchains: code analyzers, test automation, SCCS, CI/CD.
• Team: talent, organization.
In practice, this translates to questions like:
• Is the product road map aspirational (wishful thinking) or actionable (backed up by an engineering plan)?
• How much technical debt is there? What is the plan to tackle it, if need be?
• Will major components of the code require re-architecting or major refactoring?
• Are the data models consistent with the main use cases as well as future ones?
• How do your security, data privacy and risk profiles look, both now and once you have scaled 10x?
• Will you require new certifications for compliance?
• What critical hires do you need to make? By when?
• What would be the impact, financial and technical, of a two-day outage of your cloud hosting provider availability zone?
• Have the major technology initiatives (re-architecture, technical debt reduction, security upgrade) all been approved by the business team and budgeted (i.e., have time, resources and money been allocated)? Is the product road map based on budgeted resources?
Investors in high-growth companies, by and large, have a strong stomach and anticipate that at least one major software project will be needed every year or two. From what we can observe, investors generally have the strongest negative reactions to misalignments. For example, an aspirational rather than actionable road map (which implies that both budget and revenue plans are aspirational), or leadership that does not acknowledge that architecture, code quality, processes or security have been outgrown by the success of the company (which implies either lack of competence or lack of teamwork in the business and technical leadership).
In summary, the best scenario is when the business and technical leaders have performed a strategic review prior to fundraising. Preparing for the technical due diligence review should not be about cramming to figure out the answers to anticipated questions; rather, it should be about visualizing how the business, and its technology, will grow over the next two years and identifying the new categories of challenges that growth, and success, will bring.
One thought on “Lessons Learned From 50 Technical Due Diligence Reviews, Part 2”
This was a good read.
This is a great post on how to prepare for technical due diligence reviews. It is helpful to have an understanding of the goals of the review and the resources you will need to meet them.