Product - The Second Leg of the Technology Diligence Stool

This is the third in a series of posts to help search fund entrepreneurs evaluate tech-enabled (and more specifically software) businesses. The purpose of these articles is to equip the searcher to ask better questions earlier in the qualification process, and preserve precious time and capital for more qualified opportunities.

In the first article we framed how to think about a technology product company in terms of People, Product and Process. In the second article, we dived into the People leg of the stool.

In this post, we'll discuss how you can better understand the key risk areas of the Product of your target company. We'll discuss three key risks: Deployment Complexity, Extensibility and Hidden Costs. We'll share questions you can ask even if you're not an engineer to get a better sense of what lies behind the curtain. 

Deployment Complexity

Software can be deployed in (at least) three models: 

- Public cloud (where the app runs on a service such as AWS or Azure)

- On-premise (where each customer gets their own installation of the application)

Since you'll be buying not only the product but also all of the headaches of providing updates, bug fixes and new versions to the existing client base, understanding exactly how the software is shipped to customers is critical. Here are some questions you can ask.

What does it take to ship a product update or bug fix to your customers?

Sellers will tend to gloss over this question with "we add it to our product and do a release and then it gets installed."  Ninety-nine times out of 100 it's a good bit more complex than that, especially if it's an on-premise solution. Does the customer have to do a database backup before? Is the process for creating the release fully automated or does it only get built on one developer's machine? Getting them to walk you through the process helps you get a sense for how well-oiled the product machine is. And it's further compounded by...

How many versions of your product are in production and being supported today?

It's very common, particularly in smaller software companies, for the company to offer completely custom versions of its product to each customer, particularly if it's an enterprise sale. Often the justification for this approach is that the services revenue for customization is a significant part of the revenue stream for the company. Simply put, the more versions of the product the company is supporting:

- The greater the support burden

- The longer the test cycle

- The greater the bug rates in the product

- The slower you'll move on new features and updates

Extensibility 

As a searcher, you're likely interested not only in the current market that the product is serving but also adjacent opportunities. As a consequence of entering new markets, the product will have to be changed to meet the requirements of a different customer. The ability of a product to be modified (extended) and the effort required to do so is commonly called extensibility.

If you're not an engineer, it can be tough to get a straight answer on this question (and likely even if you are an engineer), but there are a few ways to at least get a sense of how things are built. Let's say for our example that the product is an e-commerce shopping cart. Common ways to modify an e-commerce platform might be to add new fields to the inventory item master (such as dimensions or weight) or to add a new payment gateway. Every product has these kinds of "core" features that you may want to modify or even swap out. Here are some questions to ask:

If I wanted to add a new "X" to the product, what's involved in that and how much time would it take?

In our example above, X would be a new payment gateway or the ability to add new fields to the inventory item master. What you want to hear is something like "we can easily add new payment gateways in a matter of weeks" or "our inventory item master can be modified by any of our customers using an API we provide."  Something that indicates they've thought about how the product might be used in ways they never considered.

What you don't want to hear is "we only support one payment provider and changing that would be a huge task" or "there is no way to modify the item master without changing the whole product." 

In addition, you don't want to hear "Hrm, don't really know, we'd have to do a bunch of research to answer that."

You might hear words like "microservices architecture" or "modular architecture" as a part of your conversation. Those can be (and often are) throw away words that don't tell you anything. 

Asking specific, exploratory questions as you're seeing a demo (like the examples above) is a great way to understand how the product works today, and how it might work tomorrow.

Hidden Costs

There's nothing more disappointing in a technology product company than beginning to grow and scale and watching marginal costs scale more quickly. Either the product doesn't actually scale without throwing tons of processing power at it, or the company has never actually audited how much a complete set of transactions costs on the system. Here are some common "gotchas" that you can look for early.

How much does it cost per "average" customer to run the application per month?

Particularly if the application is running in a Public Cloud service, it's very easy to not truly know how much it costs to support the average customer. Every single component on AWS has a meter running, and if no one's paying attention margins can quickly erode. File storage, CPU, messages, database storage. It all adds up, and more quickly than you can imagine. And, since it's often the case that hosting costs are blended both above and below the line on a P&L, true gross margin may not actually be known. 

If not in the early stages, at some point down the line in financial diligence, all of the transaction costs should be modeled in detail along with projected growth curves. What you might discover is that a current technology platform choice may become untenable at scale and require significant investment to change. 

What is your largest customer and what does the system cost to operate at peak load?

What you're trying to discover with this question is, first of all, do they know what the application is actually capable of with a "typical" installation, and do they understand which components will need to be changed to adapt to a larger load? Often times they have not done meaningful capacity testing, so if you go sell the product to a different size customer everything falls over.  In the interest of customer satisfaction, you now eat all of the costs to make things right.

Conclusion

Understanding how the product is deployed, modified and accounted for can provide critical information early in the transaction cycle to help you weed out unattractive targets. As with our People questions, these are not meant to be diligence-style questions, but rather questions you can sprinkle in to conversations with the seller as you go.  Next up we'll cover Process, the third and final leg of the technology diligence stool. Stay tuned!

Thanks for reading and please reach out with questions or comments, as well as other topics of interest to you as searchers or members of this community related to software and tech-enabled businesses.