“If you have a product fit and cultural alignment, everything else is workable” – Dixa’s Jakob Nederby Nielsen talks business acquisitions

The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.

The if…else of business acquisitions

We’re sure that you know the “if…else” statement by heart in more than one programming language. But if you’ve never applied it to the topic of acquisitions, pay attention.

An acquisition is a long journey and first. You need to ensure the organization heads in the right direction.

Jakob Nielsen believes that if you want to acquire a business, you need to confirm that:

• its mission is similar enough to one of your organization,
• its product expertise is related but different enough to complement the one of your team’s.

If the answer is “yes” to both, you can proceed with the acquisition. Else – abandon the effort. It’s not worth it.

Suppose you answered “yes” twice. Then:

• take care of the customers of the acquired business urgently,
• align your work culture and business goals gradually but with no delay,
• define the desirable outcome of the acquisition and build a roadmap to get there.

Sounds reasonable, right? But if you’ve never done it, these are just plain words.

Jakob will explain how he developed that know-how and used it in practice throughout the three acquisitions he helped finalize.

About Jakob & Dixa

How to prepare your company for new business acquisitions

Hello Jakob. Thanks for agreeing to the interview amid a busy time for Dixa. You’ve unveiled Mim, a new AI-powered chatbot, and a partnership with Ada, an AI-powered customer service platform. Dixa also got 40+ awards from G2. Congrats!

Can you tell us about Dixa’s plans for 2024?

Thanks for having me. Dixa is definitely moving towards AI. The chatbot and Ada partnership are a part of the strategy. We’re working on more AI-based features.

AI is a natural extension of our customer service platform. Dixa’s mission is to empower customer support agents. We want to make their work more efficient and easier. AI can assist them in a lot of ways, for instance, by offering smart content suggestions.

Beyond AI, we work on building strong partnerships. That’s a good way to acquire more expertise. Ada has been in the AI game for years.

Pre-acquisition

Collaboration with Ada is interesting. But in the past, you have already gone beyond partnerships and into acquisitions to expand the company’s expertise. I want to talk about it from a CTPO’s point of view.

For starters: what are the typical reasons a SaaS company acquires a business rather than develops a new feature from scratch?

Each acquisition case is different. I’ll use the example of our first acquisition of Elevio. It’s a help center that serves as a smart product knowledge hub.

It was a no-brainer for us to acquire it, because it filled a missing gap in our product portfolio. The strategy has always been about looking at our product portfolio and identifying the missing gaps. Then, we look at the market to find and assess potential strong partners to fill these gaps.

Besides, our research proved that both companies were similar. We used the same cloud provider and a comparable tech stack. Our work cultures were similar too. It was a match made in heaven.

The only downside was that Elevio was located in Melbourne. The time zone difference was 11 hours. That put stress on the team collaboration, but it was workable.

What is exactly your role in a company acquisition as a CTPO and a co-founder?

It’s mainly around deciding if it fits into our product mission. There needs to be a short-term benefit of acquiring their expertise and a long-term potential for a full merger.

A big part of it is tech due diligence, which involves validating if the to-be-acquired company’s tech is scalable enough and if any technological problems could hold us back.

Validating the culture behind the tech is also crucial.

If you don’t have a culture fit, everything is going to be hard. There are different philosophies of work and cultural differences, even within the same industry. If you have a company with a very strong cultural foundation, merging it with another one that’s equally strong but different will result in clashes.

Sounds like a lot of work. Am I right to assume that the beginning of the acquisition process is never smooth when it comes to merging the technology and culture of the two companies? 

Indeed. That’s why, if there’s a match, you should make both parties understand that even though the process is going to be long and hard, there’s a light at the end of the tunnel. Together, both organizations will be stronger, eventually.

People from all the companies that we have merged with took up leadership positions at Dixa. Many found broader and more satisfying roles than they had before. There are plenty of opportunities like this.

Overall, it’s a long journey. We’re not just trying to tap into their revenue. The struggle is about fitting the acquisition into our broad product strategy so that we have synergy.

Besides a culture fit, your company also talks about the importance of aligning the goal and mission with the ones the buyout company has. How do you verify that?

You just need to compare your mission with that of the other company.

One of Dixa’s key differentiators is that we empower customer support agents as much as possible, giving them the freedom to act. We are not building a micro-management tool. We don’t build tools that you can use to control every move of your agents. If that is the mission of our potential partner, it’s not going to work.

