Demystifying globalisation: Scaling products for a global market

Building products to consistently, quickly and sustainably meet the local expectations of customers in targeted global markets

For the last while I’ve been working on globalisation at Skyscanner — this is an attempt to synthesise some of the cool things I’ve learnt so far.

First, why should you care?

Before we delve into globalisation, localisation, internationalisation, locales, understanding globalisation depth, and all that fun stuff — let’s take a quick moment to explore why you should care about globalisation.

Today, in January 2020, native English speakers make up only ~4.92% of the global population, and English speakers in any useful capacity make up only ~15.13% of the global population. Further, majority native English-speaking market populations together make up only ~6.12% of the global market population (and only ~25% of the world’s Gross Domestic Product).

If it isn’t apparent from these stats alone, building products for English-centric customer segments (whether intentionally or not) when developing a global product is to build for a specific minority of customers. This might be the intention and strategy today, but for a global product to do so is to neglect and forego massive potential global growth opportunities and fail to capitalise on serious potential strategic advantages ripe for the taking.

Yet, not many product managers understand globalisation and how to both valuably and sustainably scale a product globally. Lots see globalisation and its processes as a big black box that they don’t want to touch out of some kind ‘fear of the unknown’ that marketing or some other team understands and you’re spooked. However, as with most seemingly scary black boxes we don’t want to touch — once you do open the black box it actually isn’t so scary. In fact, understanding globalisation could be the essential tool you’re missing to take your zero to one product from one to ten or even ten to one hundred.

It involves the enlightening process of stepping back from the lens you’re all too comfortable using to view and understand the world, looking through the lenses that others use to view and understand the world, and seeing the bigger, holistic picture of your product in both a local and global context simultaneously.

So what is globalisation?

Globalisation (abbreviated as ‘g11n’) is the combination of two concepts — internationalisation and localisation. The aim of globalisation is to build a product in such a way that it can consistently, quickly and sustainably meet the local needs and expectations of customers in targeted global markets.

Internationalisation (abbreviated as ‘i18n’) is the process of designing a product so that it can be adapted to various locales without engineering changes. In other words, internationalisation aims to set up a product for consistently, quickly and sustainably scaling to targeted global markets.

Localisation (abbreviated as ‘l10n’) is the process of adapting an internationalised product for a specific region or language by both translating text and adding locale-specific components. In other words, localisation aims to ensure that local customer expectations are understood and met.

For a simple analogy, imagine the blueprint of a house. Internationalisation is like making various parts of the design able to be interchangeable, while localisation is like the selection of those interchangeable parts to meet the needs and expectations of different people. So, internationalisation says the house design has an interchangeable kitchen, windows, roof type, flooring and it can be painted any colour. Localisation then comes along and is able to build any number of houses with that design but with tweaks to the kitchen, windows, roof type, flooring and the colour of the house to meet the needs and expectations of different customers.

Localisation, which is potentially performed multiple times for different locales, uses the infrastructure and flexibility provided by internationalisation, which is ideally performed only once as an integral part of ongoing development. However, both are equally essential in the pursuit of quality globalisation.

Tell me about locales

Locales are a tool used for localising software products for different market expectations. A locale is best understood as a standardised set of local customer expectations. They’re a good way to put yourself in another person somewhere else in the world’s shoes at a pragmatic, high level. It’s important to note here that locales are about more than language — you cannot generalise local expectations by language alone. An easy way to think about locales in most cases is as somewhat of a language / country / market expectation combination.

To show you how locales are about more than language, let’s compare a couple of easy examples of English locales first:

en-GB: Great British expectations, including the British English language, the Gregorian calendar, latin script, the £ (GBP) currency, the “dd-mm-yyyy” date format, etc.

en-US: United States expectations, including the US English language, the Gregorian calendar, latin script, the $ (USD) currency, the “mm-dd-yyyy” date format, etc.

As you can see, the local expectations of both of these English-speaking markets have a lot of similarities, but there are differences. Failing to meet the local expectations of customers in the US, for example, and forcing en-GB expectations on them will likely significantly decrease US customer trust in your product. This sounds super obvious, but it will be noticeable in a failure or reluctance to convert customers, difficulty growing your product in the US, and unlikely retention of any customers that do convert as they find more localised alternatives.

While something made for en-GB that is not localised for US customer expectations might have additional frictions that decrease trust (including some ‘s’s where ‘z’s should be, a different date format and a foreign currency), there are a lot of similarities that might still allow some portion of customers to derive value from your product.

However, the situation gets dire as soon as you venture outside of English as a language. Let’s take a look at a few:

en-GB: Great British expectations, including the British English language, the Gregorian calendar, latin script, the £ (GBP) currency, the “dd-mm-yyyy” date format, etc.

ja-JP: Japanese expectations, including Japanese language, the Gregorian calendar, multiple scripts including the Chinese (Kanji) alphabet and Kana (Hiragana and Katakana) alphabets, the ¥ (JPY) currency, the “yyyy-mm-dd (weekday)” date format, etc.

