One of our most popular posts is the sharing of our Tech Due Diligence checklist. This is indeed a great resource for conducting thorough and comprehensive tech due diligence on an acquisition or investment target. However, like all tools, the checklists’ utility is limited to the skill of the team that is using it and their ability to truly put the checklist in the context of the target being evaluated.

In this post we summarize how we approach Tech Diligence at a high level and how to optimize use of the checklist as part of the overall DD process.

We break the diligence process down along the following key dimensions:

  • Preparation
  • Tone & philosophy
  • Current phase of growth/scaling
  • Code review philosophy
  • And a parting word on....the BS sniff test

PREPARATION

In preparation for having a Tech Due Diligence conversation, we ask for about a dozen documents/process detail to make the live discussions as efficient as possible. The most important of these documents are the architecture diagrams as a foundation for the entire discussion. If the team can’t produce any diagrams, it is a clear indicator of level of maturity!

For smaller companies especially, it is more common for process documentation to be lite to non-existent which can be acceptable for the size of business but often indicates an opportunity for gradual improvement.

The sharing of documents is also often an early indicator of the teams’ strengths, level of organization/discipline, transparency and ability to collaborate.

TONE & PHILOSOPHY

Our team strives for a tone of genuine curiosity and learning in the diligence process and most importantly during the live discussions. Let’s face it, on the list of things that tech teams enjoy doing, performing due diligence is somewhere between getting a root canal and performing online annual training. However, if the discussion is more like an open discussion and a journey through phases of rapid growth, it’s a lot more enjoyable for all parties involved than an ‘inquisition.’ Related to this philosophy is the fact that the thought process in reaching a past decision is as important as the decision itself in assessing a team’s current and future capabilities. For example, in the early phases of finding product market fit and scaling a product to more customers, there can and WILL be significant trade-offs for many decisions and therefore it’s critical to understand how the trade-offs were assessed, what options were considered and how will the product be optimized as needed into the future (e.g. how and when will tech debt be paid down on a new feature that has significantly more and/or faster traction than anticipated?). There are very few cases where a past decision was ‘good or bad’ in black and white terms, the most important aspects are therefore the decision making process, critical thinking applied, trade-offs, demonstrated learning from past mistakes and taking action to improve over time. A common pitfall, which also highlights potential leadership gaps, for example, is not acknowledging the existence of technical debt (we all have it!) or worse yet not having a system for managing and drawing down tech debt on an ongoing basis.

Along with this philosophy of curiosity, we strive to conduct diligence discussions as conversations rather than Q&A. That is, we try to avoid asking most questions as ‘one-offs’ where possible and appropriate. An example may be “Talk about how you decide what to build? Starting with where ideas come from, how they are evaluated, prioritized and released to customers (fully, partially, through betas etc.)” rather than asking “How does Product Management generate new features?” This approach ensures we don’t railroad the discussion in any area or make assumptions about the ‘right way to do things.’ It also makes the discussion more free form (and generally enjoyable) and makes it easier to probe deeper where needed as the learning evolves more organically. For more practical examples of how to achieve this style of collaborative discussion and exploration, this post includes examples across diligence topic areas.

PHASE OF SCALING

Companies of all shapes, sizes and ages go through Tech Diligence processes, especially as companies often stay private for a longer period than a decade ago. Therefore, it’s important to tailor the process to the current phase of growth the company is experiencing as well as the expected growth roughly over roughly the next 1-3 years (timeframe may vary obviously based on input from the investing entity and current/expected rate of growth).

