Introduction

Just beyond the knowable boundary lies unimaginable danger. Dragons ready to burn your expedition to the ground. Sea monsters that will swallow your ship whole. Grotesque human giants with a penchant for cannibalism. And these are just the terrors reported by those who have made it back alive.

I have always been fascinated by early maps. These charming relics included wildly inaccurate coastlines and boasted fanciful depictions: partly to grab attention, partly to fill in the blanks, and partly to warn of the unknowable dangers that come with uncharted territories. This was the cartographer's view, and it shaped humanity's view of the world.

It was not so long ago that humans lacked a basic understanding of our little planet, leading expeditions to tragic consequences with false maps and imprecise technologies that misrepresented the basic landscape ahead. Perhaps the reason I love these early maps is because they present a clear perspective on how far we've come.

Today we don't just have accurate maps: they are digitized, loaded onto satellite networks, and connected instantaneously with the phone in our pocket. Every human with a smartphone has the same geographic view of the world. GPS has further improved the picture by creating a user experience that combines the highest resolution maps with turn-by-turn directions.

Modern day product teams; not so modern maps

As today's product teams spread out across the world, they operate with similarly antiquated navigation systems (or worse: no map … or, doubly worse: multiple maps). Imagine if you attempted to follow GPS instructions but had no idea where you were going. It would be an act of blind faith. "Turn right in 500 feet" is a minor instruction that is meaningless without a final destination. Imagine attempting that act in a modern product organization where we don't just have a single driver – we have a cross-country rally race – with teams, in cars, attempting to navigate a bumpy course over long distances in record time.

Turn-by-turn GPS instructions are like the stories in the backlogs of a globally distributed team. They are high-resolution instructions. They are also completely meaningless unless they ladder up to a unified, well-understood product vision. Does each team have a strong sense of purpose, a belief in their 'why'? Does each team have a strategy that maps to an overarching vision for all teams? And how closely woven is the vision, if it exists, into the individual backlogs of each distributed team? The only way for those distributed product teams to succeed is to operate from the same GPS, with turn-by-turn directions that arrive at the same destination, together, and on time. Product leadership at a distance involves giving all teams the destination before giving directions.

How did we get here? (The challenge for distributed product teams)

The world of software felt smaller just a couple of decades ago. Product managers, designers, and engineers gathered in buzzing offices across a few major hubs, sketching ideas on whiteboards and solving problems side by side. An engineer has a question about a requirement? She walks thirty feet and taps her PM on the shoulder. Having a GPS in this setting was an unnecessary luxury given the benefits proximity offered. Then came the great unbundling. Engineering went first, as the offshoring wave of the 2000s proved that remote teams could deliver significant products at reduced cost. Later, over the last decade, product has followed suit, with two million PMs and designers now working from every corner of the world to power a $740 billion global industry. While the engineering revolution has been well documented, the product shift has not.

Then came the pandemic, which gifted us reams of literature on remote work, covering the topic in a generic way, not tailored to the layered, interdependent nature of product innovation. How to use Zoom to inspire water cooler conversations does not help a company develop a differentiated product strategy or innovate its build process. Beyond the ice breakers, most remote work playbooks were built for efficiency, not for the kind of creative, cross-functional work that product teams tackle. They help people stay connected, but not necessarily aligned, and that distinction is everything when your job is to turn ambiguity into clarity. Product teams rely on shared understanding, rapid feedback loops, and a collective sense of purpose. When those principles are replaced by over-optimized systems for communication, documentation, and maximized heads-down time, the results are predictably hollow. The standard remote tactics simply don't translate to the messy, iterative nature of product strategy and design, coming up short in several ways:

• Autonomy without alignment: Empowering teams to move fast only works when they're anchored to a shared product vision and strategy. Without that, autonomy leads to fragmentation.
• Execution without empathy: When product teams are distant from customers, they start measuring execution 'success' by the amount of output. When product teams stop hearing the real voices behind their personas, they lose the intuitive connection that fuels great products.
• Process over outcomes: In the absence of proximity, teams often lean on templates and checklists to create order. A heavy process gives the illusion of progress while drifting from true customer impact.
• Communication ≠ collaboration: Remote tools keep information flowing, but product work requires shared meaning, not just message delivery. Slack threads and Notion docs can't replicate the creative collisions that happen when people think aloud together. Worse yet, these tools become a crutch: without shared rhythms for critique and iteration, they end up digitizing chaos.
• Efficiency over exploration: The pursuit of 'deep work' and fewer meetings favors individual productivity over collective creativity. Product discovery and design require friction, dialogue, and serendipitous explorations.

The habits that make remote work efficient can make product work shallow. Distributed product teams don't just need to stay connected; they need to stay coherent and grounded in shared purpose, empathy, and creative momentum.

A fresh, zoomed-out viewpoint

Given all these challenges, I initially set out to write a better book about remote work: essentially, general remote-work tactics on steroids. As I dove in, I realized the 'how' involves taking a step back and viewing the product process from a distance: setting a solid vision, ensuring operations are set up to succeed, and, yes, also tweaking the build process to work when teams are scattered. It turns out that 'at a distance' can have two meanings: collaboration when teams are distant from each other, and the need to step back and view your product from a strategic distance.

Product at a Distance provides a new map. We ensure success for distributed product teams by providing two ingredients:

• A unified framework for product strategy and build techniques that involve modern, collaborative, transparent approaches. I call this framework the Product House.
• Adaptations of these approaches for settings where teams are highly distributed, aka: Build Beyond Borders.

Through collaborative workshops and artifact-driven processes, I replace an overwhelming array of tactical tools with ten essential, collaborative frameworks, empowering remote product teams to work seamlessly as if they were in the same building. If you don't have the right product strategy, it doesn't matter how efficient your collaboration is. You will just be building the wrong thing. Also, if you do not have a location-agnostic Define and Design process, you will just be efficiently building the wrong things the wrong way. If you can't do these things without being in the same room every day, you are missing a huge opportunity.

Companies that master Product at a Distance realize several benefits:

• Unparalleled access to the best talent. When you're not constrained by geography, your hiring pool grows exponentially.
• The cost advantage from not solely hiring from your current (and likely expensive) labor markets.
• The innovation that comes from multi-cultural teams with diverse opinions.
• The personal benefits of freedom, flexibility, and saved commuting time.
• Around-the-clock progress. The product team wakes up to find that the important project they're working on has moved forward overnight.

I wrote Product at a Distance because the standard product team is increasingly scattered, and too little has been done to establish an effective way of operating in this new, distributed reality. Every company I have advised or worked for across industries handles it in a different, sub-optimal way. I have evaluated, established, and managed multi-shore product development teams across North and South America, India, China, and multiple European countries. While there are certainly experience and cultural differences by location, the Product House framework can be applied to any multi-shore system to reduce strategic risk and increase quality outcomes. These frameworks apply not just to multi-shore environments but also to multi-center ones. Which is to say, pretty much everyone.

If everyone is co-located, that's fantastic! Still, use these frameworks to align your strategy, accelerate development, and reduce the risk of missing the mark. The reason this book is titled 'at a Distance' is that without the proper approaches, distributed product work is nearly guaranteed to fail. It's not a nice-to-have.

There's a moment in every distributed leader's journey when you realize: you will never be in the room where it happens. Because there is no room. This realization is either devastating or liberating, depending on whether you've done the work that comes before. Take the liberating path and avoid the terrors of dragons, sea monsters, and unknowable coastlines. Map your future with Product at a Distance.