Consumer and enterprise tech companies in the US have a built-in advantage: they target a large market. We have a population of 330 million people who are mostly deemed affluent by global standards.

However, as companies grow, managers eventually realize that there are large swaths of potential customers elsewhere in the world. So, once American companies feel well-established in their home market, senior management should start thinking about overseas expansion, right? Wrong!

We contend that the best time to think about global expansion is long before making the decision to enter your first market outside the US.

Global expansion works best when dedicated central teams focus on making the local teams’ lives easier.

Expanding overseas entails many decisions about sales, finance, legal affairs, workforce management, and other functions. However, in this post we will focus on key product and engineering decisions that form the bedrock of any global product expansion plan.

Foremost, it’s important to understand your product portfolio and whether it is well suited for overseas markets. Scott Cook, founder and executive chairman of Intuit, told us that tax filing differs so much, country by country, that TurboTax eventually withdrew from many of the international markets it entered and now only focuses on the two countries where self-reported income tax is mandated broadly. HR and payroll software providers likewise confront a myriad country- (and sometimes state-) specific labor laws that their products must take into account. And, as consumer protection and privacy laws become more stringent and varied, significant differences by locality are increasingly prevalent for online consumer services.

Let’s parse the challenge of building global products at the infrastructure, data, and application level.

Infrastructure

The key to any global product is embedded in what’s known as i18n readiness. i18n is a play on “internationalization.” The W3C definition of i18n is “the design and development of a product, application, or document content that enables easy localization for target audiences that vary in culture, region, or language.” This includes things like Unicode support, right-to-left and vertical text support, non-Latin character display, the ability to adapt date and time formats, parameterizing localizable content from source code, etc.

All code should be i18n ready from day 1. Meeting i18n requirements is not very time intensive, and it’s good product development hygiene.

Once you’re ready to adapt the code to a different region, you can start the l10n (localization) process. This includes things like local look and feel, date, time, address formats, special language characters, and so forth. To quote the W3C definition, “Localization refers to the adaptation of a product, application, or document content to meet the language, cultural and other requirements of a specific target market (a locale).”

Another essential aspect of infrastructure planning for international expansion is adding appropriate hooks for billing and payments. While most US customers are accustomed to paying with credit cards in US dollars, an amazing variety of forms of payments and methods of billing are used around the world. Deep, who had the opportunity to build out some of the global payments and billing infrastructure at Google, remembers CEO Eric Schmidt’s admonition to the team: “If our Mongolian customers want to pay us in sheep, then we should be able to accept payment in sheep.”

While nobody insisted on paying with sheep, building systems that accepted direct debit payments in Germany and Boleto in Brazil was challenging. Creating the technical hooks that will eventually be needed to connect to the wide variety of payment service providers and payment gateways used in different parts of the world should be part of a company’s infrastructure planning from the outset.

Data

Building Google in the early 2000s did not require deep thought about data privacy and compartmentalization beyond the basics of access control and ‘need to know.’ However, on that front, the world is a much more complicated place today.

The European Union took the first comprehensive approach towards handling individual data via GDPR, its data protection law that went into effect in 2018. Several nations have followed suit and the US is also discussing data privacy regulation in the wake of the 2016 scandal involving a third party firm’s use of private data from Facebook to allegedly impact the US presidential election. Chinese regulators have also issued directives to Chinese online companies operating overseas about their handling of Chinese consumer data, due to concern about its potential exposure to foreign governments.

Suffice it to say that building robust data privacy, governance, trust and safety hooks into your products has become a regulatory requirement — and again, is best done at the earliest stages of product planning.

Application

Building a robust product experience for global markets is typically what most product leaders think about when they are contemplating overseas expansion. This is the visible, fun part of the job!

Hopefully, by now most of us are attuned to basic cultural sensitivities such as not naming your car “Nova” for Spanish speaking markets (because it translates as “not going”), taking care with color schemes, or not making french fries with lard for the Indian market. But when it comes to tech products, sometimes cultural nuances are not obvious at the outset.

For instance, when Deep became the head of products for Google’s Asia-Pacific region, he conducted extensive user surveys in key countries. One result stood out: Korean users thought that our website was still “under construction” due to its minimalist appearance. The clean, simple, and blazing fast Google home page — a key design principle espoused by the founders — was deemed to be incomplete by Korean users. Japanese users had a similar concern:  “We need more things to do on the Google home page!  Why do we only have the search box?” It took just one trip to Seoul or Tokyo, and standing at a busy intersection like Shibuya crossing with its glittering billboards and sea of humanity to understand these comments.

Another example is the culture of exchanging business cards in Asian countries. It’s an important part of business etiquette. So, when LinkedIn expanded into Asia, it was important to build in features that incorporated this timeless cultural ritual. We supported the ability to optically decode contact information from the picture of a business card and create a connection. This helped create a new norm of accepting LinkedIn connections as a valid business relationship.

