When I first joined a project whose core business model revolved around acquiring and operating multiple companies, I expected complexity. But what I walked into was far more than that. It was a living, breathing puzzle where every piece had its shape, history, and pace.
From onboarding processes that felt like assembling IKEA furniture without the manual, to managing inter-company communication across time zones and cultures, to writing Product Requirements Documents (PRDs) while the ground shifted beneath my feet, every day brought new challenges, but also unmatched learning opportunities.
If you are about to step into a similar role, or are simply curious about how product management operates in a constantly evolving, multi-company ecosystem, this playbook will help you navigate the chaos with confidence.
The Landscape: A Web of Companies, Cultures, and Challenges
In a single-company environment, the product manager’s focus is typically on one product, one set of stakeholders, and one organizational culture. Now multiply that by nine separate companies. Each with its legacy systems, ways of working, and priorities.
Every acquisition brings a new ecosystem to decode:
- Diverse tech stacks: Sometimes modern and agile, other times old enough to remember Windows XP.
- Inconsistent communication protocols: Slack in one place, email threads in another, and sometimes even in internal company communication tools.
- Varied levels of product maturity: From MVP-stage startups to companies with deeply entrenched enterprise processes.
- Different organizational cultures: What works as a norm in one team might be taboo in another.
- Fragmented customer bases: Each expecting their own style of engagement and delivery.
And yes, nine companies meant nine separate Slack workspaces to monitor. Every morning felt like flipping through nine parallel newspapers, each with its own breaking headlines.
Conversations, decisions, and crises were happening simultaneously in different corners of this digital sprawl, and keeping track meant not just reading messages but knowing which conversations truly mattered.
In this environment, understanding the ecosystem is not just the first step. It’s the foundation upon which every other decision rests.
Onboarding in the Unknown: Building from Ground Zero
Joining a multi-acquisition project often feels like walking into a library where all the books are scattered across the floor and in three different languages. There is rarely a centralized onboarding playbook. You are not just onboarding yourself. You are creating the very process that future hires will stand on.
In my case, this became even more real when a new PM joined the team just a few weeks after I did. I still had more questions than answers, but I realized that helping them navigate the maze would also sharpen my understanding.
We turned onboarding into a co-pilot experience:
- We scheduled walkthrough calls where I explained not just what a process was, but why it worked that way in our multi-acquisition context.
- We co-created a sort of “New PM Survival Guide”, noting down everything from which Slack channels are active to who the unofficial “go-to” people were in each acquired company.
- We tackled one mystery at a time. One day mapping stakeholder networks, another day untangling a tech stack that looked like it belonged in a museum.
By the end of their first month, the two of us had built a living knowledge base so robust that it became the de facto onboarding guide for anyone new to the project.
💡 Helping someone else onboard while you’re onboarding yourself is like explaining a puzzle while you’re still solving it. It forces yoy to clarify your understanding faster than you ever could alone.
Communication: The Tightrope Walk Between Chaos and Clarity
When managing across multiple acquired companies, communication becomes both your biggest risk and your strongest weapon.
Challenges I faced:
- Teams working in silos, completely unaware that parallel projects were underway.
- Misaligned expectations due to differences in decision-making styles and urgency.
- Hidden dependencies that only became visible when it was too late.
What helped?
- Establish a single source of truth: Whether it’s Notion, Confluence, or a rigorously managed Google Drive, make it the go-to hub for information.
- Run regular syncs: Monthly across leadership, weekly for active, high-priority projects.
- Ask the right questions from the right people: General Managers often had the business context, while engineers held the ground-level truth about feasibility and constraints. Pairing their insights revealed the real picture behind a project’s status.
- Define communication protocols early: Specify what belongs in chat tools, what needs documentation, and what requires a formal email.
The PRD Struggle: Writing Requirements in a Moving Train
Crafting a Product Requirements Document in this environment can feel like drafting a blueprint while the building is being renovated, and half the team is moving offices.
Lessons learned:
- Start with the “why”: Make sure everyone aligns on the problem before rushing to solutions.
- Modularize your PRDs: Different teams might need different formats, so create reusable sections.
- Document your assumptions: Many will be wrong, but having them written down makes it easier to adjust later.
Dealing with Uncertainty: The PM Superpower
If there is one skill that defines a PM in a multi-acquisition environment, it’s thriving in uncertainty.
Here, change is constant, and ambiguity is the air you breathe.
In some companies, there was little to no information at all to move forward. No documentation, no project history, and sometimes not even clarity on who owned a particular function.
Those moments were both daunting and defining. I learned to piece together clues from conversations, old emails, and even code repositories to figure out the current state before making a plan.
How to thrive?
- Stay curious: Even “obvious” questions can reveal critical context.
- Bias for structure: Implement small but scalable processes like standardized project kickoffs or decision logs.
- Overcommunicate thoughtfully: Recap meetings, clarify who’s doing what, and keep a visible trail of decisions.
Lessons Learned & Closing Thoughts
This is where grit meets opportunity.
It’s dynamic, ambiguous, and layered. But it’s also a playground for growth.
Some of the important lessons that I learnt during this process are:
1. Slack archaeology is a great skill
Looking through old Slack messages can be surprisingly useful. Once, I was confused about why a certain product decision had been made. It didn’t seem to match what I was hearing in recent discussions.
So I dug through about two months of messages in one company workspace and stumbled upon an old internal thread where people had been debating the pros and cons of a feature. Reading that back-and-forth gave me the full context I’d been missing, and suddenly, the decision made complete sense.
2. Documentation beats memory every time
I once joined a call where people even within the same company had completely different opinions about the product roadmap and about a decision made just a month earlier. Thankfully, I had recorded the exact decision in a shared document, and that saved us from going over it again and again.
3. Asking the “right questions”
As a PM, asking the right questions is just as important as finding the right answers. I learned that being crisp and clear with my questions often made the difference between a vague, roundabout response and getting the exact information I needed.
Tips to help you grow and deliver your best:
1. Embrace imperfect information
In this role, you will rarely get the full picture before you need to decide. Waiting for every detail usually means watching opportunities pass by. I once made a major call with just 60% of the facts. It wasn’t perfect, but it moved us forward. The missing 40% came as we went along, and by then, we’d already made progress.
2. Build relationships early, even before you need them
I have already seen how a quick chat with the right person can cut through days of back-and-forth. In the early weeks, I made it a point to introduce myself to GMs, tech leads, and a few “go-to” folks in each company. Those connections have already paid off.
3. Ask sharper questions
In my first few weeks, I learned that starting with broad questions can be a good icebreaker, but they don’t always yield the actionable details you need. For example, in one company, I asked, “What’s the scope for the next quarter?” and got a high-level, generic answer that didn’t help me plan.
So I followed up with, “Which specific features are confirmed for Q2, and are there any dependencies that could delay them?” That shift from broad to detailed completely changed the conversation. I walked away with a clear list of deliverables and the associated risks.
4. Document as you go
Even in six weeks, I’ve already had moments where people remembered a discussion differently. Having notes or a quick decision log to refer back to has ended debates instantly.
5. Stay visible
In such a fast-moving, multi-company environment, people can easily forget what you’re working on unless you tell them. I’ve started sharing short updates in group threads or during syncs. It keeps everyone aligned and builds trust.
If you step into a PM role in this kind of environment, expect to make mistakes. But also expect to grow faster than you ever thought possible. And most importantly: you’ll never, ever be bored.
