[Free!] Deep Dive: Make the Business Case for i18n and Get Buy-In
Tech, localization, and global strategy - decoded.
In my last i18n focused post, I explained what internationalization (i18n) is and why it matters. If you haven’t read it, you can get caught up here.
This post is an example of what my “Deep Dive” posts look like. Deep Dive posts are monthly posts usually reserved for paid users, where I give a much more detailed, drilled down look at how I work and how you can implement process and templates that I use regularly. Since I already released a paid post this month, I decided to make this one free. If you find it useful, please consider becoming a paid subscriber for more posts like this every month.
Ok, so this time, we are taking the i18n basics from the previous post and diving a little deeper. I’ll cover how to frame i18n as a strategic business imperative in language that resonates with product, engineering, and executive leadership. I want you to walk away from this post feeling like you can frame the business case, clearly show the value, and have a practical roadmap in place to secure buy-in and funding.
First, Know Your Audience
But really, please don’t stalk anyone, follow my tips on how to know your audience instead :)
In my last post, we talked about how to create a shared vision and collect data on i18n issues. In another recent post How to Get Engineers to Care About Your Localization Ask, I dove into how to identify the right partner to work with (generally the decision maker), today I want to start this Deep Dive sharing the next step: how you can frame your message for your audience. If you’ve been following along, you now have a clear picture of what the key i18n issues are, you’ve brought your stakeholders in, you have some data and you’ve ramped up on key i18n solutions and libraries. But getting stakeholders to be on board with solutions can sometimes be the biggest hurdle to overcome. If you want people to care about [insert anything you want them to care about], you have to speak their language and make it relevant to them. Although we all know this, it’s sometimes hard to remember that different people care about different things, and also, we are all so insanely busy and overwhelmed with information, people aren’t always in the right headspace to take what you’re proposing and break it down to understand how it could help them in their own work. So you have to help them get there. PMs want to move fast and grow users. Engineers want clean, maintainable code. Leaders want to scale without surprises. Once you tie i18n to their actual goals/what matters to them, your message will land faster, and you will run into less friction. Alternatively, if it’s not a good fit you will hear about it right away and you can then tailor the solution (or the messaging) to work for that stakeholder’s needs.
So what does this actually look like? How should you tailor the message? Here are some examples by stakeholder, on how you can align your messaging with what matters to them:
Product Managers: Velocity, user growth, retention, hitting OKRs
Example:
“By investing in solid i18n foundations now, we can reduce the time it takes to launch localized features by 40%, enabling us to hit our Q4 growth OKR of expanding active users in Brazil and Germany. This will directly improve retention by offering a smoother experience that keeps international users engaged longer.”
Engineers: Code quality, maintainability, technical debt, automation
Example:
“Without proper i18n scaffolding, engineers spend 25% of their time fixing hardcoded strings and layout bugs that could have been avoided. Centralizing i18n infrastructure will reduce duplicated work, lower tech debt, and free up time for higher-value tasks like automation and innovation.”
Leadership: Scalability, brand integrity, risk mitigation, ROI
Example:
“Poor internationalization risks damaging our brand reputation in key markets and increases support costs due to user frustration. By prioritizing i18n now, we safeguard our global scalability, reduce costly post-launch fixes, and improve ROI by accelerating market entry with fewer delays.”
But what about a more niche situation, what if you are a linguist and you want to communicate i18n issues to a client?
Here’s a template framing the problem in a way that should resonate with your client, you can also look at examples above and tailor it further depending on if you key contact on the client’s side is a PM, Loc Manager, Engineer, etc:
Hi [Client Name], I wanted to flag a pattern we’ve been seeing across several recent projects that’s starting to affect translation quality and turnaround times. A lot of the content we’re receiving isn’t fully internationalized. For example we’re seeing hardcoded strings, unextracted UI text, and formats that don’t account for language expansion or RTL layouts.
Right now, we’re handling these manually, but it’s introducing delays, bugs, and extra costs on both sides. If you’re open to it, we’d love to partner with your engineering or product teams to help identify some lightweight i18n improvements. Even a few early changes could make your localization workflow much smoother and reduce rework later on.
This isn’t about asking for a big investment, it’s about laying the groundwork now so future launches are faster, cheaper, more scalable, and more accurate. Let me know if you'd like to set up a quick call to walk through what we’re seeing and how we can help.
You’re not selling “internationalization”. You’re selling:
Faster, lower-friction market entry
Reduced technical debt and rework
Fewer costly bugs in production
Consistently excellent experience for all users, everywhere
Second: Tie i18n to Goals like OKRs
Objectives and Key Results (OKRs) are a widely used goal-setting framework designed to align teams around clear, measurable outcomes. Objectives define what you want to achieve, while Key Results specify how success will be measured. This structure creates focus, transparency, and accountability across leadership and cross-functional teams.
By framing internationalization (i18n) goals as OKRs, you integrate them directly into the company’s core priorities alongside scalability, reliability, and user growth. This approach ensures that i18n is recognized as essential work rather than an optional add-on, helping to secure the resources and attention it requires.
OKRs are typically set collaboratively across different levels of an organization:
Leadership and Executives usually define high-level company or department-wide Objectives that align with the broader business strategy.
Product, Engineering, and Functional Teams then develop their own OKRs that support those high-level goals, focusing on the specific work they own.
Managers and Team Leads facilitate the process by aligning team members on Key Results and tracking progress regularly.
If you are in a position to set OKRs, you have a powerful opportunity to embed internationalization (i18n) into your team’s core objectives. Incorporate clear, measurable Key Results that tie i18n efforts to business impact, like faster market launches, improved user experience, or reduced technical debt.
If you’re not directly responsible for setting OKRs, focus on knowing your audience and tailoring your i18n recommendations to their priorities. Suggest specific OKRs framed in language that resonates (whether that’s product velocity for PMs, code quality for engineers, or risk mitigation for leadership). By speaking their language, you increase the chances that i18n goals will be adopted and supported in future planning cycles. You can use my free template below!
OKR Template: Internationalization and Global Readiness
Use this template to align i18n efforts with company goals and drive cross-functional accountability. Customize based on your team's scope and maturity level.
Objective
Improve product scalability and global readiness
Why this matters: Internationalization is foundational for growth in new markets. By embedding i18n into core workflows, we reduce friction, lower risk, and scale more efficiently.
Key Results
KR1: Reduce time to launch in new markets by [__] percent
Tip: Use previous launches as a baseline. Improvements can come from automation, standardized tooling, or early integration of i18n.
KR2: Localize top [__] user flows with zero critical i18n bugs
Tip: Define what counts as “critical” and track bug resolution velocity.
KR3: Integrate i18n checks into CI for all new [UI components, microservices, pipelines]
Tip: Partner with engineering to define automated checks for strings, formatting, RTL support, and more.
KR4: Increase percentage of active non-English users by [__] percent
Tip: Pull this data from product analytics tools to show business impact.
KR5: Eliminate [__] known i18n technical debt tickets
Tip: Identify and categorize i18n blockers in your current backlog.
Role-Specific Key Result Suggestions
Engineering
Externalize strings in 100 percent of new features
Add pseudo-locale testing for all new UI screens
Resolve 90 percent of i18n bugs flagged in QA within 7 days
Product
Launch features X, Y, and Z in parallel in [target markets]
Include i18n acceptance criteria in 100 percent of new feature specs
Reduce localization QA cycle time by [__] percent
Localization
Improve translation handoff quality score to [__] percent
Launch machine translation evaluation in [language or market]
Reduce translation rework caused by development bugs by [__] percent
Leadership or Business
Increase international user retention by [__] percent
Reduce launch delays caused by i18n blockers by [__] percent
Achieve [__] percent on internal Global Readiness Assessment
Planning Checklist
Include i18n in roadmap planning
Align with engineering and product on technical scope
Assign clear owners for each key result
Set up a regular reporting cadence (weekly or biweekly)
Review blockers and track progress in team rituals such as standups or sprint planning
Finally: Reframe i18n as Core Infrastructure (Not a Nice-to-Have!)
So now you’ve gotten their attention, you’re speaking their language, you’re showing how this creates business value. How do you position the ask? In my experience, at tech companies of all sizes and across a variety of areas, i18n as Core Infrastructure really resonates. Internationalization is often misunderstood as an “extra”, something you do after the launch, after the roadmap clears, after there’s a global expansion plan. That mindset kills momentum and buries i18n under years of tech debt.
Instead, position i18n as core infrastructure. It’s just as foundational as CI/CD pipelines, observability tooling, testing frameworks, or data architecture (if these words are intimidating, check out some of my prior posts where I explain each one in detail!). Core infra is invisible when it works, and SO painful when it doesn’t.
How to Reframe It in Practice
Reframing i18n as infrastructure is less about storytelling and more of a foundational shift on how your organization works. This won’t happen overnight, but its important to start talking about i18n as core infra. Here’s how to start turning that mindset into action:
1. Use Familiar Analogies
Goal: Help non-specialists see i18n the way they already understand other critical systems.
How to Execute:
In stakeholder meetings or roadmap reviews, replace abstract i18n terminology with metaphors from your audience’s world:
For engineers: “This is like shipping without test coverage.
For PMs: “It’s like launching a feature without analytics, you’re flying blind in international markets.”
For leadership: We’re trying to scale globally without a foundation.
Use these metaphors in slide decks, Jira comments, Slack threads, anywhere decisions get made.
Practice a few “i18n elevator pitches” tailored to common objections or priorities. Keep them short and repeatable.
2. Add i18n to Your Platform Tech Stack
Long Term Goal: Make i18n visible and non-optional, like auth, CI/CD, observability, or performance.
How to Execute:
When presenting technical architecture diagrams, explicitly call out i18n components:
Don’t know what an architecture diagram is? Check out “What is Infrastructure + Architecture and Why Do I Need to Know About It?”
String extraction and formatting systems
Locale-aware rendering libraries
Pluralization or RTL support
MT connectors or TMS integrations
In platform documentation, include i18n as a core responsibility of frontend/backend teams, not a downstream localization task.
If your org has an internal developer portal, create an i18n starter kit or checklist, just like you might have for API auth or logging. You can even go a step further and have an i18n deck be included in engineering onboarding.
Add i18n capabilities as “requirements” when building internal tools and platforms.
3. Include i18n in Postmortems and Root Cause Analyses
Goal: Normalize i18n as a point of failure and improvement.
How to Execute:
After any incident involving:
Bugs that only surfaced in localized versions
Broken layouts or flows in non-English markets
Delays in international launches
…ask: “Did a missing i18n check contribute to this?”
Create a template for postmortems that includes a line item like:
Was i18n/international usage a contributing factor?
Bring real examples to your next sprint review, team retro, or ops review. Even one or two visible incidents can shift perception fast.
4. Make It Part of Engineering Rituals
Goal: Embed i18n into the team's daily habits.
How to Execute:
Story acceptance criteria:
Add a default i18n checklist item to your Jira/Linear templates:✅ All user-facing strings externalized
✅ Locale-aware formatting for dates, numbers, currencies
✅ Layouts tested in at least one non-English language
Definition of Done (DoD):
Update your team’s DoD to include:“i18n support reviewed”
“No hardcoded content”
“Tested in RTL and long-string locales if applicable”
Engineering metrics:
Track lightweight indicators of i18n readiness, like:% of key components with locale support
% of production bugs tied to international usage
Time to localize a new feature
Sprint planning and reviews:
Ask: “What would this look like in German or Japanese?”
Build that into your definition of "done," not a future fix.
5. Elevate It in Tech Debt or Infra Reviews
Goal: Give i18n a seat at the table during cross-team planning and prioritization.
How to Execute:
When preparing for quarterly infra reviews or tech debt planning, include a section on global readiness:
Outline the current gaps
Estimate the cost of doing nothing
Share a short proposal for how to fix one or two issues
Use real data or anecdotes from support tickets, launch delays, or user complaints to make the case.
Frame it like any other infra investment:
“Fixing this reduces production bugs by X%.”
“Standardizing string handling will cut QA time by Y hours per release.”
Better yet, bundle i18n fixes into already-prioritized infra work:
If you’re rebuilding UI components → add locale handling
If you’re consolidating backend services → add formatting libraries now, not later
Conclusion + Take it one step at a time!
Wow, I know that was a lot to digest! Thanks for sticking with me all the way to the end of this post. I really hope you feel empowered to take at least one action from this and start building your own business case for i18n. This was a big brain dump based on years of experience, and honestly, it took me a long time to figure out how to put systems like this in place. So please don’t feel intimidated or overwhelmed. Just pick one thing that feels doable, try it out, and then move on to the next. One step at a time. Use the examples and templates shared here to build a new skill, start a conversations, influence planning… and (over time) you will drive meaningful change.
What’s Next?
Next week I’ll be breaking down more technical vocabulary, I haven’t decided on the topic yet, what do you suggest? You can check out previous technical vocabulary posts here: