by Adam Asnes for Multilingual Computing
A local leadership conference a few years ago featured a live panel discussion including Eric Schmidt, CEO of Google, and Michael Moritz of Sequoia Capital, a Google’s investor and board member. The first question tossed out was: what makes a company great? Mr. Schmidt quickly answered, “Any great company will make over 50% of its revenue outside North America.” To which, Mr. Moritz fired back, “Yeah, but everybody’s always late on international products, particularly for Japan and China.”
Eureka! Here were two leaders of one of the most influential companies in recent business history singing my song. I wrote down that exchange and still use their quotes in many of my presentations.
So why are international products so often late? And what does that have to do with business greatness? We’ll tackle those questions in this article.
Software Globalization Delays
International products may be late, ranging from business agreements to product development. Your customer or distributor may have their own timetable and priorities that suddenly veer off from your needs.
But in the world of technology product development, there are very real ways to reduce delays – and risk – by accurately planning for and executing development efforts. Given what’s at stake, that’s a very serious question, which sometimes doesn’t get treated by product development teams with the gravity it warrants. When a company is late with a product, it has a very real impact on a company’s income, as well as its competitive position.
A simple exercise using round numbers bears this out. If the Acme company plans to adapt its software to accommodate new sales relationships in Germany and Japan, chances are, before a single developer begins to figure out the tactical aspects of internationalizing code, revenue projections are already set for that opportunity. Let’s say those agreements are worth $10 million in their targeted fiscal year, so a three-month delay reduces available revenue by one quarter, a substantial amount.
But it doesn’t stop there. There are a host of other costs involved. If Acme’s product is late, sales people, offices, marketing efforts and customers are waiting also. Entire teams, whose salaries and costs can’t be optimized until the release is ready, are idle. On top of that, the core development team internationalizing the software isn’t working on key new features for current customers, so there are significant hard costs as well as opportunity costs at stake.
Even with clear additional costs, let’s evaluate simple time to market effects on profit and loss (P&L). We’ll assume a general cost profile consistent with firms Lingoport has served in recent years. And we’ll assume that the product experiences only modest growth over a five-year timeframe.
The P&L below, showing the results both with and without i18n factored in, are below:
As shown, the firm stands to benefit substantially through reducing time to market alone – enjoying nearly 6% increases in both revenue and EBITDA, most of that impact occurring in year 1 of the analysis, with smaller advantage in each subsequent year. If higher sales growth expectations or the expected cost savings from the localization effort to produce these results were included, the impact would be even greater.
And most importantly, for this same product, the same financial improvementwould accrue to each subsequent localization project targeting other overseas markets. That could multiply the benefit by as much as 10 times, given the diverse international markets the average firm might address over time.
Considered from this perspective, development management should always consider enlisting some expert help when dealing with internationalization issues. After all, it may be the first or second time their team has actually planned for or executed an internationalization effort. Internationalization, almost without fail, ends up being more complex than any developer on the clients’ team anticipates. In fact, our 3 month lateness benchmark is likely conservative; the reality is often much worse.
The issue is critical enough that some large global technology companies have built internal internationalization departments that move from development team to team, helping make sure the effort goes as planned. Most companies don’t have broad enough product development needs to warrant growing internal resources, but a few – especially globally ambitious software leaders – do.
A very real world example from Lingoport’s experience involved a client with an online auction system for heavy road building and construction equipment. They simply had to have their product internationalized before the spring construction season started, or they would miss heavy seasonal demand. At the same time, their development group had other deliverables they had promised for their current customer base.
With Lingoport’s support services staff to help, it was a happy story of on-time delivery. But what if the client’s team had elected to struggle through internationalization themselves and been confronted by expensive and time-consuming surprises that inevitably occur when thye lacked the experience? Fortunately, the client’s engineering management, deeply experienced in commercial software development for global markets, saw that risk in advance. Not everyone is so lucky.
This is all familiar territory, in my firm’s experience. Internationalization is frequently underestimated and under-scheduled, for a variety of reasons. First, remember that software developers are a pretty smart bunch. After all, they built the software in question. Who knows it better than they do? Plus, they enjoy an interesting new technical challenge. So it’s natural for developers to conclude they can handle the effort themselves, without the inconvenience of dealing with outsourcing experts, developers or tools.
The reality is that internationalization involves much more than display-focused issues around language. Adapting software to support any locale – not simply the next locale – typically means big changes to how software operates, extensive changes to database schema, research and adaptation to third-party products, and refactoring locale-limiting methods within the code’s operations. There’s a whole new set of QA issues to plan for as well. Until you’ve been through internationalization over a number of technologies, from start to finish, it’s a notoriously hard process to estimate. Exacerbating the situation is the fact that many issues are buried in the large amounts of source code, hard to precisely identify. Lingoport’s Globalyzer software, for example, was built specifically for this issue; otherwise, developers are inclined to develop code analysis and search tools likely to be awkward at best in the identification process.
To help clients quickly get an idea of the internationalization health of their code base, Lingoport’s developed Globalyzer Diagnostics. We’re making it available free, and we’d love your take on it. It’s a simple-to-use utility that counts internationalization issues and reports on them for you, while giving you basic decision-supporting information about the extent of internationalization issues in your code. It provides a quick, easily understood code “health check”, specific to internationalization issues.
Understand how serious delays are to your company’s bottom line and market efforts. Know the revenue projections and business factors involved. Then make sure you go into internationalization with your eyes wide open to the potential for delays and the consequences and how to minimize the risk. Would you want the cost of being late to be on your head?