Selina Tobaccowala recounts her experience as the head of products and engineering for Ticketmaster in Europe. In Germany, users are accustomed to choosing their own seats from an arena or stadium seating chart, whereas in the US and UK, the customer is happy to let software pick the “best available” seat for them. Consequently, it was important to build a seat selection feature in the German version of Ticketmaster.

While it might seem like a big chore to uncover local nuances, Deep’s experience with Google and LinkedIn suggests that a well-designed consumer product generally stays 95% consistent across the globe. But the remaining 5% is very important and sometimes helps a product make the leap from ‘good’ to ‘great.’

What’s the best way to uncover this crucial 5%?

This brings us to the important discussion of setting up a global product organization.

Organizing for Global Products

One way to expand globally is to acquire established businesses in targeted markets. This can solve the challenge of meeting local requirements for infrastructure, data, and application user experience. However, acquisitions can also bring a welter of messy integration issues. We explore those issues in another essay, and assume here that a company plans to enter overseas markets through internal development, that is, offering a local version of its existing product, rather than through acquisitions.

On that path, a global product organization needs to accomplish three goals:

-   Uncovering uniquely local customer needs

-   Building product development capacity for meeting these local needs

-   Creating a management framework to efficiently fulfill the above

Steve Kaufer, founder and CEO of TripAdvisor, recounted his experiences setting up an European organization. Travel experiences are mostly global with some uniquely local twists. So, TripAdvisor initially launched into Europe with local marketing and engineering remaining centralized in the US. This structure largely worked during the launch phase, but posed challenges during the next phase of growth.

In this phase, Steve hired quasi-general managers for the largest European countries. Unfortunately, their product requests rarely synchronized with roadmap priorities that had been established by the US product and engineering teams, leading to conflict. The GMs felt responsible for the full product experience as the ‘mini-CEOs’ of their countries, so they asked that a full product development team be dedicated to them. These requests were denied: the benefits from dedicating such teams did not warrant the added cost and the risk of creating incompatible product versions.

In retrospect, Steve would have preferred to clarify the level of autonomy for the country heads upfront, keeping them focused on local marketing, sales, and partnerships while having product direction and development remain centralized in the US. Of course, this would also mean that P&L responsibility couldn’t be fully shouldered by country GMs, leading to a different kind of organizational complexity.

TripAdvisor’s experience validates an observation made by Scott Cook. He noted that in organizing for global expansion, the extremes are 100% central and 100% local. Scott said, “There must be successes at each extreme, but most companies will end up somewhere in the middle, where the tricky question, activity by activity, is who should decide which activities will be done centrally, which will be done locally, and which are negotiable? You don’t want too much in the last category.”

There’s No Shortcut to Global Success

In contrast to TripAdvisor’s approach, Google’s Eric Schmidt maintained that uncovering local needs and addressing them necessarily meant that the product and development teams had to be local. He did not believe that centralized teams could truly empathize with local user needs and hence the product they’d create would be sub-par. While this approach is expensive, it made a lot of sense for Google given the reach of its products and its revenue opportunities. One of the first tasks that Deep undertook in his role as head of APAC products was to establish substantial Google R&D footprints in nine key locations across Asia.

Relationships Matter

Additionally, Google seeded the R&D organizations in these locations with Google veterans from Mountain View. This accomplished several objectives: establishing a common Google culture; transferring best practices; and providing connectivity with HQ. This connectivity was especially important because while the local development teams could build application features, many key infrastructure changes would be handled by US teams. The relationships that in-country Google veterans had with counterparts at HQ helped prioritize the needed changes.

Rotating veterans into local markets was essential to the success of the teams they joined, and Google even established an incentive structure to encourage engineers to relocate and become ambassadors for 1-2 years in key R&D centers.

Deep also established a group of PM leads in Mountain View who acted as liaisons with the regional teams. These PMs shepherded product changes and led product reviews, security reviews, and negotiated the prioritization of local product requests. As noted by Selina Tobaccowala, prioritization can be challenging with local requests, because in a smaller country, a much bigger business impact is required, percentage-wise, to warrant resource allocation.

The lesson: global expansion works best when dedicated central teams focus on making the local teams’ lives easier.

Be Intentional

The success of global products demands serious commitment from a company’s senior leaders. Both Eric and Google’s Chief Business Officer Omid Kordestani spent at least 30-40% of their time traveling to Google offices around the world. The global heads of product and engineering and their leadership teams also spent substantial time with local development teams and listened firsthand to user feedback. During one such trip to India, we saw that Google employees were using a competing email product because Gmail had not been optimized for the country’s slow internet infrastructure. This is how the ‘Gmail-lite’ project was launched to meet the bandwidth constraints of users in emerging markets in Asia, Africa and Latin America.

Not every company can afford the level of investment that Google dedicated to succeeding in global markets. However, the key lessons apply to every company considering global expansion: prepare to be global from day one, commit the necessary resources, deploy your senior talent, and make global success an important part of the executive agenda.