There’s the idea of a customer support agent sitting in a huge hall with headphones on, the bells ringing, and a big dashboard shouting how many customers wait in line. That is not the experience we want to represent. We need a partner who shares our vision and may contribute something valuable to it.

What about their metrics? Some companies that look for a merger may be inclined to spice up their product- and tech-related achievements a little. 

Our commercial due diligence covers that. As for the tech side, there are some fairly objective matters to explore.

You could verify how many customers they can onboard. Then, check out their load testing as well as penetration testing and compliance policies.

This is on the checklist we go through with every acquisition. That way, we ensure that there are no bottlenecks. If we are to load our entire customer base onto a new platform, we need certainty it can scale to match our requirements. If it can’t, we need to estimate the effort it would take to change that.

We go through all that high-level stuff, but we also introduce some of our tech people to their engineers to figure out what the numbers will look like in the future. We ask: “Let’s say we have a customer with 1000 agents going online next week. What is your game plan? “

Whether the numbers are good or not, the buyer will have to integrate the purchased product’s code into their architecture, eventually. What are the steps an IT department can take to prepare for that in advance?

The partnership phase is the best time to figure out these steps.

In this phase, we discuss potential product integrations between the two platforms. There are many challenges to overcome. One of the biggest ones is simply the fact that both products already have many existing and overlapping integrations with different platforms.

Things are easier if both parties have the same cloud provider and use industry standards such as Docker images, infrastructure-as-code software, or Kubernetes. We can integrate these into our infrastructure fairly easily.

When you gather all the tech stack information needed, you can create an integration plan. It should include infrastructure issues as well as tooling, like incident & downtime management, and customer reporting. You should also merge status pages so they are the same. Make sure to sync the development of your stacks, too.

Is technology ever a major obstacle for an acquisition? Or, if the product is a good fit, will the buyers always find a way to make it work?

I wouldn’t say that it could be a dealbreaker.

We have worked on a platform that had some architectural issues. We worked them out, but it required effort. In particular, changing the cloud provider is not an easy thing. You can’t do it overnight.

You can make it easier by using Docker or something else like that. Still, each cloud provider offers many solutions that are similar to each other but not quite the same. You will spend some time migrating the code and polishing it.

At the end of the day, it is about stacking the effort against the value that you can potentially gain.

Changes in the architecture may become a part of the road mapping effort. How early does the roadmap for an acquisition begin for technical and product-related aspects?

First, you need to respect the fact that the company you want to merge with has its independent roadmap, customers, requests, and obligations. Typically, the partnership involves a stage at which nothing changes other than the gradual merging of cultures.

We have never completely shut down an aged, acquired platform, because there are still customers that use it. Our effort has always been to create a better product with the same people.

But in about half a year since the merger, depending on the case, you start to create a more synergized roadmap. We want both parties to go in the same direction and figure out what features we need to align. To figure this out, a technology manager might try a thought experiment: ask what you would do if you could build a new platform from scratch. 

There is a need to create at least two strategies. One for the acquired platform and a second one for the future “main” platform that will remain long-term. Ask yourself what percentage of the customers can move to the “main” platform when/if you have the x feature parity. 

The effort vs. expected value always has to make sense when doing this.

I am interested in how you overcome the doubts and fears of the customers of the soon-to-be-acquired company. They may be afraid their favorite product won’t be the same or even mistrust the new owner. What’s your experience here?

It’s important to be very proactive.

As soon as the announcement is made, reach out to the customers of the acquired company. Share with them what happened and what the long-term plan is.

If the acquisition plan involves a complete merger of the platforms, don’t hide the information. You should tell the customers why the change will be good for them. Show them the benefits, such as new potential integrations and capabilities they can get.

We would never acquire a product that doesn’t naturally belong in our product suite. The acquisitions we made always filled out gaps in our portfolio. That made things easier. The customer gained new features that complement the existing ones they use.

What kind of features does Dixa offer exactly? Watch the video and discover how Dixa empowers agents to provide personalized customer service experience.

Acquisition

What is the role of a CTPO in the formal execution of the acquisition? 

I’m always part of the acquisition team to cover the tech aspects of it.

That includes assessing the potential of the tech and talking with the founders and leadership.

I also cover alignment, that is, how we can work today with a view that a merger may happen in the future. That’s the beginning of the roadmap I mentioned.

There’s a lot of talking to be done. You need to talk to the new people, making sure that you are on the same page.

The market situation is outside of my domain. Others analyze that. But as part of that process, I need to ensure we will be capable of producing software for our shared product-market fit as a merged product-engineering department.

