M&A Best Practices

Getting into M&A 

For us, we've grown organically a lot. We're always evaluating if there are problems within the business that we could solve faster by making an acquisition. We've done three acquisitions and learned a lot with some great wins and some painful experiences along the way. We will continue to do M&A. 

Our first deal happened when we founded the company in 2011, and our first acquisition was around 2015. We've done a couple more product acquisitions since then. They've been really helpful to our business, but they don't always go as planned. In fact, they usually go very differently than expected.

Driving first deals

The first one we did was our largest acquisition. We aimed to acquire a competitor to scale more quickly. A significant part of our growth was our ability to acquire small business customers. We wanted to find competitors that had unique ways of acquiring customers, different from our methods.

Long Island is a hub for lending marketplaces and brokers. I began evaluating and meeting with every potential competitor. I visited about 10 or 15 different organizations. Some of them weren't the right fit from the moment I walked in. Some felt shady, completely opposite of what we were aiming for. 

However, I came across one of the largest players in the space and connected with the CEO immediately.The positive atmosphere and energy indicated a strong focus on employee value and culture. Building a relationship quickly, we realized it was a potential match and acquired the business, named Business Bounce.

Acquiring a company provided valuable insights. The founder-CEO stayed with us for a couple of years, benefiting our business. However, differences in growth, culture, and business practices led to a separation plan. This taught us about our team dynamics, especially transitioning from Salt Lake City, Utah, to Long Island, New York.

Initially, they didn't trust me as a leader. During our first interactions, there was skepticism. The only way to build trust was to outline our vision, benefits, and then ensure our actions matched our promises. 

We faced challenges during the acquisition, especially with buy-in. They felt like outsiders because we came in through acquisition. It took a lot of effort to build the relationship and integrate successfully. It was a valuable learning experience.

Second acquisition

For our second acquisition, one thing we've learned is that acquisitions are more likely to work if you clearly define the problem you're trying to solve. Then, determine how the acquisition will specifically address that problem, rather than just acquiring a company in hopes it will be beneficial.

We had the idea to acquire a bookkeeping solution technology. It didn't have any revenue or customers, but the technology seemed promising. We believed that with our expertise in customer acquisition and sales and marketing, we could leverage this technology. 

As a lending marketplace, we thought we could cross-sell bookkeeping services to customers seeking loans and vice versa. Additionally, having access to a business owner's financial data and building a relationship over time seemed advantageous.

We acquired the technology before the pandemic but soon discovered it wasn't as robust as we thought. While it demoed well, integrating and understanding its workings proved more challenging than expected. It took us about eight months to even begin marketing the product due to code and integration challenges, revealing it wasn't what we anticipated.

We tried executing our hypothesis of cross-selling and integration, but managing two distinct businesses proved challenging. The core business was a marketplace, while the second was a monthly SaaS subscription focusing on bookkeeping and cash flow management. Operating both simultaneously spread our resources thin.

It's challenging enough to get one business right, let alone two. After about six to 12 months, we decided to shut down the second business. We've since incorporated some of its technology and concepts in different ways, but our initial hypothesis about bookkeeping and cash flow management didn't materialize as expected.

Third acquisition

In our third acquisition, we decided early in the diligence process not to include the CEO in the merged operation, a difficult choice. We were purchasing the technology from bankruptcy, and the team had been operating with limited resources, sometimes without salaries, for six to 12 months. 

Regardless of the challenges, we saw value and potential in the technology. However, We didn't align with the CEO, so we informed him early on. Many key team members found other opportunities late in the process. 

Despite expecting to acquire a robust team and technology, we retained only about three or four members. One was exceptionally knowledgeable, but most key colleagues, engineers, and developers secured other jobs before the deal closed.

We felt we negotiated a good deal, but post-acquisition, we became highly dependent on this one individual. The code base was in a different language than what we typically use. We did thorough diligence on the technology and recognized its uniqueness. However, the challenge of working with two code bases and integrating them, coupled with our reliance on one senior architect, prolonged our time to market.

