Why Global PMs Must Unlearn Their Native Tech Biases

From Bengaluru to New York to London, and everything I had to forget along the way.

There is a version of me from about eight years ago who was convinced he understood users, more precisely, customers. Throughout my engineering career, I have shipped features, wrangled stakeholders, survived intense delivery cycles, spent nights writing code, and produced some highly impactful products. I had worked with large-scale data systems handling petabyte-scale data and optimized APIs to handle heavy loads in sub-second processing times, and these experiences had built in me strong opinions about what made a product genuinely useful. 

In retrospect, that version of me was building products for one particular demographic, the digital-first user. The user that valued speed and convenience over quality. The user I had grown up with, and had mistakenly believed I was designing for all people.

If you're an ambitious, technology-focused professional with global aspirations, I want to talk to you directly, not to discourage ambition, but to explain why the skills that made you exceptional at home can quietly become a ceiling in your global growth journey.

The World Is No Longer One Internet

Here is the broader reality that makes this conversation relevant and almost urgent right now: the assumption that you can build one product for a global audience is collapsing, and it's collapsing fast.

Let’s look at a simple, recent example. When large language models first emerged, almost all of them were built and benchmarked primarily in English. Within two years, that was no longer tenable. Frontier models went from supporting around 25 languages in early 2023 to over 100 today, a near 4x expansion, because companies quickly realized that a product optimized for one language and one cultural context simply couldn't serve a broader world. For contrast, Google Translate launched in 2006 but took a full ten years to reach 100 languages. The same destination, but the pace of expectation has changed entirely. Language was just the most visible symptom of a more profound problem.

Technologists have a term for this phenomenon: the "splinternet", and the idea is fairly straightforward. The internet is fracturing along national and geopolitical lines, and every country, continent, and government has its own set of rules you need to comply with to reach its customers. Europe has GDPR. California has CCPA. India has its own evolving data protection framework. Post-Brexit Britain occupies its own regulatory island. China's internet is architecturally separate from the rest of the world. More than 100 countries now enforce some form of data localization, rules that dictate not just what you can do with user data, but where you are physically allowed to store it.

For a product manager, such regulation is no longer a compliance footnote. It rewires how you build.

My experience across the US and UK has shown me the impact up close. I've participated in, and sometimes led, roadmap discussions where implementing something as simple as saving a user's search query escalated into weeks of planning. The issue was never the feature itself; it was everything underneath: where to store the data, verifying the user's physical location, building automated deletion flows, handling data access requests, and navigating regional legal nuances. I've watched genuinely good product ideas get shelved not because they were bad but because their architecture was incompatible with regional privacy law.

Comparing these experiences to my time in India, the priority early in my career was to move fast and build for impact. This is not to say that data privacy frameworks did not exist there. I strongly believe India has some of the most thoughtful data handling principles in the world. But in a rapidly developing economy where digital adoption was exploding, the urgency was on growth and getting products into more hands faster. The granular compliance architecture that dominates my work today was not completely absent from my thinking back then, but it was rarely the first question in the room. The speed of delivery was fast. Moving west didn't just change where I worked. It changed the order in which I think about things.

The Context Switch

Knowing the world is fragmenting is one thing; feeling it in your product decisions is another. Let me paint two contrasts from my experience that I think best illustrate what this cultural shift actually looks like in practice.

The first is granularity vs. exploration. Years of building and using products for Indian power users shaped my instinct that more control equals a better experience. Give people every filter; let them drill down precisely to what they need. That felt like respecting the user's intelligence. So, in my first job in the US, I prototyped exactly that. I added several filtering options to an analytical web application. But, when we moved that prototype to user interviews, the response showed instead that users didn't want to do the narrowing work themselves. They preferred to explore broadly and discover along the way. More options created more friction, not more satisfaction. The assumption I had carried from one market turned out to be precisely the wrong instinct in another. That result genuinely surprised me, and it was one of the clearest early signals that I needed to start questioning what I thought I knew about users.

The second shift was less about interface design and more about how feedback itself works. In India, user interviews tended to be thorough and detailed. People would tell you exactly what was broken and why, directly and with a lot of context. It was almost like receiving a diagnosis. In the US, feedback was presented in a different manner. Users would articulate their expectations for the ideal experience, rather than pinpointing the shortcomings of the current one, necessitating me to interpret the underlying meaning and fill in the gaps independently. Neither approach is better than the other. One tells you what is wrong. The other tells you what is missing. Over time, I've come to realize that working fluently with both systems has significantly increased my empathy for user needs and also made me a better user interviewer. 

The US to UK Shift 