th-TH: Thai expectations, including the Thai language, the dual Thai solar (based on the Gregorian calendar) and Thai lunar calendar (a version of the Buddhist calendar), the Thai script, particular use of spaces between words and ideas, the ฿ (THB) currency, the “dd-mm-yyyy” date format, etc

As you can see, the differences between en-GB expectations and the other examples are much more significant. Instead of having a friction-filled but still potentially useable product, you now have an almost useless one for people in that market. You cannot expand to any meaningful segment within the Japanese or Thai markets without dedicated locales to meet their respective local expectations.

The 7.8 billion potential addressable market around the globe just decreased at least ~196 million from lacking these two locales alone. In fact, with an English-only or English-centric product, you’re losing up to ~84.87% of your potential addressable market around the world off the bat. That’s a loss of 6.62 billion people from your potential addressable market around the globe from square one.

If you use our house blueprint analogy again, internationalisation and localisation apply here for locales quite smoothly. The house design being a software product, internationalisation being the interchangeability of locale elements in the code (such as the language, currency, date format, etc) and localisation being the actual understanding and data inputs for these locale elements to match local expectations for specific markets.

Impact over readiness, and the inherent balancing act within globalisation

Don’t get me wrong, it’s great to be able to easily scale to lots of locales (in whatever scope you define a locale as for your product). However, the fundamental thing you cannot lose sight of in the pursuit of globalisation is the positive impact that scaling your product is having, rather than the vanity metric of an arbitrary number of markets you’ve got locales for and scaled to.

Locales are a tool to provide a certain standardised level of localisation depth, but they are not the whole picture. They are not a substitute for talking to real local customers in the market you’re wanting to scale to and solving their problems in a way that is valuable to them. It may well be the same as a prior scaled market, but delivering value to these local customers might involve product tweaks you hadn’t considered.

In almost all cases, true high value delivery in select markets trumps low value delivery in lots of markets. This is because feeling like a product was designed and built for you and your specific needs and expectations lies at the crux of product-market fit, high net promoter scores, and retention. A good general rule therefore seems to be to scale horizontally to more markets only as fast as you can deliver sufficient vertical value to local customers as you go.

As I’ve said above, globalisation is the combination of both localisation and internationalisation. There’s an inherent balancing act at play here. You want to meet local customer needs and expectations in specific markets, but you also want to build the product for consistent, quick and sustainable scalability.

If people in South Korea use different payment methods to the rest of the world, should you deliver this feature despite scalability issues of doing so if your globalisation doesn’t account for this? If, for similar products to yours, people in the East expect significantly more text and information in their mobile phone UI design compared to the minimalist design approaches prevalent in the West, should you run dual designs for the varying cultural expectations?

Where the line is drawn between sustainable scalability and meeting local customer needs and expectations is a world-class balancing act and may take a seemingly ugly form from the ground floor. Unfortunately, how and where to draw the line will vary significantly based on the specifics of the product you’re working on and the company’s holistic strategy and vision — so there’s not much that can be helped by a general article like this, nor would it be helpful to try.

I would say, however, that a key insight here is to avoid analysis paralysis in such a huge problem space — it’s an easy trap to fall into. How deeply should you localise? How many locales do you need or should you have? What are the risks and consequences of poor localisation in a market? What are the overheads and costs of properly maintaining a locale? Does ‘full’ internationalisation of a product as it’s being built slow down delivery too much? Is ‘full’ internationalisation of a product necessary for a proof of concept within a global product? Do you lack sufficient supply or support in other markets you’re expanding to? What are the essentials and what are the ‘nice to haves’ for particular markets?

There are just too many questions you can ask at a conceptual level about your implementation of globalisation. And to be honest, as with almost everything, there’s always something to improve or reimagine. In that case, the primary concern that should most often stand above the rest for product managers is this:

Where are, and how can I find, the bigger actionable globalisation deltas to focus on for maximum positive impact?

One tool for finding the answer to this question is EIJAL scoring (English is just another language). It’s a parity scoring method comparing your English versus non-English performance for conversion-based metrics. I’ve done another separate blog on that if you want to read up what it is and how to apply it: EIJAL scoring — English is just another language.

An ounce of globalisation is worth a pound of cure

As the saying goes, an ounce of prevention is worth a pound of cure. While EIJAL scoring is a good way to identify problems in your current state of globalisation (find ‘cures’), it isn’t a substitute for ongoing globalisation efforts at the roots of your global product development process. Finding ‘cures’ simply isn’t nearly as sustainable nor scalable as preventing issues from arising in the first place, and the main point of good internationalisation and localisation practices are to prevent such issues in a sustainably scalable way after all.

In other words, eat your vegetables. Admittedly, getting into a habit of eating your vegetables is hard at first, but it gets easier the more you do it and there are lifelong health benefits of doing so. Similarly, the additional hoops to jump through in the development process by adding globalisation practices might slow you down and be hard initially, but they get easier the more you do them and refine them over time — and there are lifelong health benefits of doing so.

