Product Management 101 for Localizers
How to partner with product teams to
bring your company global

BY Linh Nguyen

When it comes to product management and localization, there’s a lot of blog content out there from language service providers (LSPs) and localization publications on the process and tools. But it can be harder to find content from the other perspective: people on the product side. You know, the ones who make the product, like designers, engineers, and — well, the product manager.

Here, I’ll give a brief overview of product management from the perspective of a product manager.

We’ll also discuss the ways in which localization teams can partner with the product manager to bring company products to the global market.

So, let’s start with the basics.

What is product management?

Atlassian product manager, Sherif Mansour sums up the answer to this question rather succinctly:

“A product manager is the person who identifies the customer need and the larger business objectives that a product or feature will fulfill, articulates what success looks like for a product, and rallies a team to turn that vision into a reality.”

There’s a lot that goes into a product manager’s work. Essentially, you can count on the product manager to ship the product by any means necessary.

Martin Eriksson, a 20-year veteran product manager, defines product management as “the intersection between the functions business, technology, and user experience.” You might also hear the term EPD thrown across the board. That stands for engineering, product, and design. The product manager sits right in the middle of that equation.

Figure 1: The product manager sits at the intersection of UX, tech, and business. Credit: Martin Eriksson, 2011

When it comes to the day-to-day, the product manager can be seen finding and defining company goals, looking for product opportunities, planning product development, conducting user research with marketing, working with engineers to develop a solution and A/B test it, creating product requirement documents, and so on. The product manager has a hand in every aspect of the product from conception to launch.

The product manager might not be the only product person you encounter. Depending on the size of your company and team, you might also come across a product owner (PO) — someone who works more closely with delivery teams to build out the product — or even a product marketing manager (PMM), who focuses more on the product’s go-to-market plan.

Understanding the product manager

To better collaborate with product managers (and the PO and PMM), it’s crucial to get behind the psyche of the product manager: What are they chasing? What are their obstacles? What are their weaknesses?

According to Rocky Sharma, a three-time head of product and a product-led CEO, it’s not enough to make a product and deliver it “as is” around the world.

“People assume what works in one country would automatically work in another,” Sharma said. “The key is to understand the market and customer. Whenever you try to internationalize, the best way is to talk to customers in the country and adapt the product for them based on their needs.”

In an interview with five world-class product managers, a resounding focus for all of them was this: understanding the customer in their local market. It’s not enough to know the customers in your domestic market. It’s not enough to assume you even know your customers.

For David Grayson, a product manager at Facebook, the first order of business as a product manager is conducting user research and speaking with customers in the local market to get a better understanding of the unique locale. Every region is going to be different for different businesses. You can call it product-market fit. You can call it having a customer-centric mindset. You can call it conducting a buyer persona. For product managers, it’s all about getting to know the customers you are serving.

How localization can partner with product

A few pain points might come up when trying to serve customers on a global scale. Some of the more persistent thorns are:

  • Addressing differences in culture, religion, and tradition
  • Making adequate locale changes (currency, merchandise, language, design)
  • Overcoming other teams’ US-centric mindset when it comes to creating the product UI, design, or even code.
  • Managing multiple stakeholders that communicate in different ways across various functions like design, engineering, legal, help center, and localization.

Localization teams can do a lot to help product managers with the issues above. But there are also two more things that need to be addressed.

Not all product managers and cross-functional teams understand localization. And even fewer understand internationalization. Why is this a problem?

Without a basic understanding of localization, product managers can inadvertently leave localization out of the loop until the end (in other words, right before launch!) when they’ve filled in a month for localization to translate the product. Worse, inexperienced engineers might not even find out about internationalization bugs until the translations turn out inaccurate or don’t even show up at all on the UI.

Figure 2: An example of a simple product organization chart. Note that organization charts differ from company to company and team to team.

So how can localization teams partner with product teams and product managers to overcome this knowledge gap and deliver high-quality localized products that fit local markets?

In simple terms, upstream engagement, early on and as often as necessary.
More specifically, we can break down the work of upstream engagement into three categories: people, processes, and tools.

Upstream engagement: people

Know your product manager

Start with people first. Get to know your product manager and their team. Better yet, maintain a close relationship with your product team. Identify the stakeholders on your product teams aside from the product manager and PO.

Do you know your PM’s pain points? What about their launch plans or current initiatives? What are their roadblocks and their level of engagement with the localization team?

At the end of the day, know where you (localization) stand in their mind and their plans.

Understand the launch plan

From there, start from the beginning — the launch plan. Most product managers, when executing a new launch plan, will create something called a product requirements document (PRD). It might also be called a product wiki. In any case, this document is essentially the home page of the product. It explains the product — why they’re building it, its features and functionalities, the scope of work, timeline and more.