Let’s talk about the changes a new acquisition brings to an organization. What is your experience with integrating the buyout company’s teams with yours?

Getting the news from your CEO that you have been acquired has the potential to paralyze your everyday work. Like I said, you need to have respect for the culture, and it’s the people who create culture.

The first half of the year should be fairly quiet. Assure employees that next week, when they come to work, everything will be mostly the same. But at the same time, start talking about how you create standardization across your platforms.

When you have the standardization, you can slowly move towards stage two of finding the synergy. Let’s look at one of our examples.

In the past, Dixa acquired Miuros – a data-heavy company. They had a product for advanced analytics. They also had a QA tool for customer support agents. Their analytics team was analogical to our insights team. They were downstream teams, which means that they took data from other teams and converted it to present it with the analytics tool. Combining them made a lot of sense. 

Miuros’ team was strong in business analysis. And ours had a strong understanding of Dixa’s core. They got together to create integration ideas by using their expertise from both ends. That’s how you create the synergy.

And as soon as you have that synergy, you can try merging the two teams.

On a different note, this process of integration is also about people getting to know each other. The best way to do it is to organize a get-together on-site. I missed the opportunity to do this during COVID.

When you meet up, try to do something fun. Go out for dinner, or to a bowling alley, or do some team activities. It’s a lot easier to communicate when you write and talk to an actual person you met rather than just their icon on Slack or a talking head you see on a Zoom call.

What about the processes that drive your development or deployment? How much can a new acquisition change them? 

Most companies that we have talked to follow some industry standard of software development. It’s some kind of Agile methodology that includes planning, a standup, and a retrospective.

So we have a lot in common. But there are these micro-differences. Sprint duration differs. One company has a standup at 9:00 in the morning, the other at 11:00. Such differences certainly aren’t dealbreakers. They can be worked out over time.

It must be even worse when the time difference is 11 hours like in the case of the Melbourne-based Elevio.

This is also interesting because we decided to keep Elevio as a satellite. We align on a strategic level, but they have full operational autonomy. They decide how they want to work.

At Dixa, we always believed in giving autonomy to our product and engineering teams. They sit with the product team every day. They can see their  product domain full potential. So, they also have special insights and unique cultures. Whether they decide to do a stand-up at 9 or 11 am, I don’t care. The same goes for their project methodology. The key goal is only whether we deliver quality on a regular basis.

It seems though that in general, the parent-company transforms the smaller one more than in the opposite case. But perhaps the smaller buyout company can also influence the parent in terms of work culture. What did you learn from your managerial experience?

It’s now always the case that the parent company enforces standards onto the acquired one.

We fill out a major expertise gap just by acquiring a highly specialized company. But we also gain highly talented individuals.

Some of the people from the buyout company know how to run processes we haven’t introduced yet. If we decide to add features they worked on before to our platform, they will be the ones to manage and champion them at our organization. They know exactly what to do. 

We need to be ready for constant change and to hear other people’s ideas. That’s essential for getting better. If you have this attitude, there’s a lot of knowledge to receive by going through an acquisition.

We talked about architecture before. After the merger, when you want to integrate the new product into the ones the company owns, what are the biggest challenges of taking over the code?

There are some major obstacles.

For example, if your engineering team uses functional programming, but the acquired team focuses on class-based programming, it will be difficult to integrate the new folks. That would call for a change of the entire programming paradigm for one of the groups. The skillset is very different.

Still, it’s not a dealbreaker.

Alternatively, you can create independent services that can communicate using a common API layer. Then, you can have multiple independent teams working on the same product. 

There are all kinds of possibilities and workarounds when it comes to integrating independent codebases or teams. But you need certainty that these hot fixes don’t end up driving your architectural direction. Alternatively, each acquisition will be yet another cause of chaos and technical debt. If you have the best long-term interest of your company in mind, determine your base technologies, frameworks, or architecture, and try to fit the acquired product into them.

Speaking of technical debt, what about the buyout company’s legacy solutions?

The thing about technical debt is that you properly generate some more when you touch your code.

Debt is a natural side effect of product development that comes from the pressure of deadlines.

But if you want to continue to build and expand on your foundation, you need to invest in fixing it, too.

The tech due diligence done during the acquisition process aims to assess the amount of technical debt and the effort it will take to get it under control. A big part of the process is simply asking the right questions such as: “Suppose we wanted to extend this feature, what obstacles or limitations would we encounter?”.

When it comes to learning about technical debt, an open discussion must take place. As for the actual debt removal, it’s all about priority and value vs. efforts. 