What ‘good’ looks like in terms of practices to adopt in your product development process will vary significantly depending on the product itself and the company vision and strategy. So, while in this article I can’t outline a framework for your company or tell you exactly what to do, I can suggest a few top level areas to look at for improving the globalisation maturity of your business — with some examples to help you understand what each could involve.

1. Consideration in development

Consider globalisation as you build your product. Examples include establishing a framework for giving thought to top-level local needs and expectations when drawing out customer pain points, automated internationalisation and localisation testing in engineering processes, testing your product in multiple languages with different local customer profiles (e.g. completing a test purchase in an expected Chinese case, expected English case, expected Russian case, etc), consideration of globalisation in design review processes for new features or infrastructure, right-to-left design (mirroring) consideration, long vs short language design consideration, etc.

2. Knowledge and training

Teach and share knowledge about globalisation in an ongoing and up-to-date way. Examples are a bit more obvious here but include engineering, product and design hire onboarding training, having perpetuated engineering standards and/or principles, globalisation forming part of the professional development framework in various disciplines, hosting periodic training sessions with various business areas, inviting interesting globalisation speakers to talk at your company, having globalisation as part of operational excellence initiatives, etc.

3. Centralisation

Efficiency, consistency and scalability are key benefits of good centralised processes and infrastructure. Examples include having a central place for translations to be taken from throughout the company, a consistent locale-based system in the case of software products, central localisation tooling, central translation vendor management, a dedicated place to go to in the company for globalisation support and expertise, etc.

4. Dedicated resourcing

Dedicated people and money are essential for bigger deltas of globalisation improvement to be achieved and to ensure quality is maintained. Examples include having dedicated teams (product managers, engineers, designers, etc) to improve globalisation in the company (such as by improving localisation tooling, automated internationalisation testing, etc), acceptance of centralised infrastructure costs, having enough money allocated for obtaining quality translations and gathering local needs and expectations, attracting specialised localisation and internationalisation talent and expertise, etc.

5. Quality assurance (QA)

Ensure and maintain quality by ongoing review and reflection. Examples include periodic locale quality audits, a feedback loop of localisation needs forming internationalisation requirements when they’re prevalent enough, spot- checking translation quality, monitoring EIJAL scores over time, customer interviews to understand locale readiness and fit, etc.

Conclusion

Globalisation is an absolutely essential consideration for global products and must be taken seriously if you are to have sustainable success. There are huge deltas to be gained by actively and continuously improving your holistic approach to globalisation. These include economic and time cost cutting efficiencies, unlocked growth potential both within individual locales and across the globe, working your way into becoming a household brand name, being resilient to competition via local authenticity, and having a sustainably scalable model to reach any customer segment around the world.

However, there are also severe consequences for failing to properly globalise your product. These include unnecessary additional economic and time costs of having internationalisation insufficiencies, the limited growth potential, local degradation of brand trust and market hold fragility inherent of having localisation insufficiencies, and the lack of sustainable success of your business due to an insufficient balance within globalisation (which only festers the longer it is left unresolved).

Let’s be optimistic though — it is like all problem spaces and starts with awareness. If your product managers, engineers, designers and others contributing to your holistic product take globalisation seriously and sufficient time and resources in the company are directed at genuine improvement of globalisation over time (as opposed to bandaids over issues), you can trust in the process and that the ongoing efforts will be very well rewarded.

So… was the black box you just opened so scary after all?
(eek, it probably was, wasn’t it…)

P.S. I recognise that this article itself was written in English and for an English-speaking audience, however the concepts above can apply for any language-bias. For example, a product built in Spanish (Espanol), in Spain and initially for a Spanish market may have a bias to such an audience in the same way as described above for English. In such a case it might be more useful to use “SIJAL” scoring (Spanish (Espanol) is just another language), or whatever other language or locale that the product may be biased toward.

Some Key Takeaways

• The aim of globalisation is to build a product in such a way that it can consistently, quickly and sustainably meet the local needs and expectations of customers in targeted global markets.
• Globalisation involves an inherent balancing act between meeting local customer needs & expectations on one hand, and building your product consistently, quickly and sustainably on the other.
• A locale is best understood as a standardised set of local customer expectations, and a locale is about more than language. While locales represent a way to ensure a standard of localisation depth, they aren’t the whole picture. Market-specific product tweaks outside of a locale framework might be necessary to maximise value for customers in a given local market.
• In almost all cases, true high value delivery in select markets trumps low value delivery in lots of markets. A good general rule seems to be to scale horizontally to more markets only as fast as you can deliver sufficient vertical value to local customers as you go.
• Recognise that failure to globalise a software product, especially internationalising it as you’re building it (making locale-specific elements interchangeable based on customer locales), poses a significant scalability risk. It not only means you’ll have significant globalisation tech debt on your hands later, it means you’re tacking globalisation on the end of your development lifecycle and opting for mere scale rather than true and genuine value delivery to local customers around the world.
• Take globalisation seriously and direct sufficient time and resources at genuine improvement of globalisation (as opposed to bandaids over issues), and you can trust that the ongoing efforts will be handsomely rewarded.