We acquired the technology from bankruptcy, securing a favorable deal, but our initial expectations didn't fully materialize. We're still addressing the problem we bought it for, but through a different platform. We're re-platforming the unique aspects of the technology. 

Many acquisitions don't unfold as expected, and it's challenging to anticipate these complexities until deep into operating the business.

Understanding the cultural aspect of M&A 

Many might believe that thorough diligence could have prevented challenges. However, timing is critical in deals. Both the seller and buyer have their motivations, and sometimes there's a push to finalize quickly. 

Balancing speed with thorough diligence is challenging. Sellers often present their best side during deals. A CEO might not want their team to know about a potential sale, so they might not grant full access to all team members until the deal is finalized. This is quite standard.

While you can examine the technology and code base in detail and envision how systems might integrate, the practical experience of merging them can differ significantly from the theoretical understanding. 

The more diligence you do, the better. But there’s a lot you won’t find out during diligence until you actually get the deal done. No matter how thorough you are, there's always an element of uncertainty until the acquisition is finalized.

Certainly, culture is a significant aspect. While the senior leadership team's philosophies about culture might align, there can be discrepancies in perception at different levels of the organization. What do team members at the ground level believe? How do they interact when they become coworkers? 

The nuances of daily operations might not surface during discussions about values and cultural priorities. You can ask all the right questions about culture, but you won't truly understand until the teams merge. There's inherent risk in any deal.

When it comes to technology, I doubt I'll ever engage in a deal again where the code bases aren't compatible. Some believe that the coding language doesn't matter, that you can merge .NET with PHP or Java seamlessly. 

However, with 80 engineers on our team proficient in PHP, Java, and SQL, integrating .NET becomes a challenge. If I want a swift integration, say in three weeks, it's not feasible. You'd need to hire a different kind of engineer or invest in cross-training. 

We've encountered hurdles that hinder the process. Initial excitement wanes when there's a lack of expertise to work on or integrate the new code, as seen in our third acquisition. While we had a strong senior architect, integrating required hiring .NET specialists, causing a bottleneck in execution.

My learning is, we had our top engineers examining the code base during diligence. We were aware it was in .NET; it wasn't a surprise. When you inspect the architecture, it appears well-structured, and the code base seems clean. However, that perception changes when you begin to work with it. 

People are optimistic about integration, thinking teams can easily connect through APIs, but the reality on the software side can be different. Of course, not all companies doing acquisitions are trying to integrate software, so this might not apply to everyone.

Best way to approach deals

For now, some of the learnings we've had is how we approach the deal. So we approach it this way now:

1. What's the problem we're trying to solve? - Is this a made-up problem or is it a predefined problem within the organization that exists? 

2. Is there a good culture fit with the leadership team? - Can the acquiring team envision working with the target leadership and employees?

3. What are all the reasons not to do this deal? - Based on the list of all the reasons to do the deal, create the diligence list to validate the thesis and assumptions. 

From a culture standpoint, from a cash or financial standpoint, let's list every single possible reason why the deal will go bad. And if we go through all of those sincerely, and then we still feel, even with all those risks, that it makes sense, then we'll continue to pursue and get into deal negotiation. 

Our goal is to put it together and make sense. Then we open up a 60 to 90 day diligence period and try to be methodical. Based on all the reasons we shouldn't do the deal, we create our diligence list and go validate all those assumptions. So my approach in a deal now is quite different from my previous approaches.

You tell yourself, this is perfect for reasons X, Y, and Z. And listen, if I can have one person get through this process and have a really successful deal out of it, this would be a great way.

Part of our approach involves assessing culture and technology fit, as well as customer compatibility, depending on the acquisition type. We hypothesize that customers will transition to our tech platform.Is there a way to validate that? What would be the reasons they wouldn't transition? 

If you're essentially acquiring additional customers and you're uncertain about their transition, you'll want to spend time during diligence trying to validate that.

