Due Diligence (PE Edition)

The ideal due diligence needs to take into account 3 models: the business model, the org model and the data model.

The first two - evaluation of cash flows and margin, executives and team - get plenty of scrutiny in the purchase process. 

But the third - looking under the hood at code and data - often gets left behind or partially ignored. This is why it’s remarkable to me why so many PE firms end up believing that the way to growth is to pour more sales and marketing dollars alone, and not address underlying architectural issues with the same alacrity.

As an operator, I’m expecting a few things as the outcome of a DD model: one, a clear business plan on how the company will drive growth; two, an understanding of the risks; and three, an incentive plan for the operating team that aligns the business plan to the expected risk profile.

Ignoring the data model as part of a tech due diligence adds to the risk profile, distracts the team from real value creation and delays the returns. 

Remember that a software company is not the same are a retail business. A simple inspection of the property will reveal if inventory is stacked on top of each other, a la TJ Maxx. You need more to assess that in a software business - you need people who understand the code.

Which generation does the code belong to? Did the first developer who wrote the code recently die (true story)? What is the triaging that you need from a CTO? Is it just “move it to the cloud?” Or significant investment in refactoring that needs to happen? Is it just “let’s get it done offshore?” Or is there a strategy that supports the roadmap? What about AI? Do we have the skills as this is the value driver for the next decade or more.