Security issues are another type of inherited debt that comes with a company acquisition. How do you address such?

Penetration tests are a good way of assessing the security of the purchased software. 

You can perform them or ask the buyout company’s team to do it. Alternatively, you can contract a third party to do it for you. There are a lot of options. Depending on the case, the pen tests can focus on either the API layer, the application layer, or both.

Post-acquisition

A CTO/CTPO who has never overseen an acquisition may wonder what the first days or weeks are like. How much time does it take to return to business as usual?

In the beginning, the changes are light. The two organizations need to get to know each other. Work normalizes when you reach an alignment and sort out cultural issues.

I already talked about technological alignment. As for day-to-day work, I recommend that you map out expectations of how you want everyone to work. To that end, run workshops during which the new folks will work together with your core team. Regardless of the particulars of how you run such meetings, start by gathering plenty of knowledge about all the differences you want to resolve. I already explained how to find such information. But to recap – the partnership period before the acquisition is the best time to do it. You can also take part in the buyout company’s retrospectives to get insights.

As for culture, eventually, your core team and the newcoming team are going to unify. Before that happens, the culture of the parent company plays a key role. If it’s forgiving and understanding, everything will go smoother, and new teammates will be outspoken and proactive in resolving issues. If that established culture is toxic and accusatory, newcomers will stay quiet. You will struggle to maximize collaboration and you won’t even know why.

There are different ways in which a newly-bought product can be integrated. In the case of Solvemate and Miuros, Dixa integrated their products completely. But in the case of Elevio, it seems that their software was adopted in full by Dixa but it’s also available as a separate product. Why is that?

It’s about market positioning. if the to-be-bought software competes with what the parent company has, it doesn’t make sense to keep it as a separate product.

Elevio happens to have an Ideal Customer Profile different enough from Dixa to stand on its own.

What’s more, Elevio is an entirely self-managed platform. You can sign up yourself and add your credit cards. The operational cost was a problem, but we invested in their backend and infrastructure. That spending included a migration into our AWS cloud to keep the running costs lower.

General advice

A lot of the tactics we talked about so far are quite situational or can work for a SaaS company. Let’s try to generalize them. If you were to provide advice about business acquisitions in IT that could be useful to anyone, what would it be?

In terms of the product fit, try to find something that could complement your owned product, so that the new software fills out a gap in your portfolio of services. If you identify a gap, and the potential acquisition fits it, the merger is a win-win for both parties.

Then, it’s about the alignment of working styles as well as of the cultures. You should work on finding synergy between two teams from the partnership stage to the merger and beyond.

Technological differences can be obstacles, but they are rarely a deal breaker if the product fit is there. If so, there’s always some potential for alignment. Just make sure to fit the purchased product into your long-term technological strategy.

Resources

When it comes to business acquisitions, you sound like a true practitioner. And perhaps there are some books or other materials that helped you expand your expertise?

I am most definitely a practitioner. It’s hard to learn about the acquisition process by reading a book. This is something you need to experience. I was part of such a process three times. Each time, I learned a whole lot. I tried my best to give you some kind of idea of how it looks on the inside.

However, I can recommend a book that tackles a lot of the issues more generally. It allowed me to polish the managerial skills that I used when I welcomed the buyout company’s teams to the wider Dixa organization.

It’s called The Manager’s Path. It explains why one-on-ones are such a good idea and how to perform them. It discusses the importance of the cultural aspect in product development. It also has some great insights into cross-functional teams.

It guided me from my days as a developer, through being a tech lead, manager, and the manager of managers, all the way to the C-level.

What’s next? The three alignments

Is there a business acquisition on the horizon for your company? If you ensured that the business is the right fit, and the potentials hardships didn’t put you off the idea, follow Jakob’s advice on alignment:

1. Align objectives

The partnership period that often precedes acquisition is the best time to work out the objectives. At first, the two companies have their own routes. But as you observe the potential for synergies on the team and individual levels, you will see common ground.

2. Align technology

Focus on long-term success. Short-term workarounds may produce tons of technical debt if taken to an extreme. Define how toe two merger products should function in a perfect scenario. Then, work your way towards it.

3. Align culture

Cultural differences between organizations are to be expected. How you will smooth them out depends on the culture of the parent company that leads the acquisition. After an acquisition you will end with a new company culture. It is important that you focus on this aspect pre- and post-acquisition. I would put most of the focus on cultural alignment as early as possible. 

If you can do all that, everything else will sort itself out!