Brian McConnell is the founder and general manager of Localization Technology Partners, and former head of localization at Notion.
I joined Notion in 2021 to help build out the localization program and team, having previously built out localization at leading startups including Lyft, Medium, and Blackline Systems.
Notion had recently launched support for Korean and Japanese, and was looking to make the localization program more comprehensive and efficient. My area of specialty is helping startups and growth companies put together the right combination of people, technology and vendors to support a scalable localization program.
What was Notion’s initial motivation for investing in localization? How did the company’s international user base influence this decision?
I was drawn to Notion because it had a great product, and even before they localized the product to languages other than English, they were already seeing strong organic demand from non-US markets. They had a huge following among startups and knowledge workers in Korea, Japan and France, which informed their decision about where to start. Notion was also seeing strong revenue growth for these regions, so the decision to invest more in localization was easy.
Can you describe some of the early challenges Notion faced at the beginning of the localization project?
When I joined Notion, they were primarily focused on localizing the product itself, which is where most companies start.
The process was pretty manual, especially for long-form content like the marketing site and help center. So, one of the first things we focused on was upgrading the TMS (translation management system) and implementing better process automation. This is a common issue with companies at an early stage of localization.
Luckily, they had chosen Contentful as their content management system, which I highly recommend. It handles multiple languages really well and is integrated with all of the top-tier translation platforms. We also added additional language service providers and reviewers to maximize translation quality.
What were the key factors in assembling a localization workflow that could effectively address these challenges?
Notion has a very high-quality bar for translation, so that more than cost was what drove our decisions. We settled on a workflow that I describe as fix-forward. This enabled us to publish translations as soon as we got draft translations from our vendors, and then update them as in-country reviewers, who were also expert Notion users, edited them.
What was important to you when putting together a localization team?
In general, my recommendation to clients is that they have a mixture of translation resources because different people and vendors have different skills.
Some are better with marketing copy, while others like to focus on technical writing, such as help center content. At Notion, we had a mix of traditional LSPs, boutique LSPs, and in-country experts who reviewed vendors’ work.
How did Notion approach the selection of translation technologies and automation tools? What criteria were most important in choosing the right tools and platforms for localization efforts?
There are a lot of translation management systems available, but only a few that are well integrated into other platforms like content management systems, marketing communication platforms, and so on.
When I joined Notion, we were using a TMS that, while it was good for localizing app strings, struggled to deal with long form content. The main things we were looking for in the TMS were solid integrations with external platforms like Contentful, as well as process automation.
We had limited engineering support, a common constraint for localization teams, so we were relying on the TMS vendor to provide out of the box integrations. We ended up going with Smartling.
Notion has partnered with multiple language service providers, including JOEL Localization. How did you determine which LSP was most suitable for which languages, and how did you assess the strengths of each provider you work with?
Notion started off with a single LSP. They do great work, but we were also looking for in-country expertise and copywriters, so we added around them.
We found that in-region specialists like JOEL Localization do well for languages that require in-country knowledge, like Korean. If you are targeting Japan or Korea, you will probably be best served by a vendor based there. These languages are difficult to staff, and my experience has been that generalist vendors struggle with them more. JOEL stood out for its efficiency and attention to quality, and the success of the product in Korea is a testament to that.
One of the nice things about having a good TMS is you can easily work with multiple vendors and in-country reviewers, and route content to different workflows and vendors as needed.
Could you share your strategies for ensuring smooth collaboration among all stakeholders, including internal teams and external vendors?
I’d say the most important thing is process automation combined with good cross-functional communication. We automated as much of the translation process as we could, not by using machine translation, but by ensuring that new or updated content got queued for translation by default.
This enabled us to spend more of our time prioritizing work and communicating with stakeholders. We used Notion to track the progress of translation projects so stakeholders could easily submit requests and track the status of their projects.
Whenever we had a major feature release, such as Notion Calendar or Notion AI, this involved teams throughout the organization and lots of material that needed to be translated. Notion is a great project management tool; I highly recommend it for that.
Looking back, what aspects of Notion’s localization strategy do you consider most successful?
I think the most important thing Notion did was to build a product that resonated with people worldwide. It helped that the founder, Ivan Zhao, was from China and understood the importance of building for a global audience. The design motifs used throughout the product also appealed to users in Asia, which was probably another big factor in its adoption in the region.
Because of the strong organic demand and Ivan’s global background, the company resourced localization at a level that enabled us to be successful.
Many companies treat localization as an afterthought and never really design their products for global markets, which leads to a self-fulfilling prophecy of disappointing results. Notion was the opposite of that, and today a large majority of its users and revenue hail from outside the United States. Notion is an exceptional company in that respect, as most SaaS companies generate most of their business in the US, and maybe a third from other regions.
From your experience, what are the most valuable lessons learned from managing large-scale localization projects? How have these insights shaped your approach to ongoing and future localization initiatives?
Localization typically evolves over time and moves around within an organization. During the early stages of building out the program and the infrastructure to support it, there is usually a lot of engineering work that needs to be done.
It’s helpful if localization lives with engineering or product during that phase of development, which usually lasts about a year or so depending on the complexity of the product and the amount of tech debt that needs to be retired. As the program matures and workflows are mostly automated, there is less engineering work to be done, and more focus on supporting in-country activities.
The important thing is that, even early on, it touches most parts of the company. Startups are, by nature, resource-constrained and often have short attention spans, so localization involves a lot of cross-functional communication and coordination.
The most important message I have for companies is that if you anticipate your product will be used in other regions, it is never too soon to start preparing for this. That isn’t to say that you should add 20 languages before you understand the market for your product. However, you should take care to design your product so it can operate in multiple languages in the future.
It’s also important when choosing systems like Content Management Systems to require that they support multilingual operation. If you do a few simple and inexpensive things, it will be relatively easy to add languages when the time comes. If you don’t, you may be faced with a year or more of work that needs to be done to retire tech debt. I have seen that at many companies and it’s part of the reason I have a job!
What are you working on since you left Notion?
I recently started a new company, Localization Technology Partners, to provide localization program management as a service. I had actually been planning to start this business a couple of years ago but couldn’t say no to Notion.
One thing I have observed is that a lot of startups need help in this area, but most of them struggle to staff it correctly. They’ll usually put a product manager who has no prior localization management on the project, which leads to a lot of avoidable mistakes and delays.
We can help companies that are new to localization get the right people, technology and vendors in place, as well as to train engineering, product and design staff on best practices. This way, they can get things right from the beginning, as well as save a year or more in time to market.