The Problem of Bolt-On Acquisitions in a Digital World

I was at a startup that got acquired. At MyEdu, we had developed a college student profile product, and Blackboard—one of the largest educational software companies in the world—purchased our company to supplement their existing product portfolio with this rich new capability. With the profile, students using Blackboard's software could present themselves to their classmates, teachers, and to prospective employers.

There are all sorts of good reasons for one company to acquire another. It might be an earnings boost, where the post-acquisition company continues to operate independently while increasing the value of the parent company. It might be to take a competitor out of action—buy a company and then shut it down. It might be to buy talent. It might be to optimize the tax implications of new development. Or it might be to accelerate product development (and build out a richer product portfolio) by buying product capabilities across the market value chain.

Companies often see these capabilities as additive, that they can be "bolted-on" to current offerings to enhance the customer value proposition. What almost always gets underestimated, though—and often overlooked altogether—during due diligence is the actual integration of the new capabilities and how (or whether) it will work. This process has become doubly important in a digital world of seamless customer experience.

For example, if you run an educational software provider, you might think about your educational value chain as including Discovery and Enrollment, Financial Aid and Payment, Teaching & Learning, Academic & Career Advising, and Alumni Services. As you look internally at your own product and service offerings, you can identify where you excel and where you are lacking. If you are lacking in, say, Academic & Career Advising, you could go shopping for companies that excel in those areas. When you find one you like, it seems easy enough: do your due diligence, buy it, and now you "have" that capability in your product portfolio. That means that—on PowerPoints, on websites, and in the way you describe your products to the market—you can say that your company Does That Thing.

But having the capability doesn't automatically deliver the value of the capability, because it doesn't recognize the interrelated aspects of experiencing the capability.

A student doesn't first experience enrollment, and then experience financial aid, and then individually and sequentially experience teaching & learning, academic & career advising, and alumni services. They experience college, which weaves and twists between phases organically. The academic journey is not linear—it's a mess. If that mess is to be supported by products and services, those products and services need to be intertwined in workflows that match human expectations and mirror human interactions.

Value comes from experience, and experience doesn't happen in isolation on the value chain; it happens across the chain. You can't just bolt new features on to your existing products and expect your customers to have positive experiences. At its best, the edges of the bolt-on will show; the transition from one to the other will be apparent, crude, and disruptive. At its worst, your customers will give up in frustration and go somewhere else.

The customer experience "edges" of a poorly integrated product acquisition look and feel similar to when you, as a consumer, have to deal with different business units in a large company. At an airline, one group handles reservations, another is in charge of the website, another handles your miles, and yet another is responsible for customer complaints. But the customer doesn't differentiate between these things; they are all "flying." These edges appear when artificial business constructs are dropped on top of human experience. Organizational structure is an artificial construct, and so is the value chain.

The bolt-on approach to product capabilities is mirrored by the bolt-on approach to a new team. For example, a simplistic way of thinking about an "aquihire" is that, if your company acquires a startup with developers that know Jenkins, chef, and cloud technology, then you've gained knowledge and development capability around Jenkins, chef and cloud technology. MyEdu was made up of developers, designers and product managers, and after acquisition, we all worked for Blackboard. It's reasonable to expect that our knowledge would pervade the acquiring company.

But, like bolting on capabilities, bolt-on talent doesn't work, either. Simply "having" developers that know Jenkins doesn't instill any institutional knowledge about that technology. The skills need to be integrated into the larger ecosystem of developers, and the processes to support those development activities need to change. The language or system alone often changes the way people think about product development, and so the entire structure of the teams and the organization may need to adjust to support it. The same is true for design; "having designers" doesn't mean that the company is going to be doing great design work. The competency needs more than just people; it needs to be managed, and integrated.

Perhaps worst of all is attempting to bolt-on culture—buying a company in order to buy a "way of working." At MyEdu, for better or for worse, we had all of the silly startup icons: ping-pong, bean bags, and Xbox. Less obvious, but more importantly, we had flexibility, speed, and control. Most startups operate this way, both by necessity (scarce resources) and because it's the culture that entrepreneurs generally thrive in. You can imagine what would happen if this culture ran head-first into its opposite. The startup culture doesn't infect the larger corporation—the larger corporation eats the startup.

These bolt-on problems happen when acquisition strategy is conceived of separately from post-acquisition tactics and process. It's tempting to push off the operational plan for the acquisition—"we'll figure it out later." But the plan itself may actually change the strategy. By working through the how will it work scenarios, you might realize that it's actually not a great idea to go buy that company, because when you dig into it, there's no great way to integrate it cohesively into your tech stack, or into the product experience, or into your company culture.

Current approaches to due diligence typically investigate and validate the objective claims the startup has made. In a world where more and more products and services are software-based, speeding up operations and adding nuance to customer experience, the process needs to evolve to model the challenges of integrating capabilities, technology, and people. That means actually doing the design work to show the integrated product experience, and developing the integrated technology architecture, and planning an organizational structure that will work to uphold the company culture. Doing these things before completing the deal will significantly increase the likelihood of long-term success.