Scaling a Product Across Multiple Markets

Problem

The main challenge of scaling a product across multiple markets is how you balance localization needs in each individual market and the global scale that you are trying to achieve as a technology organization. Every market requires certain aspects to be highly localized -- multiple languages, different regulations and specific users’ needs are important especially as you are often competing against local players. This is especially true if you are a US-based organization, as from both a client and a local market perspective, the bar is high to prove yourself as someone locally authentic and serving the needs of local clients.

Actions taken

1. Localize from day one: One of the actions that started long before we considered expanding beyond our first market was leveraging our product sharing forums to offer visibility to local partners into our proposed product and get feedback that informed how we would build for a global scale. From day one, you should have a global mindset built into your product and anticipate how it might scale long before you come to launch in new markets.
2. Get regional sponsorship: When it comes to localizing to new markets, having regional level decision-makers is key as it enables you to serve the most critical local needs that aggregate to the regional level rather than only seeing the individual market view. In addition, they can serve as tie-breaking decision-makers if you are struggling to get alignment with stakeholders on your local product or are having to trade-off features requests from different markets within their region.
3. Rally around shared goals: Setting shared goals with your local partners is also of utmost importance as it avoids an ‘us vs. them’ mentality and fosters closer collaboration. We came to the understanding that it was in our shared interests to launch a local product that is manageable and scalable and that the more bespoke we made it, the less manageable and scalable it becomes. Therefore, we set a high bar for localization ensuring local features were truly in the service of business or customers’ needs. We also built shared understanding around speed to market, as we found for many markets this was a priority. On understanding that a minimally localized product could be launched more quickly, many markets deprioritized their more frivolous requests in favor of a less bespoke product.
4. Ask if requests will solve your most important goals: Reframing any localization request in the language of what is going to meet your highest priority goals is extremely important. If in our case the answer to ‘help a user make a purchase decision’ or ‘choose us as a provider’ was not a concrete ‘yes’ we could collectively ask why we were prioritizing this request as a key change.
5. Solve for your most difficult markets first: Solving for your most difficult markets can be a good way of achieving scale. For example, we always designed for German and Chinese first. German words are the longest words in the markets we serve so in terms of design, you build to fit the German language as your solution will scale to any other market. The same applies to Chinese characters as they allow you to test for non-Latin characters from day one.
6. Finding common regional pain points: In addition, trying to find common regional pain points is also useful. For example, most European countries use the Euro as a common currency, but there are exceptions like Swiss francs of Swedish krona so solving for new currencies allows you to solve a common regional problem. Also, the more extensive mobile usage we tend to see in Asia led us to focus more on specific mobile design and functionality as we knew that was a key priority for all Asian markets.
7. Refactoring is your friend: Finally, from a technology perspective, going from one market to many markets is an opportunity to make the product more configurable. Oftentimes when you first build in one market, there are hacks and hardcoding and scaling should be viewed as the time to pay down some refactoring debt and improve the robustness, scale and speed of your product. This is key to transition a product from a very scrappy one-market product to one that can serve many markets without becoming impossible to maintain. ć  

Lessons learned

• A very different skill profile is required from a PM perspective; a one-market PM should be very creative, trying to build as much impact as possible for your one market versus a multiple-markets PM who has to manage multiple market rollouts, work with many different teams and organize and document rollouts flawlessly. In the latter case, creativity is important but arguably it is more important to be supremely organized to be able to run a scale operation of many different markets and stakeholder needs.
• Documentation becomes increasingly important as you scale. We realized that many decisions and processes that existed in people's heads or were discussed between the team that was originally working on the product fell through the cracks of non-documentation. As we scaled globally, we became much more reliant on well-maintained documentation.
• As you scale, testing becomes more important and we put a big focus on automated and unit testing. To be able to scale a quality product you have to be able to test it and the more markets we hit, the more important it became to be able to test and monitor the product without relying on manual testing alone.
• Scaling across many markets is an opportunity to improve the core product back in the original market as well. Once you've rolled out across many different markets, you are granted an opportunity to take some of the learnings and data and keep improving the original product.