Five Acquisitions, One Platform, No Authority
I worked at a company that had acquired five big competitors in two years in a roll-up strategy. My job, as a platform PM, was to get everyone aligned on a unified technology stack. What seemed like a technical challenge became one of the most complex organizational change initiatives I'd ever encountered.
We had multiple teams solving duplicative problems with different goals, creating a Frankenstein experience across the company. I had no formal change management authority, yet the product's success depended entirely on getting these disparate teams to fundamentally change how they worked.
I couldn't issue mandates, control budgets, or reorganize teams. What I could do was find the people in each acquired company who were frustrated by the same duplicative problems I was seeing. Those people became my coalition.
Instead of dictating a top-down solution, we leveraged each team to help build solutions and share them through a centralized module library. Each team contributed their best work to the shared library, which meant they had ownership over the outcome rather than feeling like something was being imposed on them. When one team's module solved a problem that three other teams were struggling with, the value of the approach became self-evident.
The project transformed how four acquired companies worked together, but it started with something simple: finding the frustrated people and giving them a way to contribute to the solution.
The Pattern Behind the Story
I didn't have change management training when I took on that platform role. But as a PM, I already had the skills without realizing it. I spent every day convincing engineers to build things, designers to iterate, and stakeholders to fund roadmaps. Those same influence muscles -- reading what people care about, finding common ground, making a case without pulling rank -- turned out to be exactly what organizational change requires.
The pattern that worked in my acquisitions experience is the same one I've seen work everywhere since: find the frustrated people, start small, make progress visible, and treat resistance as information.
In the platform consolidation, finding the frustrated people meant identifying the developers across all five companies who were tired of rebuilding the same components in slightly different ways. Starting small meant one shared module that solved a clear pain point -- not a grand unified platform vision. Making progress visible meant that when one team's module saved three other teams weeks of work, everyone heard about it. And treating resistance as information meant that when teams pushed back on the centralized approach, I listened -- because their concerns about losing autonomy were legitimate, and addressing those concerns made the module library design stronger.
The reason it stuck -- the reason it outlasted my involvement -- was that the teams who contributed modules became the strongest champions for the approach. They weren't participating in someone else's change initiative. They'd helped build the thing, so they had ownership over its success. That's the difference between change that requires constant pushing and change that sustains itself.
Product managers don't need formal authority or a change management team to drive transformation. We need coalitions and small wins. Find the people who see the same problems you do, give them a way to contribute to the solution, and let visible progress do the persuading for you.