Why is this important? Adapting a product for international markets requires checking your assumptions about the current product definition. If you know why you are doing something today for your current market, it will be easier to check if that will still be true in the new market. This way, the internationalization team will be able to adapt the existing product to the new market in a systematic way. Having a process for internationalizing a product saves both time and cost.
How do you define your current market segments? How do you group customers? By industry, sector, geography, job title, age? What are the unique challenges faced by each segment?
A use case is a specific way that customers get value from your product. Why do your current customers use your product? What problems are they trying to solve? Key use cases should be fully documented, including steps the customer takes to complete the use case. Many use cases are specific to a particular segment.
These are requirements that describe how your product works to an outside user. This may include APIs, standards compliance, electrical specifications, functions, or other key features. Are any of the functional requirements specific to a certain geographical area? Many interoperability standards for software and hardware are defined by standards bodies with specific geographical oversight.
What is the pricing strategy for the current product? Do you use cost-based or value-based pricing? Is the price of your product mainly driven by a competitor? Are current competitors strong or weak in other geographic areas? Are there taxes or tarifs that affect the price in the current market? Any of these factors may change in the new market, so it is important to understand the current strategy.
How do you support current customers? How easy is it for customers to get support when using the product? Are support personnel located near the customer, or do they even work in customer facilities? Where are call centers located? What are support hours and turnaround time? Do you offer support forums or chat clients for support? Do you have a knowledge database of support issues and resolutions that may be used by internal personnel or customers themselves? In what languages do you offer support?
Are key features or services provided by a 3rd party? What are the geographical capabilities of your partners?
How do you currently sell your products? Do you sell direct, through distributors, or sales representatives? How do you train field personnel? What margins or commission are expected by each part of the channel? How long did it take to build relationships with the customer?
How do you select what features and capabilities are added to your products? Is there a requirements database? How are new enhancements prioritized? How is the roadmap communicated to customers?
How was your current UI (user interface) designed? What steps does the user take to complete key use cases? Do you have formal design guidelines for the UI?
You will discover many more requirements and issues with your business model as you begin to explore your new markets. However, by having your requirements and process documented, you can check your assumptions much more efficiently.