Selling to the international market is the obvious next step for software developers who have come up with a great product or technology and seen it achieve some success in Australia. Unfortunately, getting your brilliant piece of work onto the world stage requires more than just technical nous and the ability to get your Web site listed on Google.
Broadly speaking, the challenges which face developers seeking to expand overseas fall into two categories: technical and commercial. Most developers are aware that selling outside their home country can be difficult. "One of the bigger issues for small companies is that it seems very daunting to go international," notes Shane Williamson, partner manager for the development program at mobile network supplier 3 and a veteran observer of Australian developers.
While the commercial problems are often well recognised (and will be examined in detail in part two of this article), developers aren't always as cognisant of the fact that international success begins at the design and coding stage. "I've seen a lot of attempts fail because they don't bother to do their research and understand the reasons to take the software to other markets," says Williamson.
"If you've got a product you're going to take to market, you need to think of who the end user is," agrees Chris Eldrige, director of software engineering solutions at Dialect Solutions, a Brisbane-based company whose payment systems have been sold internationally. "Software engineers who are caught up in the technology can easily forget that."
 |
Subscribe to Builder Magazine This article first appeared in Builder Magazine. To subscribe to the free magazine visit our membership centre. |
"Developers don't always do a good job of explaining how a product is relevant to business," adds Graham Jones, head of Integrated Research. While IR's Prognosis system management programs were developed in Australia, the company always intended to sell them overseas, and spent more than two years on development and research before launching their first version.
"At the technical level, there were a lot of early decisions to make about strategy," says Jones, whose advice to budding international entrepreneurs is succinct: "Don't bite off more than you can chew." Differentiation isn't always a matter of purely technical skill. Gerard Carè, managing director for G+D Computing, whose Strand7 engineering product derives 50 per cent of its sales offshore, first spotted an obvious gap in the market 15 years ago: "The bigger products were more difficult to use."
Technical competence was an essential feature for an engineering package, but ease of use and consistency made it more appealing to users long-term.
Speaking in tongues
Perhaps the most visible challenge in attacking other countries is the language barrier: how easy will it be to develop a version of your product in French or Mandarin? "The biggest challenges historically have been the production of software that could provide double byte capabilities for languages such as Chinese, Thai and Japanese," says David Steny, business development manager for Tokuii, which develops relationship management software.
While this can seem tricky at first, the rise of Unicode as a basic standard has made matters rather simpler. "Make sure you support Unicode character sets from day one," advises Phil Morle, chief technology officer for Sharman Networks, whose Kazaa P2P tool has certainly succeeded in garnering international attention, albeit not always in a complimentary way. "Doing this later is complex and not doing it at all means you are limiting the regions you can localise your product to."
"If I was doing it all from scratch, I'd do everything Unicode, but that wasn't an option at the time," notes G+D's Carè. However, he also points out that not all overseas buyers are concerned about translation.
"In the engineering world, it's a highly educated target market. In most Western countries, language hasn't been an issue for us," he says. Even in China, many university students prefer software to be in English.
Jack Andrys, CEO of WebSpy, a listed company whose Internet monitoring software is sold across Europe, suggests that pursuing multilingual software is only worthwhile once you have a very large user base. "English has continued to be more and more acceptable," he says.
"The chances are you are never going to get the budget allocation to translate and localise your application into Estonian or Zulu, but the aggregation of all those smaller markets is a pretty big market," adds Sharman's Morle. "If you have done the job right in separating the locale-specific elements of your application, it should be easy enough to create tools to let users do their own localising and contribute their efforts."
Remember that translation requires more than just word matching.
"Localisation is much more than just getting a translation service to give you copy in the target language," says Todd Martin, executive producer for Amnesia Group, which develops multimedia marketing content across Asia.
"The language used must fit the purpose and sound like it comes from a knowledgeable local." Martin notes this is less of an issue for highly technical software: "The difficulties of marketing and language are probably not as critical for software developers as for designers. Software users are focusing on whether the product suits their needs rather than the nuances of communication to differing demographics."
If you do decide to develop multiple language versions, then you'll need to put in some extra effort in even if -- as seems likely -- you rely on third parties for the actual translations.
"Don't assume anything," says Morle. "Don't expect a word in one language to be the same size, or go in the same direction in other languages. Don't expect a comma in a string of numbers to mean the same thing someplace else."
The culture of abstraction
Outside of language, the next most obvious challenge for many international products is date formats: Australia and most European countries now use DDMMYY, but the US stubbornly persists with MMDDYY. While these differences are handled fairly well in most modern operating systems, be wary of making assumptions. For instance, the US military uses 'international' dates in the YYMMDD format.
This underlines the important point that software often requires subtle process changes. "A key component is how that software interacts with other systems -- the business logic often needs to be changed," says Richard Dowling, Rational technical manager for IBM ANZ. "You don't want two different applications. You want to use the same components."
"The expectations of scale will be different in larger markets," says Doug Bertinshaw, chief operating officer for Integrated Research. A product that works well in a typical Australian business may struggle as user loads soar.
Generally speaking, the best way to face these challenges is to plan your software to enable flexible redeployment for different markets. "Make sure that you only need to do things once. This is the number one rule," says Morle. "Keep application logic away from country-specific resources so that localising your product does not require re-writing the application."
"You've got to build your product so that's it's very flexible in terms of architecture," says Grant Straker, chief technical officer of Straker Interactive, whose content management system has been sold through New Zealand, Australia and Europe. "It's extremely difficult to retrofit a system to fit a new region or market," concurs Rational's Dowling.
Working with established technology frameworks can also aid in this process. "If you tailor your product on a standardised technology, and don't go branching off into some weird abstract programming language, you'll get a lot more global traction," says 3's Williamson.
One important area that is often overlooked is building extensive troubleshooting features into your architecture -- something that can make supporting offshore users much easier. "Too often, we don't think about those things until after the event," says Dialect Solutions' Eldridge. "People might be ditching your product and you won't know."
"You must build a high-level of supportability in your product," agrees IR's Jones.
A related issue is the need to have a good base of beta testers, and ideally to have them across the globe. "You are only going to get good results if you have testers," says Williamson.
Dealing with all these issues can take considerable time and resources -- and bear in mind that you haven't even started trying to sell the application yet. However, careful planning can eliminate much of the stress. As Dowling points out: "If it's a well-developed system and you understand what region you are targeting the application for, it won't be a major exercise."
In the next issue of Builder AU, we'll discuss how to pick your overseas target markets, plan a sales strategy and ensure that you're not overwhelmed by establishment or support costs.
Leave a comment