Most companies don’t wake up and decide that the whole world needs their product. They are too busy trying to make the product successful in one region to think about what it will require (cost, time, money, development, marketing, etc.) to make their product successful worldwide. The impetus for global expansion almost always comes from marketing or sales, not from product, customer support, or development teams. And the need for global expansion is usually to meet a commitment that has already been made. Thus the time frame is limited and the quality expectation will be high. So your why mandates a when that prevents a well thought out strategy for global expansion. It’s alright. You can fix this.
First, have a stern conversation with your sales team to let them know they shouldn’t be selling things you don’t have. It won’t change their processes or promises, but it will help you feel a little better about what comes next. You now have a timeline that is too short to do a proper job. Make sure to track your shortcuts so you can go back and fix them all when you finish your first international launch. You should also track any issues that come up because those will be essential to pinpoint the systemic issues you will need to fix as you scale your systems and tools to manage more locales.
Where to begin?
Most likely you’ll need to localize a GUI and some documentation or some marketing materials. Start with an evaluation of what is necessary. If the product has already been sold, then most likely the whole UI will need localization. You should do terminology, and user guides as much as necessary, the UI, and support services should be addressed. You know this will be necessary to meet your team’s commitments but the localization work only prepares you for an initial launch. That is the easy part. The update and the management of the content lifecycle is where your team will fail without an actual plan.
What you should really be doing
What data are you collecting from customers? Can it be collected with your current design or does your product have character constraints that prevent your new customer base from communicating with you or signing up for your product? Where and how will you store the data you collect? Will it be encrypted at rest? What encryption do you use? What transformations does the text or content go through in transit, storage, or when it passes through services? Have you integrated ICU into your code? Which parts? Have you hard-coded text, used concatenation, or turned your pricing and marketing into operational exercises for a US loc team? Can you market the product the same way in a new locale? Each of the answers to these questions will necessitate development, process, and perhaps legal or tax changes. Let’s dive deeper to show you what I mean.
Implications of some of these issues
Backend
If you are collecting data in Europe GDPR mandates that you are clear what that data is and that the data is stored in Europe can your team do that? What will it take to make that happen? At a database level, this may require a cross-region cloud database if you plan on one single database. Or it may require different technical stacks, development teams, and a forked product to meet the needs of a single mandate.
Tax
If you have one entity in the US that does all the localization, but separate entities in different regions even paying for localization becomes a problem. All the revenue from the localized product will most likely be booked in the EU, Japan, or China entity, but are you also back-charging the costs of the work (+5%-10%) to that entity or is the US entity absorbing it? This creates tax allocation issues. If you have a cost share of some kind is localization costs a part of it? If not how will you support the financial implications of localization?
Product
I’ll give an example from my time at Amazon to illustrate how devastating an effect pure translation can have on a brand. Amazon has always had an ad for the Kindle that shows a woman reading on a Kindle device poolside or at the beach. In my mind, it is a bit tone-deaf and market-restricting.
Their intent with the ad is to show that it can be read in full sun and water resistant. The unintended message is that the Kindle is a luxury reading device for the upper class that has disposable income. The second message obviously does not play well in countries where people earn much less money. I have always argued that an ad similar to the World Reader image below is a much more powerful message for the Kindle in developing nations that are more rural, have high education costs, and don’t have established library infrastructures. It turns the Kindle from a luxury reading device to an instrument of education, hope, and change. What parent wouldn’t give a year’s salary or even more to provide their children an education and a chance to succeed? Better still if Amazon implemented a payment plan for their devices outside of the EU and US they may see even more sales.
Over time Amazon has become more savvy about their messaging. Though the poolside ads still exist, they don’t show up in Mexico or Spain. If you compare the Kindle ads for Spain, Mexico, and the US only the images for the high-end Kindle Oasis match. The Spanish and US ads still have a woman on the beach or in a hot tub but the image is noticeably absent from the Mexico site.
A half a solution at best
As I hope you see getting the first deliverable out the door is really just setting you up for much bigger problems if you don’t have a plan. Once you’ve successfully helped deliver for your customer, you should begin the real work of preparing for the onslaught of issues that are coming. There will be issues with the first deliverable because it is the first time your team has done localization. So now as you plan how for more localization you’ll also be addressing translation mistakes, unclear, or unrealistic expectations of your stakeholders, and a slew of issues in content, marketing, and development that the first localized product exposed.
The end of the beginning
I’ve slightly touched on the promised list I gave in my last post. I’m adding it below as a signpost for myself to pick up in the next few. I’ve not even gotten to the actual localization process yet and I won’t for a very long time. I’ll more directly discuss the list below in the next post. I will use the customer and data journey to evaluate a multi-service platform to identify localization work. What you should take away from this is the mantra you will see throughout my posts. Localization is much more than translation and to do it well you need to address the whole enterprise not just the product or service you want to deploy in another locale.
Where do we go from here?
One last bit of advice before we go any further. This work affects the whole enterprise and cannot be done effectively unless there are FTEs involved in the work. You can have consultants and vendors help and provide guidance, but what you will need to do must be driven by people in the organization or it will never happen. I recommend that internal stakeholders own deliverables and actively drive this process.
In the below list, the data inputs should be gathered by each of the groups that rely on or contribute to localization. Unfortunately, I won’t have that data for my examples because I would need to make up the data. So my examples will focus on the customer and data journey where I can walk through the process in depth.
- Data inputs you must understand before you do a customer and a data journey assessment.
- Product Roadmap
- Quality expectations for localization for each stakeholder
- Development tools and processes
- Localization tools and processes
- View of teams you will collaborate with. For example, will you work with or will you leverage the work of content, marketing, development, or other localization teams? And what do they expect from localization?
- Customer Journey and Data Journey: Following customer interactions with and expectations of your systems is a study of your product. Following the data how you store it; what you use it for; and, what other systems depend on the data is a study of your architecture. These two processes will frame all of the other work you do.
- Assessment
- Tools
- Systems
- People
- Costs
- Short and long-term plans
- Current production process
- Assessment
