The most successful companies I worked with did one very important thing long before they ever thought about formal localization. They designed the product so that users could interact with and author content in their language, even if the UI was still in English.
Notion is a good example. Years before they started localizing the product, their early generation product enabled users to author wikis and databases in whichever languages they wanted. They also had a minimalist design motif that appealed to international users, especially in Asia.
What ended up happening is they developed a rabid following in France, Japan and South Korea. Even though the product and supporting assets had not been translated, there was nothing stopping users from authoring content in French, Japanese and Korean.
Their first users in these regions were early adopters, many of whom were running small businesses and startups. They knew English well enough that the lack of formal localization didn’t block them.
Because of this, they had early demand signals from markets they might have otherwise overlooked. Indeed, their first language releases were for Japanese and Korean. These are two of their largest non-US markets today and over 70% of their users and revenue are from outside the US.
Key Lessons & Action Items
Early adopters are tolerant of missing localization. Early adopters are like hackers. They are innovative and work around barriers that might stop other users.
Early adopters want you to succeed. They are using your product because it solves a need. Most of them want you to be successful, and will share insights about the local market that will guide product and marketing decisions.
Hire bilingual and multilingual staff. If you are seeing organic demand in a region, look for new EPD hires who are fluent in relevant languages. They are often passionate about accessibility and can fix subtle functional issues that cause users to churn out.
And lastly, don’t put off localization and internationalization for too long. While its absence won’t block early adopters, once you have picked the low hanging fruit, you will need to make your product and supporting assets accessible to get beyond this user cohort (this is especially true in regions where English proficiency is low). How long is too long? If you start seeing organic demand in places like Japan or Latin America, that’s a strong signal to start formal localization because it won’t hurt and can only help.
What Does This Look Like In Practice?
The basic idea of getting out of the customer’s way is straightforward, but what are some specific examples of things you should do?
Hire for diversity. Many EPD professionals are first or second generation immigrants who speak English as a second language. While you don’t necessarily want them to spend time translating resources, they can assess how your products are performing in their language. They can also spot and fix functional issues that cause your product to look janky. These people are often passionate about accessibility and can make the product tailored to users and not lazily translated. This is even more important now that many companies are incorporating AI into their products, because how the AI performs can vary significantly by language.
Sort orders, address formats, and date formats are examples of things that break and are easy to fix. When displaying a sorted list of names, the proper sort order can vary by language and character. The database system you are using probably knows how to deal with this but isn’t being told what language the customer is using and defaults to US English sort rules. Easy to fix, but also easy to ignore if nobody is looking.
Design matters. Fonts matter because some fonts render well in many languages and alphabets and some don’t. When I was a Medium there was one person whose only job was to nitpick on typography which made Medium stand out to serious authors and readers compared to other online publishing platforms. Because the fonts worked well in many languages, Medium sent two important signals: 1) we take design and typography seriously and 2) we took care to test that things work in other languages. Because of this, we saw strong organic demand from authors and readers in regions like Brazil.
Another thing to check is how well your product deals with right-to-left and bi-directional text, which is widely used in Middle Eastern languages (Arabic, Hebrew and Urdu). It is also common for people to combine left-to-right (English and other languages), numbers (which are usually displayed left to right) and right-to-left text in a single document. Even if you don’t plan to translate your UI and other assets to these languages, hire someone who speaks RTL languages to find and fix issues that might block users from using your product there.
Don’t bake English and US assumptions into your product. Many companies treat localization as a downstream task, which sets them up to fail at international expansion. Lyft was a case in point. While they successfully localized their apps and other touch points into many languages, their ride share offering was dead on arrival in many markets due to regulatory and cultural barriers. Uber, on the other hand, acted as a broker/booking agent for licensed taxis in markets where they could not offer rideshare. They also got into delivery services, while Lyft did not. Uber is worth $150 billion. Lyft is worth $5 billion. Both companies started at the same time in the same city, completely different outcomes.
There are several types of adaptation that matter here. One is the presentation layer, which in addition to being translated, also needs to be culturally relevant (for example, by highlighting anchor customers that users in a region will know). The other adapting the product itself so it is acceptable to users, regulators and other stakeholders. Lyft did well on the first, but failed on the second mostly due to executive insistence on trying to make a US centric product (ride share) work in markets where it faced significant cultural and regulatory barriers.
Develop user communities. Active communities can drive awareness and adoption of your product. At Notion, we had ambassadors and user communities who increased early adoption many fold.
Translation != Adaptation. Companies often assume that all they need to do is to translate the interface and then users will show up. It is actually the other way around. If you adapt your product so that people can use it in their language, you will see early demand signals even before it is formally localized . I’ve seen many companies shotgun their product into many languages, and then be disappointed that nobody showed up. It doesn’t matter how well translated your marketing website is if it drops users into a broken experience. By the way, this is one reason it is best for localization to be led by EPD teams, especially early on.
Conclusions
The best way of thinking about this is to start by removing barriers to users instead of thinking about translation and localization as the first step. Most digital products, such as SaaS services, are globally accessible and do not have physical barriers to usage. The barriers will mostly be in usability.
Early adopters will care more about how well your product works and about functional issues. While formal localization is a prerequisite in some regions, especially as you sell to larger customers, you can get a lot of traction and insights from them. Focus on fixing functional issues, blockers and design craft at this stage.
Use metrics to detect early demand signals. Adoption, retention and churn metrics should be broken out by country and user language. This will enable you to see both positive and negative indicators. Higher churn points to usability barriers, while higher adoption and retention, especially in a low English region like Japan is a powerful signal.
Use global ready coding and design practices so that when you decide to pull the trigger on localization you are not faced with an expensive and time consuming refactoring effort.
Related Reading
Where Should Localization Live In An Organization – Who should own localization? This is a tricky question because it touches almost every team in a company. The answer also depends on how the company is organized. This article discusses the trade offs involved in different ownership models.
Choosing A Global Ready Content Management System (CMS) – Companies often choose a CMS without considering localization and multilingual functionality, which can result in big delays to subsequent language rollouts. This article explains what criteria to consider in evaluating CMS vendors.
Global-Ready Coding: The Checklist Every Engineering Team Should Follow Before Launching New Languages – Even if you are not planning to formally localize your product and other assets, this article describes a few low and no cost design and coding patterns that will prevent you from accruing tech debt that is costly and time consuming to retire later on.
Hiring Bilingual EPD Teams For Global Growth – This is a growth hack that pays big dividends at little additional cost. Many EPD professionals speak more than one language, and many are first or second generation immigrants. By hiring with language and cultural knowledge in mind, you can recruit people that can help immensely with product adaptation as you expand into new regions.