I used to think stakeholder management was mostly about communication. If all of that was happening, I assumed alignment would naturally follow. Cross-product integration work forced me to rethink that assumption.
As an integrations product manager, a large part of my role involves coordinating across product teams, engineering groups, UX teams, and external partners.
One particular integration changed how I think about stakeholder management altogether.
The illusion of alignment
I worked on a cross-product initiative to build a shared workflow between two systems.
The goal was simple in theory: users should be able to move between both products without friction. On paper, everything looked aligned. Looking back, I think we confused activity with alignment.
There were plenty of conversations happening. What we weren't doing was checking whether we were leaving those conversations with the same understanding of what we were building.
We had regular syncs between product teams, shared roadmaps, API discussions, engineering alignment sessions, and continuous updates. There was no lack of communication. But when execution began, assumptions started to diverge.
Each team believed they were responsible for building their part of the integration, expecting the other side to adapt accordingly.
What was never explicitly defined was the end-to-end user experience:
- what "seamless" meant in practice
- where the workflow started and ended
- how ownership was split across systems
- what constraints existed on either side
We were aligned on the idea of integration, but not on how it should actually work in practice. So each team optimized locally based on its own interpretation.
Where misalignment showed up
The gap became visible during execution.
In one instance, we discovered midway through development that an API had been implemented exactly as discussed by one team, but not in a way the other team expected to consume it.
The requirement hadn't changed. Our interpretation of it had.
At the time, that was a frustrating realization because both teams genuinely believed they were building exactly what had been agreed.
That misunderstanding led to rework after implementation had already started and forced both teams to adjust scope while timelines were already in motion.
Similar issues followed:
- Dependencies surfaced after development had started
- A login step reappeared in a workflow that was intended to reduce friction
- Engineering rework increased as assumptions were corrected late
- Timelines slipped as scope was re-evaluated during execution
The irony was that the integration was technically connecting the two systems, but it wasn't fully achieving the outcome we wanted for users. We were reducing some friction while unintentionally introducing new friction elsewhere.
We were constantly talking, but not consistently verifying shared understanding.
Communication does not ALWAYS mean alignment
This experience forced a shift in how I think about cross-functional work.
Looking back, communication wasn't really the problem as we were sharing information constantly. What we lacked was a way to validate whether everyone had interpreted that information the same way before execution began.
The shift in how I work
For a while, my instinct was to solve this by increasing communication through more meetings, check-ins, and status updates. However, that didn’t really address the problem.
Instead, I shifted focus from improving communication to reducing ambiguity before execution started.
I introduced written alignment upfront, documenting the end-to-end workflow, system boundaries, dependencies, and success criteria before engineering began. This helped surface mismatched assumptions early, before they turned into rework.
I also changed how we ran cross-team coordination. Previously, each product had its own weekly 30–60 minute sync, which added up to several hours of recurring alignment every week across teams. I consolidated this into a single biweekly cross-product decision meeting, supported by ad hoc sessions only when needed.
Across this initiative, this reduced an estimated 4–6 hours of weekly meeting time across teams, while improving clarity on decisions earlier in the cycle and reducing late-stage rework.
1. Written alignment before execution
I now document integration assumptions before any engineering work begins.
This includes:
- end-to-end workflow definition
- integration assumptions across both systems
- success criteria for the combined experience
- dependencies across product and engineering teams
- ownership boundaries
The goal here is shared interpretation.
I've found that documentation forces teams to surface assumptions that often remain hidden in verbal discussions.
If two teams read the same document and describe different systems, that gap is resolved before execution begins.
2. Pre-build alignment reviews
Before development starts, I run structured walkthroughs with all stakeholders involved.
We walk through:
- the end-to-end user journey
- expected system behavior at each step
- assumptions and edge cases
- dependencies across teams
- ownership boundaries
These reviews create space for teams to challenge assumptions before they become implementation decisions.
This step is less about presentation and more about pressure-testing understanding while changes are still cheap.
3. Explicit success criteria for integrations
Instead of describing success as "seamless integration," we started writing what a bad experience would still allow to happen vs what it should completely eliminate. For example, in one integration, our original success criterion was simply that users could access functionality from Product B within Product A.
Technically, that requirement was met. However, when we stepped back and looked at the workflow from the user's perspective, we realized they still had to authenticate separately and switch context during key parts of the process.
The integration worked, but the workflow still felt fragmented.
We eventually reframed success around user behavior rather than technical delivery:
- Users should complete the workflow without navigating to a separate platform
- Authentication should happen only once
- Required information should be available within the same workflow
- Users should not need to manually transfer data between systems
Those criteria gave both teams a much clearer target than simply delivering API connectivity.
4. Fewer meetings, higher signal
Before this change, each product team involved in the integration had its own recurring weekly status meeting (30–60 minutes each). This quickly added up to 3–5 hours of weekly alignment time across teams.
The harder part of reducing meetings wasn’t redesigning the structure. It was getting teams comfortable with the shift.
Initially, stakeholders were unsure whether fewer recurring syncs would reduce visibility. In cross-product work, people often equate more meetings with more control over risk.
To address this, we made a small but important adjustment: every decision and dependency from the core sync was documented in a shared place immediately after the meeting, including ownership, open questions, and next steps.
Over time, this changed how teams engaged. Instead of using multiple meetings to stay updated, they started relying on the written log and came into the core sync already aligned on context.
What I learned
In cross-product integrations, teams often communicate frequently through meetings, documents, and status updates.
The challenge is that different teams can leave the same conversation with different interpretations of what was agreed.
Unless assumptions, workflows, and success criteria are explicitly aligned before execution begins, each team ends up building a slightly different version of the same idea.
Looking back, the problem was never a lack of communication. We were aligned on the idea of the integration, but not on what that integration should look like in practice.
That's the lesson I carry into every cross-product initiative today.
Stakeholder management isn’t about keeping people informed. It’s about making sure different teams can still build the same thing, even when they’re building different parts of it.