“I would like to have a localization team that’s … integrated into the research or requirements stage. Having them integrated to that and the rest of the product and engineering process,” Grayson said.

Here’s a brief outline of the kind of stuff you might see in a typical PRD, borrowed from The Product Book by Josh Anon and Carlos González de Villaumbrosia. For a more in-depth description of each section, I recommend you check out the book yourself.

Product Requirements Document Outline

  • Title
  • Change history
  • Overview
  • Objectives
  • Success metrics
  • Messaging
  • Timeline/release planning
  • Personas
  • Requirements/features in
  • Features out
  • Designs
  • Open issues
  • Q/A
  • Other considerations

There’s one thing missing from Anon and Villaumbrosia’s PRD outline that Grayson hinted at above: locales. We need to know where we’re launching this product or feature, right? Depending on legal, cultural, or even logistical reasons, the locales to be launched might not be the same locales that your company currently serves.

The product manager uses the PRD to get all important stakeholders aligned on plans and help the team understand the project. Now, who might need to see this PRD? Everyone that has a stake in product creation or decision making.

Yes, that also means you, the localization manager.

As the localization counterpart to the product line, the perfect time to collaborate with a product manager is once a product idea starts becoming action items in a launch plan.

Aude Moras, head of product at Tablecheck, says that one thing she does to ensure the product succeeds in the international market is to make sure that localization is part of the launch plan.
“You don’t want to get ready for the market and then two weeks before launch start thinking about localization,” Moras later added.

Thinking about localization starts at the launch plan. When the product manager sends over the PRD, they’ll solicit feedback from their stakeholders and address them. When reading the PRD, look over the sections but pay close attention to success metrics, messaging, timeline, and locales. These are possible feedback points from localization. Let’s dive into each in detail.

Success metrics

Every product launch should have success metrics — key
performance indicators (KPIs) that help product managers measure the success of the launch. Commonly tracked metrics include leads generated, website traffic and page views, news coverage, and more.

As a localization manager, you can suggest tracking localization-related metrics or helping the product manager determine localization-related KPIs to inform how well the product does not only domestically, but also internationally.


In the early stages of product planning, the messaging might not be fully fleshed out. Design will be taking that task on and localization can help with providing localizability checks on the content (more on that in process). But if there is content under messaging, it’s also up to the localization manager to think of the global customers while reviewing this portion of the PRD. Here are some questions to consider and discuss with product managers:

  • Could the current messaging in the source language be problematic or offensive in another culture if directly translated?
  • Will this messaging need to be transcreated?


Depending on how far the project planning is, the PRD might not have the full launch timeline yet. But if there is a semblance of which teams will do what by when, that’s an opportunity for localization to give feedback. As you review the timeline, ask yourself a few questions:

  1. Does the timeline account for internationalization (or is this not needed)?
  2. Is there adequate time built-in for localization and translation efforts?
  3. Is there adequate time built-in for localization quality assurance (LQA)?

If the answer to all of these questions is yes: Congratulations, you’ve got an awesome product manager who understands the importance of localization! If you’ve got any additional localization concerns that should be on the product manager’s radar, let them know early on in the process.

But if the answer is no, see if you can negotiate with the product manager a bit. Let them know the time you think is needed for internationalization/localization/LQA and why it’s necessary to elongate the launch plan. This is especially important if there isn’t enough time allotted for internationalization and LQA, which can often be overlooked and potentially lead to bad user experience (something product managers certainly don’t want).

As the project planning progresses, the product manager will start mapping milestones into a project management software, Gantt chart, or the like to track the project stages. Also called a launch readiness tracker, this project tracker is often shared with all the key stakeholders in cross-functional departments, including localization. Make sure there is enough time built in for the entire localization process in the tracker and if there are any upstream activities or dependencies in localization the product manager needs to be aware of.


As stated above, we need to know where we’re launching the product. Not only that, knowing which locales will be launched lets localization know:

  1. How many translators of which specializations will be needed on this project.
  2. Any technical debt or issues associated with certain locale repositories that need to be addressed before translation.
  3. Additional language resources to create if there are new locales to consider.
  4. Internationalization frameworks to use for time/date, currency, etc.

Be there for the kickoff meeting

After settling the launch plan, product managers will host a project kickoff meeting with stakeholders to align on the project goals and objectives. John Huân Vũ, product manager at PayPal, makes it a point to invite all the key stakeholders to this meeting, including his World Ready (i.e., localization) team.

When does a kickoff meeting usually happen?

