Startup localization lessons from Lyft

Focus

Startup localization lessons from Lyft

Brian McConnell is the localization program manager for the ridesharing company Lyft. Prior to leading the localization team at Lyft, he held similar roles at Medium, a blogging platform, and Insightly, a small business CRM. He has consulted extensively with startups about localization projects.

Brian McConnell

ocalization is hard, for a variety of reasons, but it can also be a huge growth level for startups. Here, I’ll talk about why localization is key, the importance of preparing for it early on in your company’s development, and how to manage localization across teams and projects.

Why you should localize your product or service

The reasons to localize depend a lot on your product, company goals and the primary market you serve. As a starting point, ask yourself the following questions:

Is your primary product or service offering an information service or app that can be accessed regardless of the user’s location?
Do you serve a linguistically diverse population in your primary market?
Are you subject to regulatory requirements to support two or more languages?
Do your primary competitors offer services in multiple languages?

If you answered yes to any of these questions, you will likely benefit from serving customers in more than one language. For example, any business in the Los Angeles area will benefit from serving customers in Spanish (Chinese and Korean are also widely spoken there).

If you answered yes to question 1, by not localizing you will be ignoring growth opportunities outside the regions where your home language is predominant. Pretty much any mobile app or web service falls into this category. If you don’t care about picking up international customers, just be aware that some information services have network effects, which will favor operators that can serve users in many languages. The popular WhatsApp instant messaging service is a great example of viral growth that was accelerated by localization.

Many managers don’t think about question 2, but this is an equally important reason to consider going multilingual. In many southern US cities (Miami, Orlando, Houston, Los Angeles and more), 30% of the population speaks Spanish. Many of these people are bilingual, and can conduct business just fine in English, but they prefer companies that speak Spanish — often because they will recommend these options to friends and relatives whose English is not as good.

If you are operating in a bilingual region, such as Quebec, you may be required by law to serve customers in both English and Canadian French. This is especially true if you run a brick and mortar business and are subject to accessibility requirements. This is less of an issue in the US but it does come up, especially for government contracts.

Lastly, if your competitors are doing business in other languages and you are not, this puts you at a disadvantage. You don’t necessarily need to copy everything they are doing, but you should do research and find out how this is helping their business or costing yours.

Localization is a 360 degree experience

One trap companies often fall into is to confuse localizing something like a mobile app (usually pretty easy) with actually serving customers in their language. Lyft is a case in point. It involves much more than the Lyft app people use to hail rides. In order to fully serve our passengers and drivers in Spanish, we had to make the following services and touchpoints multilingual:

Passenger and driver mobile apps (Android and iOS)
Every backend service that sends user-facing text to the apps (for example, receipts)
Customer support knowledge base
The lyft.com website and blogs
Live customer support via agents
Onboarding instructions and sign-up process for drivers
Promotions and marketing copy (for drivers and passengers)
Offline documents such as driver handbooks
Legal documents such as our privacy policy

This work spanned a large number of teams, including engineering and nontechnical teams. It was also a challenging project because Lyft, like most companies, had been operating in English only for the first several years of its existence. As a result, we had a significant amount of technical debt that needed to be resolved as part of this work.

Cross-functional projects like this are hard, and they are hard for a variety of reasons. In order to succeed, you will need the following things:

The project has to be a top level company key result. Without senior management support, it will be difficult to get teams to coordinate their schedules. In many ways, this can be the hardest part because they need to weigh short-term and long-term priorities. Don’t be surprised if it takes six months or more to get this commitment. Start working on getting management support today.

There should be a central team that manages the cross-functional work, although much of the work will be done by individual teams. At Lyft, we have a dedicated engineering team that focuses on building translation tooling, but otherwise most of the work was done by the teams that owned specific processes or features that needed to be localized. This approach allowed us to build tools that the rest of the company could use, while educating other teams about best practices, coding standards and so on.

Lyft in Spanish and global net revenue of Lyft from 2016 to 2020

Figure 1: Lyft in Spanish (left) and global net revenue of Lyft from 2016 to 2020 (in billions of US dollars).

This is why it was so important to have executive leadership set a company-wide key result for language support. Because of this, teams throughout the organization had to meet this goal, and synchronized their schedules throughout the second half of 2018. As a result, we were able to ship Spanish ahead of time, and are now on track to add several more languages early in 2019. If we had not had that support, it is likely that some teams would not have prioritized localization, and we would have ended up with a broken experience that was part Spanish, part English, due to coverage gaps.

Another important item to consider is where your localization team will live within the organization. I like to compare it to the IT department, since teams throughout the company are customers. It is important for your team to report to the right part of the organization. At Lyft, we are part of the growth marketing team, which makes sense, since localization unlocks new market segments. Some of us are engineers, some are technical program managers and some are product or project managers. An important bit of advice: you will need support from the software engineering team, but you don’t necessarily want to report to engineering. It depends on the company, but often the engineering leadership is more concerned with tracking quality and reliability (all important) while other teams are responsible for marketing and growth. You want a sponsor who can see the growth opportunities in multilingual, and who will be rewarded for unlocking new market segments.

The importance of starting early

One mistake I have seen almost all companies make, including Lyft, is to wait until they have to support multiple languages, which is usually several years into their development. By the time they decide to take the project on, they have a lot of technical debt to clean up. This is understandable. Most startups fail, so preparing prematurely for multilingual use before you know if you have built the right product is a risk.

That said, there is a useful hack that I like to share with all early stage companies. The same tools that are used to manage translations can also be used to manage your app and web copy. Think of it this way. As your developers and copywriters are developing and testing new features, they will write English prompts as they do. The problem is that these people are not often the best at writing finely polished copy (often English is not their first language).

The hack then is to “translate” rough English to finished copy, and you can do this using the same continuous translation tools that are used to manage translation for apps, websites and so on. This tool is a translation management system. There are a number of ways to configure this, which I am happy to discuss. The general idea is to treat rough English as your source locale, and finished English as a translation of the source. In doing so, you will go through all of the same technical steps needed for conventional translation, and will be in a much better position to add more languages when the time is right.

The other thing I recommend to software companies is to use the localization tools built into the programming frameworks they use. For example, the Python programming language uses the gettext localization framework. By requiring developers to use this for all user-facing prompts, you can write and maintain localization-ready code. Then, when you are ready to start adding languages, most of the busy work and tech debt cleanup has already been done.

Summary

For most companies, the question is not whether localization will help the business grow, but rather when to start and which languages to prioritize. For example, any business that operates in the southern half of the United States really ought to support Spanish at a minimum, as roughly 20-30% of the population in these markets speak Spanish. The exact mix of languages will vary depending on the markets you serve and what product or service you offer.

One of the interesting things I learned at Lyft is how much the mix of languages varies by city. Did you know that there is a large cohort of Portuguese speakers in Boston? Each city has its own mix of languages, which reflects the immigration patterns that are unique to them. This is true for any region that has a history of migration and immigration, which includes most countries in the modern world.

It’s never too early to plan for localization, and with a few simple tricks, you can make your product or service localization-ready today, and avoid the tech debt trap that so many companies fall into.

Back to Issue