Writing, speaking, and translating the future

Templated country launches

Making a mold

For international launches to be efficient they must be repeatable. This requires creating repeatable processes that will be easy for others not as steeped in the details to understand and to successfully contribute to the work. So building a prototype of a process and making it an easy to follow template are essential to create a templated process that will expedite decisions and execution.

Global-ready stack

The following discussions about prototypes and templates is contingent on having a global ready stack. If that is not the case, the prototype phases can be used as forcing functions to ensure the stack is properly internationalized, configurable enough to support legislation or cultural expectations, extensible enough to meet demands in these new markets, and scalable enough to manage the traffic and users in each new country with little change in latency or features.  This may require work by UX to support the UI in every language, choose alternate fonts, or change the workflow to fit regulations. Development teams may need to make a plan for managing multiple versions of the stack in different regions to satisfy data residency requirements or reduce latency, and they may need to have a plan for cookies and a way to rectify language settings from the device and the on page language chooser. Localization and test teams may need new tooling to support all the multilingual testing and content revisions.  These are all extraneous tasks that are not really part of the prototype phase but they can be addressed during that work.


The prototype phase is really a proof of concept phase for your templated process. The templates should be stress tested in preparation for an actual launch to make sure all the right stakeholders are providing feedback and the essential information for decision-making is captured.  If you’ve already launched in other countries it is worth writing up the process you used to test the templates. It will help you find gaps both in your previous launch and in your templates


A  standardized launch process expedites decision-making, reduces risk, and documents decisions.  This can be successfully executed with three templates. Below is a description of each document.

Country profile and launch template

A country profile that delineates opportunities and challenges of a new country as well as essential information we need to convey to teams for them to make their own decisions about what is required to support the market. This document should also seek data from legal, privacy, UX, and other teams that might be required to change or adapt the US-models for a new locale.

International market product requirements document

A short or medium length PRD document that delineates what we will build, why, and how we will measure success in the new market. This document will be socialized more broadly then the country document because product, support, and other teams will need to plan how they will support specific products in specific countries. It is also a good opportunity to get product teams thinking about what it means to support a lot of new countries. As products launch in new countries, updates, feature development and deprecations become more complex. In the next blog I write I will address this more fully. This document and the as-built document are great ways to track these complex interactions between the product features in any new market.

As-built global product and solutions document

This document that captures what we have done for a product, or solution in each market. The as-built will be the historical record for what was launched where. It will allow new team members and veterans to quickly understand why our solution or product looks different in each market.

All of these documents can be created as templates so that anyone could begin the work to create a country launch, intl prd, or an as-built document. I’d also recommend using a table on confluence or a company blog to track all these documents because documents for planning launches will be created continually.

The goal of these documents is to create a lightweight scalable method to decide on whether we will support a country, what the issues we need to address are to be successful, and document how our solutions are adapted and released in a country. These will also be a great record for launch learnings to help everyone improve at the processes.



Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.