“A kickoff is necessary when the initiative has been approved by leaders and product managers can explain the business value of it,” Huân Vũ said. “It’s when your dream becomes reality, and you know exactly what you need and what you want to do — that’s when you have the kickoff.”

Design, engineering, and marketing will be there. If you haven’t been invited to join a kickoff meeting before, ask your product manager to send you the invite. While the meeting isn’t for feedback, it’s important to meet the other stakeholders who will be working on the project and potentially collaborating with you during the localization stage.

And that’s all for understanding the launch plan. By offering valuable localization insights that help the product manager finalize their launch plan, you can transition from an operational role to that of a strategic product partner.

Give brown bag presentations

Another major win for making global products is when a localization manager identifies what localization and internationalization knowledge is missing from engineering and product teams and fills in those gaps through brown bag presentations.

Brown bag presentations are business casual meetings where employees come together to share their expertise on a particular topic. As you work with your product team, begin identifying where you see a need for clarification with a wider audience. Then, reach out to your product manager counterpart to see if the product team is open to attending a brown bag presentation where they can better understand localization or overcome certain internationalization bugs that continue to pop up.

While each team is different, here are some brown bag topics you might consider:

  • Localization 101: Explaining the cultural, linguistic, and other adaptations for global audiences
  • Internationalization 101: Exploring internationalization (i18n) best practices, including localizing strings and resources and how to prepare source code for translation
  • Automation: How translation technology connects with product technology
  • Translation Quality Assurance: An overview of LQA best practices and how to conduct in-context LQA testing
  • Company Localization Success Stories: Share how the company has previously taken their product global using localization best practices
  • Open Q/A Session: Hold a general session where attendees can ask questions about localization

By organizing brown bag presentations, the localization manager is able to involve not only the product manager but the entire engineering team working on the product. This facilitates a clearer understanding of each team’s work and fosters a closer partnership to achieve common goals.

On the flip side, if your product manager or the engineering team hosts one, attend if you can. You’ll earn their trust by demonstrating that you value their work and partnership. It might also help you better understand the product or even how you can improve your processes.

The point of brown bag presentations is to share knowledge and also to be open to receiving it.

Connect your product team and linguists

Another way to connect with your product team upstream is to have your product teams (manager, content designer, etc.) give a walkthrough of the product to your linguists before sending the product for translation.
Why do this?

Your linguists are your language and cultural experts. They can spot localizability issues from the source and save time downstream by raising those issues upfront. Also, by getting a walkthrough of the product from the creators themselves, your linguists get a better context and understanding of the product, which no doubt will help them during the translation process.

Upstream engagement: process

After developing a partnership with the product manager and product team, you can look at implementing localization-related processes that support the product development life cycle (PDLC) and enable a smooth global launch.

Conduct market research

Even before the product manager comes out with the launch plan, you can help them in the beginning stages of their work by offering support in conducting local market research.

One way is to reach out to your contacts (your vendor, linguists, etc.) in the interested markets to help your product manager get better context on things like: What’s the advertising like? What are the biggest brands in your industry? Do they use the same search engines? What’s their perception of foreign companies? What’s the average price range for X product?

Another way is to translate their market research documents. In-country surveys and user interviews are a few documents that might need to be translated.

Prioritize engineering tasks

Remember, your product manager is busy.

“As a product manager, I’ve got a million and one things to worry about, not to mention localization,” said Brian Trejo, a former product manager at GoPro.

They might miss a step or two when it comes to localization. So as a localization manager, here’s where you can step in and help prioritize the run list of engineering tasks related to localization. For example, engineers have to test the user flow, the website, and work on linguistic QA, and internationalization QA. If you are working with a product manager who is new to localization, they might not have built in extra time for LQA or might not know how long that could take. As a localization manager, you can provide a structural perspective of how and where localization should fit into engineering work.

Another way to prioritize engineering tasks is to prioritize reported LQA bugs. Identify the most pressing (payment pages in multiple languages defaulting back to English) and least pressing tasks (missing comma) that the engineering team needs to address.

  • How do you know how serious a bug is? Consider it from different factors:
  • How much would it cost the company if they left it alone?
  • How many users are affected by this bug?
  • What are possible results from this bug?

When communicating bugs to the engineering team, you can include those factors to prove the severity of the bug. This helps them prioritize what’s most important and streamline their work.

Provide localizability checks

Another overlooked challenge for product managers when putting out a global product is the product’s user interface (UI) and build. Aude brings up a common example of this — the culture of product UI and user experience (UX) in Asia and the West.

Due to differences in culture, appreciations of technology, and user expectations, among other factors, UI design can look vastly different in these two cultures, she explains. Generally speaking, modern western UI/ UX philosophy emphasizes a minimalist look with lots of white space. On the other hand, if you look at Japanese websites, you’ll find a lot more information and text.