Differences in professional environments are not just between Asian and Western economies. There are significant changes even between the so-called "developed" nations, and I learned that firsthand in my move from America to Britain.

Product culture in the US rewards bold bets. You are encouraged to take risks, move fast, ship things before they are fully baked, and iterate loudly based on what you learn. In that sense, it actually shares more DNA with the Indian hustle environment than most people expect. The tolerance for public imperfection is relatively high, and that energy is genuinely motivating to work within as a PM.

London is different. The UK product environment operates with a stronger default skepticism toward "launch and learn," particularly in data-adjacent industries. Regulatory awareness gets baked in earlier, and most product reviews carry an invisible layer of "but have we fully thought this through?" that you don't always encounter in San Francisco or New York. Consensus takes longer to build and is harder to shortcut.

From California to London, I noticed my instincts shift gradually. The "ship it" reflex slowed down in favor of more thorough evaluation. At first, it felt like friction. Over time it started to feel like discipline.

None of these environments are better or worse than the others. Each is a rational response to the market, the regulation, and the culture it operates within. India taught me how to build with urgency and creativity under constraint, serving one of the largest and most diverse user bases in the world. The US taught me to think ambitiously, take calculated risks, and trust the iterative process. The UK taught me how to slow down just enough to ask the harder questions before shipping. The PM I am today is a product of all three, and each geography left something behind in how I think, how I prioritize, and how I build.

How to Actually Unlearn

If I had to distil nearly a decade of cross-market PM experience into three principles, it comes down to this.

First, avoid viewing "users" as a single entity. The Indian market rewards speed, affordability, and convenience. Western markets reward trust, simplicity, and a feeling of quality. These are not just different preferences on a shared scale; they are different value systems built on different user journeys. The sooner you start isolating what "value" actually means for the specific user in front of you, the faster you will stop making assumptions that don't travel.

Second, let data challenge your assumptions, not confirm them. Coming from an engineering and data science background helped, but knowing how to run an experiment is only half the skill. The real discipline is designing tests specifically to challenge your convictions, not confirm them. My earlier example about adding more filters with the assumption it would help users is a good illustration of this principle. The data told a different story than my instinct, and I had to be willing to listen.

Third, build your qualitative empathy muscle deliberately. The single habit that most changed my product thinking was spending half a day, once a quarter, watching an actual user do their job. Not through a demo or a dashboard, just observing. Journalists, marketers, supply chain analysts, and compliance leads. Every single time, I walked away carrying fewer assumptions than when I arrived. This exercise is not about learning how other functions work. As a PM, expanding your problem-solving horizon is one of the most important and underrated parts of the job. The better you understand the humans around you, the better everything you build for them will be.

From Local Executor to Global Visionary

Finally, on a note of practice, study GDPR (General Data Protection Regulation) and the CCPA (California Consumer Privacy Act), not as a compliance exam but as a user psychology document. Understand why EU users feel the way they do about data and why the state of California requires more data reporting than other places, because all of it has come from somewhere real embedded in the mix of culture and political systems. 

Read Erin Meyer's The Culture Map to gain a framework for understanding how different societies communicate, give feedback, schedule, and build trust. This is invaluable for managing diverse teams and understanding user expectations. Learn Hofstede's cultural dimensions (such as Power Distance, Individualism vs. Collectivism, Uncertainty Avoidance, etc.). These models are not tools for stereotyping, but rather a vocabulary for articulating what you will notice in users across regions. The subtle friction points in user flow, the differences in conversion rates for a payments product in India vs. England, or general variations in feature adoption. Having this language allows you to build structured, objective analysis rather than relying on vague, unhelpful cultural generalizations.

The cross-cultural UX literature is astonishingly rich and underread in PM circles. Most product managers unknowingly adhere to established, US-centric best practices, overlooking the potential benefits. Things like color psychology, information density, input methods, and the very definition of "simplicity" all shift meaningfully across cultures. Seeking out research on localization and culturally sensitive design isn't optional for a global PM; it's literally the job. But beyond the reading, the most valuable thing I've learned across nearly a decade of building products on three continents is something no framework can teach: the transition to building globally successful products is really about developing the humility to recognize that your mental model of the world was built in one place and to have the courage and the curiosity to keep updating it everywhere else you go.

The world's tech ecosystem is fragmenting. Regulation, culture, trust, and expectation now vary more between markets than they ever have. The PMs who will matter in this environment aren't the ones who ship the fastest but rather the ones who understand that every interface is also a cultural artifact and that building with that awareness is the hardest and most important skill in the room.

Now I want to hear from you. What's a popular Indian app you think would instantly fail in the US or Europe without a fundamental redesign? Why? Can a simple design shift make it work better? Drop your answer in the comments.