Minimum Viable Product in DevOps is a development technique in which a new product or website is developed with sufficient features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product’s initial users.
In DevOps, the MVP allows teams to quickly release software to a user base, gather feedback, and then improve upon it in subsequent releases. Instead of waiting for a “perfect” product, the MVP is about rapid delivery, testing, learning, and optimizing. It’s a continual loop of feedback and enhancement.
It becomes clear very quickly that the idea of different delivery levels existing in localization services as well. Not necessarily directly related to DevOps, but we’ve always offered services such as translation only, translation and proofreading, translation, proofreading and editing, and so on. The iteration and polishing of the same idea that is run in cycles.
But these classic localization workflow steps do not entirely align with the DevOps methodology where we automate as much as possible and provide true flexibility for content to be input in any step of the product development journey. Below is a diagram of how we think a basic minimum viable product model should look like in localization. The iterations can differ according to the content purpose, but this diagram helps with understanding the concept.
Applying Minimum Viable Product Concept to Localization Sprints
Machine Translation and AI Post Editing Draft
The roughest draft that is created by purely automating content localization process. The content is driven through a machine translation engine such as DeepL or Intento and then is subject to a pre-trained AI post editing script. Even though the output is a complete draft, we can compare it to the initial, first iteration MVP and call it MVLP (minimum viable localized product). The financial costs are next to none, time of execution can be measured in seconds.
Example use cases:
- Localized A/B testing – Allows for localized testing of features very early, ensuring the decisions on changes resonate with diverse audiences, leading to better user adoption that is grounded in local user data.
- Reader analytics – Offers insights into content consumption by locale, guiding content optimization, UI/UX tweaks, and deployment priorities, ultimately refining the continuous software development cycles
- Layers of data for further iteration – Localization introduces multi-dimensional data, encompassing regional performance, localized feedback, and usage patterns. This rich data spectrum allows DevOps to make deeply informed, locale-specific iterations, ensuring products cater precisely to regional nuances.
Human Post Editing
Using the data and feedback gathered in the previous step, if necessary, human editors are brought in to refine the machine-translated content. This is as much a UX question as it is a financial question. Therefore, the data provided in the initial draft stage helps in making an informed decision. And given the fact that the rough localization draft is done in the first sprint, based on adjustments that have been made to the source, localization production time is greatly reduced.
SEO Optimization
Further iterations are again based on user analytics data and the need for certain content performance. Based on data acquired in the previous drafts, SEO specialists are brought in the loop to adjust meta tags, keywords, and other SEO elements taking into the account user behavior and feedback.
Key metric: After the initial draft MVLP, we start tracking analytics data to identify markets that consume the content more actively. By doing that we can create a localization plan for which markets need to be addressed in the next sprints, and which ones can wait in the background. This allows for fractured localization budgeting, when enterprises can prioritize budget spending in accordance to user activity in certain markets.
Industry Specific Proofreading
We continue looping in new aspects of localization polishing, if they’re required, and delve deeper into linguistic intricacies that may not have been addressed yet. In this step we bring in highly specialized, industry-specific proofreaders address complex terminology concepts that might have not been addressed in the previous sprints. This is a very custom step that might not always be necessary, but it represents further iteration of localization content in the context of product development.
Cultural Adaptation
The last consideration that might be on the same level as industry specific proofreading, we address cultural adjustments. Similar to the final steps of software development sprints, where the software is debugged and finalized, localization in this case deals with polishing of non-linguistic elements, UX experience, content modifications to fit cultural norms, values, and preferences of the target audience. This again might not always be relevant, but nevertheless, this shows the convenient possibility to add localization sprints for when the need for them arises.
The minimum viable product approach from DevOps offers a fresh perspective on the localization process. It shifts away from the idea of localization being a plug-in discipline to a more hands-on support function that can be synced in at every step of software development journey. Each iteration or sprint refines and optimizes the localized content, presenting different use cases for different purposes at varying budget points. This agile approach to localization can be the difference maker when it comes to delivering software to a number of markets quickly and efficiently.