In his article on design considerations in Japan and the US, Kyle Chow sums up the dilemma quite well:

“The best translators could be hired to produce superior translations. Lots of time could be spent choosing amazing replacement fonts and stylizing the English text to make it just as polished as the Japanese versions. But in the end, a company still might find their US target audience isn’t clicking on the ads very much because the amount of text on the graphics is ‘too much’ to be appealing for many people in their audience.”

So, what can a product manager do to reconcile these two vastly different UI approaches? In situations like the one above, it’s useful for a localization manager to provide localizability checks on the product UI.

“Localizability checks are performed to identify elements in source material that could potentially cause localization issues and lead to delays,” writes Emilia Soto Galindo. “The purpose of such checks is to ensure that text, images, and layouts are localization ready.”

If we think back to the UI scenario, what elements would you include in a localizability check? Consider the following:

  • Will this UI work in the target country?
  • If not, what needs to be changed?
  • Is all the text dynamic?
  • Are there images or graphics that are potential flags in the target country?

Conducting a localizability check on the product UI helps ensure the product manager that their hard work of developing the product for domestic audiences will still reach their international customers.

Another check you can do in the design or production phase is a localizability check on regional placeholders.

Some examples of placeholders are:

While some placeholders can be handled using globalization systems (for more information, Microsoft has a breadth of documentation), some might need to be manually checked for locale accuracy. For example, if you need to have a sample book title in English, it might look like Book Title. But in Chinese, it would look like 《Book Title》. And in Korean, it would look like 『Book Title』.

To ensure correct formatting of placeholders, you can ask the engineering team to send over their list of placeholders used in the product UI and share this document with your linguists to check the correct usage of placeholder per locale.

Upstream engagement: tools

Along with integrating localization processes into the product development life cycle, you can look at implementing localization tool automation and knowledge documentation to support the whole operation.


A win for both engineering and localization teams is integrating localization tools with company tools as much as possible.

Connect your translation management system (TMS) with the internal customer relationship management system (CRM) or string repository (GitHub, Bitbucket, etc.). This allows the developer to send translation files from the repository straight to the TMS for translation — no need for manual uploads and file fumbling.

Apart from simplifying the translation process, this automation saves product and localization teams time and money. Your engineering team will thank you for making translation requests easier on them and you’ll be happy that things are finally centralized. While a huge benefit for product and localization, these types of automations can get complicated, so the process of creating integrations could require help and collaboration from your engineering team and your TMS vendor.

If you haven’t already, you can also look to connect your TMS to your company’s issue-tracking software (Jira, Trello, Monday, etc.). It’s like creating a bridge between the dev world and the loc world.

Developers use issue-trackers to manage their tasks and bugs, but linguists and reviewers aren’t as used to these types of tools. Creating a direct connection from TMS to issue-tracking software makes it easy for linguists or reviewers to point out bugs from the TMS, for localization managers to cross-reference and prioritize bugs, and for developers to read it in the issue-tracker.

Some other integrations you can explore are:

  • TMS to data visualization tool (PowerBI, Tableau, etc.)
  • TMS to content visualization tool (Figma, AdobeXD, etc.)

Ultimately, the point of automation is not to complicate the process, but rather to allow the product manager to scale as the needs of the product grow.


I want to mention one last thing about tools to provide upstream engagement with product teams. It might seem simple, but documentation creates a solid foundation for common understanding. Create as much as you need and make it easily accessible to your product manager, dev teams — heck, even your other cross-functional stakeholders would find it useful!

Now I won’t go so far as to say that documentation is an art, but know that writing too little will leave your reader more confused and think of you as unhelpful, and too much will overwhelm them and possibly turn them off from you or from localization. Knowing when and where to insert documentation is also an important way to help product teams.

Here are some examples of types of documentation you might provide your product manager or product teams:

  • Localization + internationalization resources
  • Internationalization libraries
  • Your company’s localization process including the cadence and timelines
  • Translation request templates and instructions
  • Localization terms, if needed


Now we’re at the end of our journey around the product management world and our quest for developing an upstream partnership with product. You should have a solid grasp of what’s important to product managers and the people, processes, and tools that help them launch products globally.

But not only that — as you continue to collaborate with your product manager and product team as a partner instead of a provider, you’ll be able to help create products that are even better than their original iteration, products that are truly global in nature and speak to your unique audiences.

Linh Nguyen is a localization program manager at PayPal and a recent graduate from the localization management program at the Middlebury Institute of International



Subscribe to stay updated between magazine issues.

MultiLingual Media LLC