Why modern product teams are forced to choose between customer-closeness and team collaboration, and what to do about it.
For most of my career, I believed something that, at the time, felt unquestionably true: you could offshore incremental engineering work, but not innovation. Not your core product. And certainly not your product management or design functions.
Innovation required proximity. PMs and designers needed to sit close to customers. But engineers also needed to sit close to PMs and designers. The magic happened in the room: on whiteboards, in design critiques, in the friction of fast debate. That belief wasn't irrational. It was shaped by decades of industry practice.
Then, in the early 2000s, the offshoring wave hit, driven by cost optimization. Engineering talent became globally accessible, and companies sensibly expanded their footprint. But product leadership, strategy, and design largely remained "on local soil," close to customers and go-to-market teams.
That model "worked", at least for non-strategic development projects.
As engineering organizations matured globally and collaboration tools improved, the talent equation shifted. Distributed engineering was no longer just about cost; it was about access, scalability, and specialization. And once engineering became structurally distributed, product organizations faced a more subtle, more strategic dilemma.
I began to see it clearly about a decade ago, when I stepped into a CPO role at a company whose entire product and engineering organization sat offshore. My initial reaction was predictable: this is risky. We'll need to relocate product and design closer to customers to make this work.
But the more I observed, the more I realized I was staring at a deeper structural tension; one that didn't have an obvious answer.
I call it the proximity paradox.
The Structural Tradeoff
When your teams are geographically distributed, you are forced into a choice:
- Place PMs and designers near customers, but distant from engineering.
- Place PMs and designers with engineering, but distant from customers.
You cannot fully optimize for both forms of proximity at the same time.
If PM and design sit near the market, they gain immersion. They hear unfiltered feedback. They develop intuition about customer nuance. But the day-to-day collaboration with engineering becomes slower, more mediated, more prone to misinterpretation.
If PM and design sit with engineering, you preserve the tight multidisciplinary "nuclear unit" of the agile squad. Ideation, design, and delivery move faster. Tradeoffs are debated in real time. But market signals risk becoming abstracted and secondhand. Product discovery is not impossible, but it's much harder.
The paradox is not about whether distributed teams can succeed. They absolutely can. The paradox is about what you inevitably give up and whether you are deliberate about compensating for it.
What makes this different from the original offshoring wave is that the earlier problem was operational. We worried about time zones, code quality, and handoffs. The proximity paradox is strategic. It shapes how innovation happens inside your company.
Why the Nuclear Unit Matters
Over the years, I've become increasingly convinced that the smallest durable engine of innovation is not an individual. It's a tightly integrated trio: product, design, and engineering.
When those roles operate as a cohesive unit to challenge assumptions, sketch together, and review increments daily, the quality of thinking rises. Decisions improve not through individual brilliance, but through disciplined tension between perspectives.
When that trio is fractured across time zones, not-so-subtle changes occur. Conversations stretch. Context gets lost. Energy dissipates. What once took five minutes on a whiteboard becomes a 48-hour asynchronous thread.
That doesn't mean distributed squads fail. It means friction increases and compounds.
For that reason, I increasingly lean toward preserving the nuclear unit, even if it sometimes means PM and design are not physically near the market. But that choice only works if you intentionally reinforce what you are sacrificing.
Because distance from customers carries its own much more insidious risk.
The Slow Drift from the Market
When PMs and designers are separated from customers, the danger is rarely dramatic. It doesn't manifest as a catastrophic misread of the market. It shows up as gradual drift. Customer anecdotes become summaries instead of lived experiences. Sales conversations are filtered. Support pain points are sanitized before reaching the team. Market signals weaken.
You still iterate, and ship. But the sharp edge of empathy dulls over time.
Left unattended, this drift reshapes roadmaps. Internal efficiency begins to masquerade as customer value. The organization optimizes around what is easiest to build rather than what is most meaningful to solve.
The proximity paradox, then, is not a binary problem. It is a tension that requires continual balancing. A balance that does not happen accidentally.
Four Disciplines for Managing the Proximity Paradox
There is no perfect organizational structure that eliminates the tradeoff. But there are disciplines that allow distributed product teams to thrive despite it.
1. Be Explicit About What You're Optimizing For
The most common failure mode is unconscious structure. Organizations drift into geography decisions based on hiring convenience, historical precedent, or executive preference, without articulating the tradeoffs.
You have to decide deliberately: are we optimizing for squad cohesion, market immersion, talent access, or executive alignment?
Different phases of company growth may justify different answers. Early-stage startups often prioritize speed of collaboration. Mature organizations entering new markets may bias toward customer proximity.
There is no universal right answer. There is only the need for careful, conscious choice.
2. Protect the Nuclear Unit
If you decide to distribute your team, distribute by squad. Avoid splitting PM, design, and engineering across geographies unless you have an extraordinarily strong operating model.
Cross-squad collaboration can tolerate time zone friction. Intra-squad collaboration rarely can.
The tighter the feedback loop inside the squad, the more resilient the team becomes to broader organizational complexity. Preserving that core unit creates a stable center of gravity for innovation.
3. Strengthen the Weaker Proximity
Whatever side of the tradeoff you sacrifice must be deliberately reinforced.
If PM and design sit with engineering, you must over-invest in customer immersion: structured interviews, live observation, rotating site visits, exposure to raw support data, and direct conversations rather than filtered summaries.
If PM and design sit near customers, you must over-invest in design and build cohesion: high-cadence reviews, shared artifacts, disciplined documentation, and protected collaboration windows across time zones.
Distance does not shrink on its own. It must be actively reduced through process and habit.
This is where many teams underestimate the importance of structured design and build practices. Workshop-driven discovery sessions, clearly documented opportunity briefs, shared product and design reviews, written product narratives … these are not bureaucratic artifacts. They are mechanisms for collapsing distance.
When executed well, these practices create clarity that travels across geography. They allow teams to align deeply even when they are not in the same room.
4. Lead with Durable Vision and Structured Adaptation
In distributed environments, alignment cannot depend on proximity; it must depend on clarity.
A strong, durable product vision and strategy becomes the binding force across geographies. When teams understand the long-term direction, the customer segments that matter most, and the outcomes they are accountable for, they can make consistent decisions without constant synchronization.
"Align before building" becomes more than a slogan—it becomes survival.
Leadership plays a critical bridging role here. Not as a layer that centralizes decisions, but as a force that ensures strategy is explicit, shared, and durable. Leadership must translate market signal, reinforce priorities, and continually re-articulate why the work matters.
At the same time, teams need practical distance adaptations in their design and build process. Structured workshops, clear decision frameworks, artifact-driven discovery, and regular review rhythms. These are not theoretical ideals; they are operational necessities.
In highly distributed environments, process discipline is what enables creative freedom.
There Is No Final Equilibrium
One of the hardest lessons for product leaders is accepting that the proximity paradox is not something you solve once and for all.
As your company grows, enters new markets, or hires from new regions, the balance shifts. What worked at 50 employees may fail at 500. A team optimized for early innovation may need to be rebalanced when scaling globally.
The proximity paradox is structural. It is a byproduct of modern talent markets and modern work expectations. And in many ways, the original wave of engineering offshoring accelerated its arrival.
But it is not a disadvantage.
Distributed teams, when intentionally designed, can outperform fully co-located ones. They tap broader talent pools. They build resilience. They develop stronger written and workshop-driven clarity. They are forced to articulate a strategy instead of relying on osmosis.
The key is recognizing the tradeoff.
You cannot maximize customer proximity and squad proximity simultaneously. But you can choose deliberately. You can protect the nuclear unit. You can reinforce the weaker side. You can anchor teams in a durable strategy. And you can adopt disciplined design and build adaptations that shrink distance in practice.
The companies that struggle are not the ones that lack perfect co-location. They are the ones that pretend geography does not shape innovation.
The companies that thrive understand that proximity is a design choice.
And like any design choice, it requires intention.