Mergers and Acquisitions Project and Product Onboarding: Oracle
My Role
In my position as a SaaS Product Manager, I was tasked to lead a PM team in developing a merger and acquisition playbook specific four our line of business. This would include planning, scheduling and execution of post-merger/acquisition activities to onboard both product and employees and integrate them into Oracle effectively while adhering to a strict timeline that would allow us to maximize ROI.
Creating the Framework
There were six main areas that I determined would need to be addressed:
1. Organizational Structuring and Processing
2. Financial Considerations
3. Product Strategy and Integration
4. Sales and Marketing Considerations/rebranding
5. Locational Logistics
6. Cultural Mesh
Initial Assumptions
While there are a multitude of acquired companies throughout the world each year, two things initially stood out to me: Firstly, I must take into account the sensitivity of the company being acquired. There is going to be a large period of time over the first 30-60 days where two cultures are merging, and communication is of the utmost importance.
Secondly, a one-size-fits-all approach is not likely going to work, given that the size of the product, its employees and users are going to vary widely. It’s going to be much different integrating a smaller sized company where we would be working with 20-30 employees vs. a few hundred team members.
Questions
- How could we structure a unified communications team that would handle critical communications for things such as manager changes, permissions, structure, and cultural mesh?
- What would a general framework look like that we could expand upon as needed to address the size and scope of any given merger/acquisition?
Next Steps
With a general framework in mind as a starting point, I began by creating a rough timeline that would that would provide a roadmap with broad milestones and address the questions posed above. I was able to pull inspiration from past acquisition activities, as well as a number of fairly detailed linear graphs that could incorporate the timeline that I desired. I settled on the below as a starting point.
Now that I had a plan, I could begin working through with our first case that would allow me to measure exactly how successful this could be.
Initial Run
Using the plan outlined above, I began to work onboarding the first case, an acquired company whose product team would be working directly into ours. Along the way, this plan allowed us to address a few major issues that cropped up:
Culture merge – with an understanding that post-M&A deal would require sensitive handling, I was able to gain critical insight via meet and greets, general communications, and discussing with employees what they thought was going well, what can be improved, and their input. It was crucial for me to gain this information about the merging company’s culture. For example, as a smaller team they were entrepreneurial in nature vs. ours being a much more corporate environment. It was up to me to determine how these groups can be meshed and merged effectively.
Training, permissions and cross platform training – onboarding the acquired company to ours occurring while also introducing the acquired company and product to the existing line of business proved to be an excellent opportunity to familiarize everyone.
Working within structure – how was the current workload handled? In one instance, it was discovered the acquired company was working their support and defect tickets in a open queue without prioritization. Two concerns brought up through employee conversations were that it was taking additional time to locate and assign specific tickets to the proper SMEs, and that there was a lack of communication in high priority/critical issues, which in turn were being escalated for attention to executive management
Hypothesis 1:
By not having a method to drill down and sort support and defect tickets, it was taking time away by needing to sort these out on a regular basis.
Proposed solution: provide a drill down into the specific product area to assign where the issue is occurring, then by creating a silo/queue specific to the product area we can assign team members and SMEs based on their skill. Finally, create a method to skill engineers in assigning them to queues in a silo. This would eliminate the need to manually perform sorting incoming new tickets as this can be done upon creation by the customer for support issues or internally for defect tickets
Hypothesis 2:
By not utilizing a structured system to properly prioritize items, unnecessary escalations were occurring.
Solution proposal: assign a numeric value to a given ticket to prioritize within a given queue – 1 outage, 2 critical, 3 small impact. These values can be assigned as described above, either on the customer end or internally.
Next Steps
Results
Conclusion
Jared Ewert 