Unless you have just entered the world of high-tech (or have been living under a rock for the last few years) you’ve certainly heard the buzzword-acronym MVP. In a sports context it stands for most valuable player, but in this case it stands for minimum viable product. It has become as pervasive in software as chocolate chips in cookies, even making an appearance as an episode title and a subject of HBO’s series Silicon Valley.
MVP is a concept that comes from the product development realm. Defining the MVP for a software company often comes as one of the very first tasks organizational leadership takes on. It defines the minimum feature set required to learn about the product and its users in order to define its future development trajectory. By determining your MVP you’ll often take into consideration the costs to release; the top three features; how to scale; the regional knowledge needed to ship in a target region; and your target audience. It’s these last two items where localization should play a key role, but often is overlooked. MVPs are not necessarily meant to meet a global user base, making localization typically a luxury for most US-based startups.
Honestly, there’s nothing wrong with that and waiting may be in the best interest of the company. Eventually, however, leadership will want to target more markets and will need your help to guide them through the process of defining what I like to call the MVLP: the minimum viable (localized) product.
You might think that this is as simple as repeating the same process for defining the MVP, but in fact it’s not. The MVLP is defined after the MVP has been created, tested, and user data has already begun to trickle in. All too often, the organization’s MVLP is defined only after their product has expanded beyond those top three features. The beauty of the MVLP is that it happens multiple times throughout the product life cycle. Every time leadership sees potential in a new regional market, that’s the time to define a new MVLP for your future consumers. In fact, you’re often in a better place to define the MVLP once the MVP is a bit more mature because you then have user research data to help you!
Data is necessary to building out a solid MVLP. Some of this can be gathered at any time, but some is most valuable once you’ve identified your users’ habits while they’re engaged with your product. There are several resources available to help you to accomplish this. First, there are heatmap usability studies that track your users’ interactions with the product user interface (UI). These studies help you analyze how users in specific regions interact with your product, including which areas of the product are most visible and used by your target users. These studies can also help you identify varying levels of string visibility in your UI based on menu clicks and allow you to prioritize their localization on a region-by-region level (see Figure 1 for an example of how Mozilla has defined string priorities). Second, you have the OECD study “Skills Matter: Further Results from the Survey of Adult Skills.” This report by the Organisation for Economic Co-operation and Development (OECD), produced in 2016, aimed to categorize computer skills around the world in adults aged 16-65 years by region. It’s a fascinating resource that we’ll come back to in a bit. The final resource you have at your disposal is your competition. Your competitors can indicate to you what markets you can be competitive in, as well as what markets they have not yet entered. All of these resources can help you with the most important part of defining your MVLP: knowing your users.
Defining your own MVLP
Now that you have these resources and data, the first step to defining your own MVLP is knowing your users. Jakob Nielsen of the Nielsen Norman Group said it best when he wrote, “One of usability’s most hard-earned lessons is that you are not the user.” The OECD study on adult computer skills only solidifies the sentiment here. Based on this study, Nielsen found that “across 33 rich countries, only 5% of the population has high computer-related abilities, and only a third of people can complete medium-complexity tasks.” This has significant impact on the way that your product will fair in a new target market, depending on the complexity of the UI and the product’s purpose. In defining your MVLP, not only will you determine the appropriate target languages within a specific regional market, but you’ll also contextualize the user data you’ve gathered from your MVP within the findings from the OECD study. See Figure 2 for an example of data that could be helpful. By doing this for one language across several regions, you can validate the results of the OECD study for your own product. This would inform your decisions concerning whether or not a region-specific version of the software needs to be created to cater to the regional user’s computer skills. It can also help you to prioritize content for translation based on regions, average computer skills, and the content’s level of visibility within the product.
Now that you understand your users, you’re ready to define acceptance criteria for your MVLP. These acceptance criteria can and should include your target languages, the percentage to which the product UI should be translated, and the minimum level of acceptable quality assurance and quality control performed on the product. If the minimum level is quite low, you might consider utilizing nontraditional means of translation procurement for that language. You might also consider performing simple smoke testing rather than full static string analysis.
Finally there’s the issue of the cost to release your MVLP. Very often this is tied to your organization’s localization budget exclusively. If this is the first MVLP your organization is creating, your localization budget is likely going to start off quite low.
Your acceptance criteria can help you to defray costs for creating multiple MVLPs. For example, let’s say that you’ve determined through your user research that in one region the computer skill level of your target audience doesn’t require the full UI to be localized the first time around. You may run a budget surplus for this MVLP. In another region, however, the computer skill level is higher and requires a full localization of the product UI and potentially any user help documentation. With your acceptance criteria for both MVLPs, you can reallocate funding from one to the other, as well as determine if cheaper, nontraditional means of translation procurement are a good option for this MVLP.
The MVLP definition process will likely be repeated multiple times throughout the life cycle of your product. Each time the product enters a new market, ideally an MVLP definition will be created for it. Sadly, we don’t live in an ideal world and often localization is one of the last considerations made for a product. As I mentioned before, the beauty of this concept is that it can be applied at any stage of the product life cycle and repeated over and over again.