Strategizing acquisitions

The question I would start with is: What feature or service keeps customers with the current provider? If the technology is outdated, why haven't they switched earlier? Is it apathy, or is there a small but significant feature they value?

It's about understanding why these customers are staying with this product and validating that if I make this acquisition, they will come to our product and not just cancel and move to someone else's. Sometimes we assume our product is better and they'll naturally transition, but it's crucial to consider potential pitfalls and reasons they might not.

Validating assumptions before acquisition commitment

Using the different phases of the process to your advantage is key. Pre-LOI, with a willing seller, you have leverage as they strive to present their best. Post-LOI, during negotiation and diligence, you delve deeper into details.

For deal enthusiasts, once an LOI is in place, there's a tendency to become emotionally invested in the deal. You see its potential to solve problems and naturally want to move forward quickly. However, it's essential to remain disciplined and leverage these time periods to gather all necessary information.

Some companies are more opportunistic and it's not like I'm actively searching. I've met a CEO and found their proposition interesting for a problem we're trying to solve. On the other hand, like our first acquisition, we clearly defined what we wanted. 

We met with 10 or 15 companies and selected the one that was the best fit. So, whether it's stumbling upon an opportunity or having a clear strategy to acquire multiple companies and scouring the market methodically, there are different approaches.

I always map out my vision before reaching an LOI. I aim to get them excited about the idea that one plus one equals three. The LOI typically includes some upfront cash, seller financing paid over time, and an earn-out. 

Earnouts are designed to keep key team members invested in the combined success of the merged organization. They're aligned with the vision and understand our goals. If they help move things forward quickly, they'll be rewarded well. 

Some might hope not to pay out an earn-out, but if you do and it's structured correctly, this is a win-win because if the acquiring company is paying an earnout, it means they have accomplished the entire deal rationale. 

For me, the deal structure is all about creating alignment between the two companies to maximize the chance of success.

So I always approach a deal considering both upfront and ongoing cash. For instance, in a hypothetical million-dollar deal, I might negotiate $250,000 upfront and then distribute the remaining $750,000 over the next three years, paying $250,000 annually. I also often incorporate equity into the deal, preferably allocated to those individuals we plan to retain. 

Additionally, I include an earn-out to align retained individuals with our success. This earn-out ensures alignment. In a $3 million deal, payments occur upfront, over three years, in equity, and performance-based on earnings, leveraging multiple levers.

Budget allocation for an earnout

For instance, if it's a $3 million deal. You might have a million in cash, split between upfront and over time, a million in equity, and then a million in earnout. This earnout is paid out over time based on performance milestones and integration milestones. Depending on the situation, you can adjust these numbers. 

For our company, which is growing quickly and potentially on a path to going public someday, some people might prefer more equity over immediate cash. But these are just levers you can pull during negotiations. I once lost out on a deal because we didn't want to give equity; we wanted it to be all cash. 

My point is, you have a lot of different tools in your toolbox. It doesn't have to be just cash. When I issue the LOI, I specify it's a $3 million deal, broken up like this. So the seller feels they're selling their business for $3 million, even though it's not $3 million cash upfront.

I always want to engage with the CEO or the relevant person to understand their motivation and what's crucial for them. While many might emphasize cash, I usually explain our typical deal structure. 

I aim to grasp their perspective on valuation first. Rather than negotiating immediately during a call, I prefer to understand their viewpoint, then draft an LOI proposal that appeals to both parties.  I submit that, let them digest it, and then we discuss and negotiate as needed.

You can raise debt capital or other capital to finance a deal. However, if you can use seller financing, there's significant upside. It's lower risk. If you raise money from a debtor or investor, you're introducing a new partner, which comes with bank covenants and other obligations. 

While I wouldn't intentionally default, if the deal goes south and you haven't paid it off, there's less recourse. Seller financing also indicates that the seller has skin in the game. In my view, there are many benefits to having the seller carry some of the financing.