AKF’s questions and evaluation criteria span a likert scale from 0 to 4, but a 4 for many questions is what we would expect in terms of optimal scaling capabilities for a going concern business with a critical mass of existing customers. For many smaller early stage businesses though, it is not appropriate for them to have invested to maximum scale yet. That is, you should not always invest to be able to easily scale infinitely or near infinitely when you are in the early phases of growth, product-market fit and customer acquisition. Therefore, we evaluate based on the phase of scaling that is most appropriate for the current and near to medium term needs of the company. As an example, at large scale, ideally the datastore(s) are scaled across regions and are sharded based on a logical customer/product dimension so that storage is cost effective, resilient to regional failure and performant. BUT most smaller companies will start with one datastore with cold replication and failover which involves some downtime in the case of primary datastore failure and this may be completely appropriate for the company’s current size and business. In this case, the expected max score may be 1-2 out of the 0 to 4 scale and the evaluation of the current state versus expected max could be 100% or “rated 2 on a scale of 0 to 2”. This approach to evaluation is nuanced and critical to the outcome of assessing the company against its expected or appropriate current state as opposed to an absolute state of ‘scaling perfection.’

CODE REVIEW PHILOSOPHY AND THE EMERGENT USE OF AI

Occasionally we are asked to do code reviews for ‘quality’ and/or security posture. Normally we work with a third party to meet this need for philosophical and practical reasons. We do not perform code reviews in our standard process because:

  • If you ask a any developer to look at someone else’s code they will say “I would have done it differently”
  • In fact, if you ask the same developer a week after they finished coding something, they will also likely say “I would have done it differently”
  • Stated another way – there are infinite ways to implement an architecture in code, AND we find that understanding the architecture and current challenges relative to scaling based on the current architecture to be MORE important in evaluating the details of code implementation of the architecture.

That said, there can of course still be very messy, complex code that will be problematic to maintain and there are usually better approaches than others overall in architecting and application. In addition, the cost and simplicity of GenAI/LLM code analysis are improving such that there can be value in a cursory analysis using these tools to ‘point in the direction’ of areas that should potentially be understand in more detail so that the investor can better understand where investment will be needed and potential areas of significant risk or tech debt.

THE BS SNIFF TEST

Based on our approach of curiosity, learning and collaboration on the evaluation of a current company’s tech product capabilities, we rarely experience situations where the conversation becomes adversarial. That said, there are definitely situations where we run into a more paranoid individual, or a person that (seems) to believe they have never made a suboptimal decision. Alternatively, sometimes the engineering leader either doesn’t know the details or is trying to hide the details. In these situations, if the BS meter starts to rise and/or the individual doesn’t answer questions clearly in a way that they come across as trying to hide something(s), we will probe more deeply to truly understand detail (and may ask for examples, walk through of processes, bring in other sr engineers etc), especially in areas of risk or concern.

A WORD ON SELL SIDE DILIGENCE

We often help our clients with sell-side tech diligence evaluations in preparation for engaging investors. Although the process of assessment is the same, the use of the output and therefore how it is received are very different. In the case of buy-side diligence, the investor is sponsoring the diligence and obviously wants to understand the risk and value of what they are investing in, period. The investor obviously also does not know anything yet about the platform or team (or very little in most cases).

In the case of sell-side diligence, our customer is the entity being evaluated and so of course has a LOT of pride in ownership and what they have built and want to put the ‘best foot forward’ for potential investors. And of course, the sell-side diligence team has an intimate knowledge of all aspects of the product and team, whereas the buy-side investor does not. All that said, the sell-side company is still paying for an honest evaluation of what they have built for the purpose of sharing with investors as an accurate representation of their current state - and that is what we must deliver. When working with a sell-side team, we often perform 1-2 more iterations in terms of discussion and report refinement based on making sure we have a clear understanding of the platform, team, scale and risks that is accurate, while maintaining appropriate alignment with our customer. We also underscore that all companies need to invest as they scale, and a proactive and honest stance as to what the risks/challenges currently are, does not reflect negatively on the team but should be a positive indicator of self-awareness, learning from past decisions and planning towards future needs, i.e. scaling challenges are opportunities with growth as opposed to consistently a negative reflection of the failings of management! And see above regarding scaling trade-offs and the importance of decision making that is based on the current and near-term needs of the business, as opposed to infinite scale always.

WRAPPING IT UP

Conducting Tech Due Diligence is both an art and a science. Having a checklist provides a comprehensive foundation to start from but is only a tool to support a rich discussion that gets to the most important aspects of scaling a product technology business. We have performed countless tech due diligences across company size, industries and geographies. Call us and we can help!