Approaching Lean Translation Management for Localization
Your Startup is agile, but is your localization process, too? This is the first in a series of blog posts outlining a strategy to achieve lean translation management. Modern software development usually follows agile product development methods. Especially in start-ups, working relatively boot-strapped and overhead-free is the preferred path to success. Employing a feature and solution centered product strategy is key to rolling out an early preview of your product, be it for alpha customers, investors or start-up events. Most start-ups do a great job at creating amazing products at a very early stage, by staying super-agile in their work processes and employing the latest development tools and frameworks to launch their product on cutting-edge technology. However this does not just go for start-ups.
What is lean management?
Lean Management has been around as a term for quite a while (there is even a journal), describing a management style that wants to minimize waste and harmonize processes. Cutting cruft and optimizing workflows means a reduction of overhead, freeing up resources and achieving your goals faster at less cost. Concentrating on the essentials and cutting out what holds you back can be a daunting challenge in grown structures especially, but it will free up everyone involved.
What is lean translation management?
Just like lean management, lean translation management means establishing a process for translation of your product that aims at harmonization and overhead reduction. Translation is not an appendix to your product production cycle, managing it is not an "extra task". Translation should be an integral part of your work and conform to the same processes and management goals as the rest of your process.
Lean translation management means achieving localization of your software, website or app within a short time period (speed), without unnecessary overhead (cost), integrated into your established cycle (agility), without the number of languages influencing the pace of the process (scalability).
When it comes to the current state of the localization industry, a different picture emerges. Linguistic skill is usually scarce in smaller teams that consist of techies and business mavericks. Localization management tools are not all that popular, and it is usually very late in the development of beta or public product versions that the topic of translation even appears on the agenda, sometimes even much later when rolling out to markets that clearly are not highly English-proficient. Similar patterns emerge in larger companies, where in most cases responsibilities for globalization are shared across departments (business development, marketing, product management...).
As a result, the agility of your department or team comes to a halt, and product managers become disillusioned about translation, often resulting in strategy changes away from internationalization. Bad experiences with localization workflows can kill scaling strategies early in their tracks - but that is unnecessary.
In most cases that we have observed, negative experiences are the result of one or a few of the following dimensions:
- late preparation for localization and missing world-readiness in the product design
- wrong platform choice for translation management
- wrong strategic choice of new languages or target markets
- low quality results due to last-minute cost-cutting in quality control
Let’s look at some of these one by one...
Microsoft apparently coined this term, and it describes whether or not your app or website is in fact ready to be localized - from a technical standpoint. Have you separated all text content from structure and design? Is your master locale either a separate resource file or otherwise extractable? Are all text elements of your app string variables, or is text left hard-coded? This also evolves around general preparedness in your development team to be ready for translation. The goal is to include this smoothly into the development workflow.
This is the internationalization part of your product development, where you ensure that you can take the next steps easily. Careful code documentation and clean resource files can prevent lots of headaches later and reduce the amount of preparatory work that might have to be performed before starting with the actual localization. Most startups do this right, but having someone advise you in the early stages to ensure that world-readiness is by default from the get-go saves tons of trouble later.
Two things are crucial in picking the right tool to manage your translations: compatibility and efficiency. Can you easily import and export your resource files? Is there an API? Are your file types handled by the platform? In terms of efficiency you really have to ask: is the platform making your life easier, or does it come with a huge learning curve and tons of things to change in your workflow? This can be a make or break decision, especially because path dependencies sometimes create hidden costs that are hard to foresee, due to the technical nature of such decisions. Another issue is usability: it is not enough if a tool makes life a bit easier for your development team, how about the translators working on your texts, could they use it? Fulfilling most criteria already points to one thing: not using one will get you into trouble, especially once you think about scaling.
Keep lean translation management in mind. Don't lose agility with media breaks or conversion. If you work in Github, make sure your translation management tool works with that. Ensure you have defined the process for where and when localization starts and how the final roll-out is conducted. As the CTO or product lead developer ask this question: how long after getting all finished files in the target language can we go live with it? Have you talked to marketing? Are all app store descriptions ready? And so on. Staying lean means to rid yourself of unneeded processes, so think about this: how much resources can your developers really spend on handling the localization process? Shouldn't it rather be like this: programmers write code - translators translate text? Money you spend outside these two areas, is overhead, plain and simple.
Most new products get released in either the developers’ native language, or the lingua franca of the internet, English. While English will allow you to cover the core markets in the western world, and most people around the world on the internet have a sufficient command of the English language for basic use of applications, mathematically you’re missing out on billions of potential customers. Billions. You should not pick your language purely based on math, however. Deciding to which markets to expand to, comes with other ramifications attached.
In some businesses for example, if you offer your product and/or website in an additional language, you will have to offer customer service in that language as well. Are you ready to comply to laws and regulations of a new target market you are expanding to? Set up your linguistic market expansion strategically. You can test the waters in smaller markets that are similar (a German product might want to expand to Switzerland first by adding French and Italian language options), or you can focus on key growth markets and securing a first-mover advantage, think Russian, Chinese, Portuguese or a Central European language. Only in few cases is a simultaneous expansion to a whole range of languages feasible, it depends on your product. The wrong choice however can mean significant resource strain and disappointment when looking at your sales figures. After all, do you have marketing channels in place to actually reach those new users? You should have a good answer to the following question: Why are we translating into this language? And if you're a business person (I hope you are), even more importantly see if you can well answer this question: Why are we not translating into this language? Following a lean approach here is to not do translations into certain languages "just because", or because your boss is from that country, and so on :)
Most products fail with this aspect if the others have also "happened". When it is time to pull the plug, in many cases you still want to get the product out, or deploy whatever it is you spent (some) money on. Quality Control is not a luxury good, it is a make or break aspect of any product cycle, that goes double for everything that is customer-facing, obviously translation is one of them.
In the beginning of this article, I turned to the definition of lean management, which is all about minimizing waste and harmonizing processes. Quality control is a process that is crucial to integrate as a major milestone in the product cycle. Carefully planning when and who and how is just as important as the execution itself. Plan this: Who is in charge of quality assurance, who will perform review processes, when are those performed, what are the feedback loops, how much time is earmarked for quality control as a whole, what are possible fallbacks? In a lean translation management approach, one way to look at this is automation: Quality control needs to be an automatic process that kicks in at a certain point in the product cycle, it is not a detour or a show-stopper.
Next up in Lean Translation Management
Ensuring agility across the board in your business means taking a holistic approach to your scaling strategy. Think in terms of numbers, legal, marketing, customer service and technology, but do not forget culture and language! You wouldn’t be the first company to change your product’s name because it will sound unacceptable in certain new markets. As a CEO, CTO or product manager you will thank your team for taking the proper steps to take your product global.
In the next post I will look a bit more at the process side of lean translation management and in a third blog post we will explore how we see Lingohub's role in achieving lean translation management. We welcome your thoughts!