Product managers underestimate integration costs
Integration work is often treated as a detail.
A line item on the roadmap. Something to estimate, schedule, and move past once the "real" product work begins.
That's a mistake.
Integration costs are rarely just technical. They show up across time, teams, and decision-making, often long after the initial work is "done".
What PMs tend to underestimate isn't the first integration.
It's everything that follows:
Aligning data models and assumptions
Handling edge cases that don't fit clean abstractions
Coordinating changes across teams with different priorities
Debugging issues that span ownership boundaries
Each individual cost looks manageable in isolation. Three days here, a week there. The cumulative cost, measured in months and coordination overhead, isn't.
I once scoped an integration between our checkout system and a new payment provider at "two sprints."
The technical work took two sprints. But we spent another month after that:
Reconciling how we defined "refund" versus how they did
Handling partial payments that our data model didn't account for
Coordinating testing across three teams with conflicting release cycles
Debugging failures that only appeared in production under load
The integration worked. But it cost 3x what we'd planned and created ongoing coordination overhead we hadn't budgeted for.
Another issue is optimism bias.
Integrations are often scoped based on how the system should work, not how it actually does. Legacy constraints, undocumented behaviour, and partial ownership only surface once teams are deep into implementation.
By then, the scope has doubled but the timeline hasn't.
Integration also carries an ongoing tax.
Once systems are connected, they move together. Changes require coordination. Failures propagate. Teams inherit dependencies they didn't explicitly choose.
A "simple" schema change on one side now requires migration planning, backward compatibility, and synchronised deployments. The integration becomes a shared constraint.
That tax rarely appears in the original business case. The ROI calculation assumes the integration is "done" once it ships. The real cost is measured in years, not sprints.
In my experience, the PMs who manage integration well do a few things differently:
They surface assumptions early
They budget time for coordination, not just build
They treat integration as a product decision, not a delivery task
They question whether the integration is necessary at all
Integrations can create enormous leverage.
But only when their true cost is understood and intentionally paid.
The first integration is cheap. The second is where you pay.