Software Business Models

The recent announcement of the intent of Broadcom to purchase VMWare reminds me of a conversation I once had with my CEO. At the time, I worked in a business unit of a company that grew primarily through acquisitions. I was hired to be the product manager for the main product of one of these acquisitions, and prior to being hired, I did my due diligence and thought that they had a laser-like focus on expanding their document management business via targeted acquisitions, expanding their capabilities and improving the product to make it stickier for their target segments.

n.b: This whole post is in reference to B2B software business.

To be sure, there was some of that going on, but in reality, it wasn’t the prime mover. No, the principal criteria for assessing and buying a company was much more banal.

Do they have a large(ish) customer base that would find it difficult to move away from their product? And, how much annual maintenance revenue do they have?

Back then (mid to late 2000’s) the subscription model, and SaaS was in its infancy, and if you wanted to deploy an IT solution, it required you to:

• Decide that you need the solution.
• Build out infrastructure (servers, rack space, leased lines/MPLS capacity, any ancillary hardware)
• Purchase the software (licenses, shrink wrap, whatever)
• Plan the deployment (project plans, line up resources, assign a budget, do risk planning, etc)
• Execute the deployment (with staff or with an ISV or VAR)
• Train the end users
• Write it in to process documentation, and operating procedures (i.e. establish a formal workflow, and standardize it across the company)
• If there are regulatory or compliance issues, document and have them approved
• Maintain the solution (software and hardware, as well as IT staffing), including paying the annual “maintenance fees” for the software

Thus, what today might be a much less rigorous process (review the SaaS offerings in the space, pilot a couple, make a decision, and then deploy it, relying on the SaaS provider for maintenance and training, and just pay the monthly/yearly bills) it used to be a Big F-ing Deal.

All this to say that once a decision was made, and the deployment was complete, there was a HUGE incentive to live with the solution regardless of the wrinkles and warts, and to keep paying the annual maintenance fees to keep in “support”.

Back to the acquisition model

Anyhow, at the candid lunch in the canteen with our visiting CEO, he laid this out to me clearly. That they look for installed base, “satisfied1” customers, and an annual stream of maintenance revenue paid by said customers.

What he didn’t say, and that I learned the hard way, was that they acquire the companies, decimate the new customer acquisition spending (i.e. “marketing”), trim the engineering team to be little more than maintainers, and wring every last dollar from the customer base, all while using the baseline revenue to increase the corporate annual turnover. They had just hit $1B in revenues, and the CEO was talking about how his team was scouring the tech space to find $80M - $120M incremental adds to the corporation to grow the revenue.

I learned that this was a really common operating strategy that worked well in the pure software space.

An exercise to the reader is to think about why this doesn’t work for hardware companies.

What about Broadcom and VMware?

Clearly, if you look at Broadcom’s acquisition history you can see this model in action. Sure, in the way back time, Broadcom was primarily a hardware company, and they still make a lot of commodity networking chips that are used widely, they have parleyed that into a conglomeration of tech software that follows a simple pattern.

Starve new customer acquisition (cut marketing spend to the bone), identify which parts of the business generate recurring profitable revenue and keep them. Shut down or starve the unprofitable business (anything in the “innovation” space where a market doesn’t already exist for it), and apply relentless operating pressure on the remaining management team to return capital to Broadcom.

VMware will be squeezed and sucked dry. Their big bets will be shelved, their core business will get just enough to keep it going, and a lot of heads will be cut to save money.

Not a good time for them, I fear.

The Silver Lining(?)

As time goes on, the number of companies that haven’t shifted to a cloud based XaaS model shrinks, reducing the pool for acquisition that the Broadcom’s of the world can chase, and the model shrinks, having come to the end of the road.

If you are in one of these businesses, the primary focus needs to be how to get into the cloud, and to make the deployment as friction free as possible. Because what gives aircover to the above described acquisition strategy is what used to be the standard model, raise the switching costs so high as to lock in an end customer to your solution. That literally is the first thing that companies like Broadcom look for in an acquisition target.

All the things I learned in the late 1990’s and throughout the 2000’s about marketing, creating defensive barriers to switching, raising switching costs, and the like are all bad practices today. Providing customer value, ongoing “delight” and a compelling product (solving a real problem that enough people have, and that they are willing to pay for).

Ironically, it is the virtual lack of barriers to switching that protects you from this predatory conglomerating takeovers. That reduces the value of the stripped core business, and thus makes it harder to grow top line by accretive acquisition.

Coda: Being in a Business that was acquired for their customers

It sucked. We were allowed to spend just enough to keep the product alive. Fortunately our new overlords didn’t wipe out the engineering budget, but new product development was severely constrained, and we had to make do with our existing team.

It was difficult, but not impossible. We were at the cusp of cloud services, and we had a product that could be transitioned, so we were allowed to build a business case and drive that transition. I am no longer there, and really out of touch with my old colleagues, but I keep watch of what my team is doing, and they survived. That was not a guaranteed outcome.