Hello everyone. Since today’s guest comes with a Spanish educational background, not Hispanic but Spanish educational background, I thought it would be appropriate to start with the blooper in Spanish, and it’s a sign both in Spanish and English that says very simply, “Prohibido arrojar nada dentro del sanitario” which should be translated, “it is prohibited to throw anything in the toilet.”  Instead, the English translation says, “It is forbidden to throw nothing down the toilet” which is, of course, very descriptive. And what happens with double negatives and so forth? 

So, today’s guest is Ramsey Pryor. Ramsey is the founder of Port of Entry Partners, a strategic consultancy that helps software companies expand and thrive in international markets through market sizing and priority prioritization, from product localization to building up world-class teams and partner ecosystems and scaling up revenue. Ramsey and his team applied the frameworks and best practices used by the fastest-growing software companies and help you avoid costly mistakes. 

Prior to founding Port of Entry Partners, Ramsey was a software executive at IBM, Outblaze, and Register.com, and is a multi-time startup founder and entrepreneur. Ramsey has a BA in economics and Hispanic studies from Northwestern University and earned a bilingual MBA from IESE in Barcelona. 

He also hosts the International Expansion podcast, which covers the best practices and lessons learned the hard way by some of the best-known software companies. 

Welcome, Ramsey. I’m glad that you can join us. 

Thank you, Philip. Thanks for having me. It’s my pleasure. 

So, let’s start with what your bio talks about: What are some of the best practices in the software field when it comes to going into international markets? 

Well, Philip, I’ve been in software for pretty much my whole career, and when I started, there was something that was referred to as the “waterfall method” of software development, which basically meant that if you were going to build an application or some sort of software product, you had to hire somebody whose job it was to write a really long document about everything that it should do and how it should behave, and when that person was done, they’d hand that over to a design team, which would figure out what the screen should look like and design it. 

And it, and then that team, when they were finished, would hand it over to a bunch of software engineers to go build it, and then the thing would come out, and, no surprise, there were a lot of things that people hadn’t considered that it doesn’t do or doesn’t do well. That was the water flow method. And then, fortunately for everybody, a new methodology came around called Agile, and the Agile methodology is really the opposite of that in many ways, where instead of building one big monolithic thing in sequence, you build really small pieces and have your cross-functional team work together instead of working separately and throwing things over the wall.

And the good news about that was that it was built in time to make improvements along the way and to figure out, OK, now that we’ve seen it, touched it, and used it, what should come next, and that allows you to fix things that didn’t work, allows you to insert new ideas that you hadn’t even thought of before, and just lets you play a lot more a set of scenarios through the software before it was considered done, and that was a huge leap forward for just software in general. 

But what I think are the best practices that I’ve seen happening in terms of how software companies go international are very much in that vein.

Ten years ago, if a company was doing really well in the US or in their home market, they would hit this threshold where they would say, “Hey, we’re doing so well here, why don’t we take this show on the road?” and U.S. companies would often start thinking about maybe putting an office in Canada or, wow, maybe even an office in London or Ireland or Australia If you’re really adventurous.

These days, software companies are thinking about that from the very start. And instead of erecting these massive monolithic structures and hoping that all of their estimates and forecasts were correct, you can do things in much smaller pieces. You can test the waters before you make really big investments, and you can let the data tell you where to double down, where to pause, or where to retreat, rather than trying to make all those predictions upfront. In a nutshell, I would say that thought processes and methodology is the big picture of best practices for international expansion and software.

So, it’s partially a modular approach. I know that software developers create the modules that they piece together and then go into countries and let the data decide where to expand and where to go from there. 

That’s right. 

And I think that taking that philosophy down a level into the day-to-day, companies that do this the best build things into the product up front. So, even before they are in ten languages, they made plumbing international. They’re prepared for that, and then something that is a definite best practice, and it’s often referred to as “internationalization.” It’s building the capability for that. 

And from a stack perspective, usually software companies these days are put together like Legos, so they don’t build a payment system, and they don’t build all the plugins. They select pieces that will complement one another, and anticipate that you will be in multiple markets and take local currencies. These are available in many languages, and you know you would build your stack a certain way from the beginning to optimize for a future state where you are in multiple markets, and you can even do that from an operational perspective. When you think about growing your team, one of the questions I always ask clients is: What percentage of your company’s revenue, customers, and end users do you expect to generate in ten years, assuming everything goes as planned? The continent level? How many will be in the Americas? How many will be in Europe? How many people will be in Asia? 

And you know, these days I never hear any company say, “Well, the majority of any of those things is going to be in my home market.” Even U.S. companies anticipate if what they’re doing is actually global, maybe the US is worth 40% of all things in the fullness of time or maybe 50%, but it’s not 80%, and if you know that going in and really internalize it, you’ll probably do some things differently as you build your product, your team, and your stack to prepare for it. 

Yeah, that’s very true. And that’s actually unique in that unlike most businesses, software companies seem very progressive in thinking internationally to begin with, and preparing for that to begin with. As you know, I run a language translation and localization firm. Of course, we get clients who come to us and ask, “Can you localize our website or translate the software?”

And very rarely, we find that there are program designs that simply cannot be localized, when you can’t extract the text and the plumbing is not there to put it in other languages. So, it’s wonderful to know that most software companies do think of this in advance because many other firms and other industries do not think of those pieces in advance.

Of course, one of the questions I would want to ask is what happens when these practices are not followed. But it seems that these practices are generally followed now. So perhaps that question doesn’t apply, but I suppose then I could ask what kind of mistakes companies have made when they develop international software. 

Well, I wish it were the case that all companies thought completely global from the start and didn’t have these problems or consequences, but I come across very few companies that do it all upfront or make those investments all upfront. 

The best companies will do a couple of those, but it’s really interesting to talk company to company and to see who’s really good at which piece of this and is the most forward-thinking. But in terms of building the internationalization plumbing upfront, plenty of companies don’t do that, or, you know, their companies have been around for a while but are only now expanding and realizing the need for it. 

And I’ve been in that situation myself, and the pain point that you run into then is that you have to ask your product team to halt the presses for four or six months. You go and build that plumbing in, and at that point, that’s an expensive ask. There are a lot of things and new features that you know people are waiting for. There has been a mile-long list of customer requests of this type for years. Things must be prioritized, and getting that done is really, really hard. 

And so either you’re taking a lot of things off hold to go and do that, or you have these arguments about, “Well, why don’t we just use Google Translate and call it a day?” And you know, people who are out in the field know that it’s not that simple. So, you know something suffers as a result, and it’s much better to do it correctly. 

You know, the consequence of not thinking ahead is that you often end up with massive teams that are really based wherever you started. But they’re being asked to support multiple regions as you become international and so as a result, people are staying up late or receiving assistance from a region that, yeah, they don’t really understand if the people they’re speaking with are not located there. All they’re going to do is get a job supporting them. They don’t understand the local context. You know, people always want to talk to someone who’s in their region, speaks their language, and is contextually in the same ballpark. 

And if I think that a company is thinking well ahead and hopes to have customers in Europe and Asia. Well, maybe as you’re building your support team or your inside sales team, which can really be anywhere, you might as well go ahead and start taking advantage of the global market in place of spreading your team out a little bit so that they can support multiple time zones from the beginning, and, those people can also give you great insight into the markets that you’re going to be going into. They can tell you what good competition looks like. They can tell you about local pricing. They can tell you about so many things that are very difficult to detect. By reading reports or taking a flight every now and then.

Yes, that is correct. 

One of the first rules of international business, which a lot of people don’t think about, is to have support teams in the same country or at least on the same continent. You know you can launch something in Portuguese for Portugal, but at least have that support center somewhere in the European Union, because it’s the same time zone, and so forth. 

And a lot of companies that go internationally don’t think of this, and you know what it’s like… It’s like you buy furniture from IKEA or something and try to assemble it, but the instructions are in Chinese. Why can’t you call someone in Taiwan to figure out why this is poorly translated and how this really goes together? 

It’s something obvious that most people don’t consider, so it’s wonderful that a lot of software companies do think of it now. Other software components of Globalization are basically internationalization, globalization, and acculturation. These are, and what I found in the language business is that these are words that are very misused, or if not misunderstood, certainly used in different ways and people define the terms in different ways. 

So how would you define these terms: internationalization and globalization. 

Probably poorly because I know that companies such as yours know this, and I probably butchered these terms. I’ll actually give credit to Natalie Kelly, who has a great blog on this. She’s the head of International over at HubSpot. You know, she has burned these simple ways of thinking into my head. 

So, when I think of globalization, I think of frameworks. When I think of internationalization, that’s your code layer. And when I think of localization, that’s really the product experience, and the translation is when you’re adapting the message.

And so, you know, I don’t know if those definitions resonate with you. I do appreciate that people look at these terms differently, but that’s my cheat sheet. And that’s the way I think about them.  

That’s fine as long as you all are communicating in the same way and understand each other. I was laughing earlier because when you were talking about the ways of building software, I was thinking of a wonderful town where I used to live in southern Africa. I lived there for two years. Mmabatho is the name of the town, and it was growing so quickly that houses appeared almost overnight. I would drive along a road and a week later, I would have a detour because I would have driven through someone’s living room: There was now a house there.

And what I found was that it was delightful to see all the development, but then the town planners conveniently forgot to put in the sewers, so they had to tear up all of the roads that they had paved to put in the sewer lines to then connect them to the houses—so you know, in one of these situations, you’re growing so fast and what do you think of? And then, oops, go back and do some basics. 

It’s a literal consequence of exactly what we’re talking about. But yeah, absolutely. And I think that one of the things that I also see happening is just not being aware of, you know, time zones. And I’ve worked in tech from a lot of different locations, and I’ve noticed that somebody’s always in the dark. Someone is always working during the evenings and weekends. It’s inevitable. If we sleep for eight hours and you’re covering, you know, three time zones or sleep zones.

And you know what I’ve noticed is that it’s actually very easy to work with from the West Coast; from the East Coast, it’s a little more difficult. You know you’re especially popular with East Coast businesses. They find it very easy to work with London and that headquarters and to fly back and forth. But in Asia, the connection tends to be infrequent, in the evenings and weekends, which is unfortunate in some ways. 

So, I think that’s the other thing to kind of consider upfront. Which groups, teams, and regions need to be talking to each other? Are you making the investments, and are you putting people in places that will make that easy or difficult? It’s a simple thing to understand the time zone issue, but in practice, it’s one of the most painful.  

Very true. And, of course, from the West Coast, our morning is the afternoon in Asia. So, count on that; they’ve already had their sleep, and hopefully, they’re wide awake by now. 

They’re seeing the future for you.

Seeing the future. Exactly. 

Are your clients mainly B2B or B2C? And do you advise your clients to acculturate in specific countries? You’ve mentioned this to some extent, so can you give us some examples of how they have assimilated into different countries? 

So, I have clients that are both B2B and B2C. My personal experience is a lot deeper on the B2B side, and I think, generalizing, I would say that B2B companies have an easier time going into markets. I think, especially for software companies, if you’re selling to a technical audience, a lot of engineers and product people are used to reading documents and dealing with websites that are in English, and even at Apple, I think a lot of their documentation is only in English. So, they’ve kind of trained the world that you’re going to have to read technical documents in English. 

You can get a lot further with those around the world who speak English if you’re selling to businesses. If you’re putting a consumer-center product into a global market, I think that is a lot trickier and requires a lot more cultural or localization, and it’s very difficult if it’s the exact same product in all markets. It’s not just a matter of language; it’s the cultural context that is going to determine whether a communication tool is adopted by a group.

A lot of that is difficult to understand as a group, especially after having launched my own product into the world via app stores. Certain parts of the world were loving your product, and other parts were not at all, and it was very interesting and challenging to unpack why that would be. 

So, I think it’s a lot harder. One best practice that I heard of came from a company that launched during the pandemic. So yeah, they had no option but to kind of launch it as a completely remote company, and they launched it globally, as they took as much language out of the actual interface in the experience as possible. 

As a result, rather than using words, in order to explain how it works and what to do in words, they made it extremely graphic. They made heavy use of emojis and imagery and took as much verbiage out of it as possible, and I think that’s brilliant, and they even were able to penetrate markets that most people think are the hardest like Korea and Japan. They got a lot of adoption there up front, and I think that a lot of the credit goes to the fact that they took language out of the equation out of the picture so that was pretty interesting to me.

But I would say that, yeah, B2B companies can get a lot further with less localization when they’re going into Europe, and your team’s always going to ask for it. And you know where it seems to matter the most: France and Germany. 

But I think you can get a lot done and treat that as a kind of … once you have the traction and the business case, that can come a bit later, but I don’t think you can do that when you’re B2C. 

While speaking of languages, I know one of the issues because we’ve translated for software. One of the issues is the character limitation within a certain field. A German word, for example, is this long compared to an English word. And how do you make it fit? The big German word fits into this larger field. Also, German does not abbreviate very well. What other kinds of language issues have you encountered, especially with B2C companies? 

That example you have is really great, and I think it’s eye-opening. A lot of people don’t think about the fact that there’s so much information that you’re displaying in tables, and those tables were built with probably English or one language in mind. 

And you’re correct: if you put German in there, Dutch in there, or a right-to-left character set in there, you’ll realize that your design doesn’t work, and there are some solutions out there that will allow you to test things like tables and word wrapping and things like that, so that’s a best practice that I actually became aware of just recently but that makes tons of sense. 

I think the other thing is that many people will remember or are aware that date formats and other things like that differ. But if you’re taking payments, the way that people put address information in one place may not make any sense in another place. Again, I’d treat it like a Lego piece rather than attempting to build and figure out all of these things the hard way wherever possible. 

So using a payment processor that does all of that for you is already available in the locations that have weird address formats or that accept currencies that you never want to have to go and build for is probably worth doing that upfront. 

And I was trying to think of an example that a friend of mine over at Shopify gave of the way that worked. I worked in forms that were so different in Japan, but I would just say that I think the best practice here is to think about the markets you want to go into and make products for them. Make certain that you’re getting feedback from someone who is native to that language and culture before declaring your user interface finished. Otherwise, you’re just going to have problems later. 

When we first started over 30 years ago – this was not for a software product; it was a consumer catalog for girls’ clothes.The company asked us to translate it into Japanese, and they had four spaces for referring a friend. 

One of the first things we had to tell the client –and this is acculturation or localization – is that it’s something you never use. You never say “four” of anything in Japanese, Korean, or Chinese because the word for “four” sounds exactly like or very close to the word for “death”. It’s like in English “see” and “sea” or “there, their, and they’re”. So, you never have four of anything. You have three or five, but not four. 

That’s fascinating.  

So that’s just another tip for your clients as well. What are some of the largest difficulties—you’ve alluded to this – but what are some of the largest difficulties that software firms typically face when they enter international markets? Is it the software itself? Is it the marketing? Is it the support? Or is it something else? 

Yes, I think it’s a combination of all of those. I’d say that the biggest, highest-level problem is knowing what to expect when going into a new market, that it’s always going to be harder than your home market, not easier. 

And there’s sort of a discount that needs to be applied to what your addressable market is based on how much you are not catering to the local audience. I think that you know that the big decision you have to make as a company is whether you’re going to optimize for taking one code base and one product and optimizing for speed and taking that everywhere and assuming that it will fit as it is. Or whether you want to allow for adaptation and localization, and if so, that’s going to come at the cost of speed perhaps, but it’s going to give you the benefit of being able to serve a greater proportion of the audience. 

So, I think you have to pick where you want to be on that continuum. And then with that information, you have to make an estimate of what your addressable market really looks like given where you are on that curve. And then you need to put in some real targets; a lot in any market when you first start, it’s up into the right and the last quarter is significantly better than the previous one forever, and it becomes really hard to know whether you are actually doing well or not. 

Unless everything is going swimmingly, this is probably the most difficult thing to understand. I remember when I first opened up a team in an office in China, things were going so much better than we could have expected, but the problem was we didn’t really know. OK. Well, our expectations were maybe too low, but how high should they be? 

And over time, we found out—well, actually, even though the business coming from the partner channel looks pretty good. You look at a couple of other companies, and it’s even higher there. So, I think knowing what good really should look like is the hardest thing to do when going into a new market. 

That’s fascinating, too. Thank you. 

In business, the number one rule is not to anger your customers, and you obviously want to entice them. You want to make your customers happy. But in my experience as a software user, many of them aren’t. Programmers don’t seem to understand the rule that “thou shalt not anger your customer.” 

They have errors that are so common; they just create immense frustration. Step number one is “Go to this icon.” But where is this icon? Show me the location of this icon on the keyboard or screen. So, I’m curious: Do all software developers drink from the same water cooler, or is there something that many of them, but not all, think about? They feel the same way. They think of themselves as programmers rather than customers. 

So, when you say there are a couple of things that make me wonder if they are factors in this type of experience you’ve met one. Is this a waterfall-type of thing where somebody dreamed up what the product should do? It made sense to that one person. They handed it off. They built exactly what that person asked for, and it worked for them but didn’t work for a lot of other people including you. So maybe that’s why, and there, you know, I think software companies need to be able to take feedback when things are confusing, to detect it, and to act on it. 

But the problem persists, and I believe I am to blame. When you have a product that is being rolled out globally, you’re going to hear feedback from a lot of different places, and sometimes that feedback is conflicting. What is confusing to one person may be great to another, or it may simply be competing with a slew of other things on the product roadmap, and the challenge I frequently face was that customers in China are customers in this one. And unlike every other place, this thing is really important to them. And if your headquarters and your product team are in the US and they haven’t heard of those customers and they’ve never seen that request before, it’s really hard to get that thing prioritized. So, yeah, I’m not sure if you’re the complaining customer from a region where their team isn’t located, and they’re just not very sympathetic to your request, or if it was built via waterfall, you know, by someone for whom that made perfect sense. But maybe it’s a combination of both. 

But I think it has a former product person. I can understand how that happens. You know, I empathize with it, but I think the best practice there is that you’ve got to build in the ability to detect dissatisfaction, and then you’ve got to have the capability to improve the things that you’re hearing are very broken for some people. 

Do these companies normally test with things like focus groups? I’ve been in a focused group for a software product, and I was delighted. That company seemed so enlightened, but so many companies don’t seem to do that. 

Well, it’s funny because when I started my career, it was testing software. When you’re stressed out from college, that’s usually where they put you. Yes, I think that every piece of software is generally tested. Is it tested heavily, and is it scaling in multiple locations? Not usually. 

Although I would say that, again, it is a service. You know that what used to be the thing that everybody had to do themselves has become a service. There’s testing as a service, and hopefully, those testing companies are running this in places like Japan where there are a lot of particular needs around the way that things are displayed and doing it in multiple cultures and all that sort of thing. 

But not every software company, you know, has the budget or is truly the best in class. But, hopefully, only the best in class are doing so. And my friends who work at large software companies have the budget, awareness, and skill to do good testing. 

Yeah, well, that’s why they’re very large companies. 

Indeed

Everything goes together. It also seems to be a common practice, at least in the United States, that companies have a predetermined launch date for their products, and then back up into that. But if the product is not fully tested or ready, they’ll release it anyway, bugs and all. And then go back in the second and third iterations to fix the bugs, whereas other developers, particularly Europeans, will not launch until the bugs are worked out. 

And so again, it creates a sense of customer service, and thinking from the client’s point of view. Do you think that U.S. companies adopt different practices when releasing their software abroad, or do they tend to follow the US practice of having a fixed start date and whatever there is, is launched?

I think the fixed start date or fixed kind of release date is often something you see with public companies because they promised shareholders that they would have something out by Q2, and they’re going to put it out there one way or the other. 

I think that that kind of constraint feels like a promise that’s been made to someone who’s probably a shareholder in the market or to a board. And of course, that’s going to distort reality. It’s rare or impossible that the date that was promised is the date when the product is truly in its best shape. If you’re lucky, it will fall on the date, but you know that in reality, it will be either before or after. 

Things never go away. Very rarely do you bake in enough time according to your timelines to ensure that it is wet by the time that date arrives. So, I would say that’s probably a public company scenario. 

And I believe there is simply a greater acceptance of the fact that there have been many companies and examples of software that have been rolled out prematurely. We’ve seen that from the very biggest U.S. companies—the Apples, the Tesla’s—and we’ll even say, “Yeah, well, we had to.” We had to hit the date for whatever it was, and perhaps that’s not as tolerable in other places. And one of the things that comes to mind, that many people told me before we went to Japan, is that you only get a first chance or one chance to make a first impression there, and you can’t mess it up. 

And you know, I think that’s the kind of place where the last thing you want to do is be deadline-specific, and roll something out that’s premature. And I think that maybe, coming back to your point, maybe in Europe too, it’s a very bad look to try to take something that isn’t fully baked out there. I think there’s more tolerance for that sort of thing in the US. 

Yeah, I think it’s more German than for other Europeans. 

Is there anything else you’d like to add before we wrap up? 

I just really enjoy these types of discussions. I’m happy that you’re building awareness for the terminology that we went through and just sort of the best practices. You asked me a lot of questions about the best practices I’ve seen. I’m sure that you guys come across a lot of best practices. 

And maybe the thing that we didn’t talk about, if there are listeners that are not as versed in this, is that I recently sat in on a localization and transcreation discussion, and I didn’t know those terms very well. But it was the example they gave that really opened my eyes. This was to get to the point about the distinction between translation and doing. Actually, a proper job and I’m sure I’m butchering the term, but doing the content right for the context, audience, and culture—as in Harley-Davidson—And you know, a lot of the marketing message that we see in the US revolves around these ideas of freedom and open highways, as well as this culture of rebellion. 

Of course, Harley-Davidson is a company that wants its products to be available. But if you did a masterful job of translating that campaign, and then you took that campaign to a place that doesn’t have open highways and where there is no cultural resonance of rebellion, and, you know, maybe rebellion is actually going to turn someone off, then that’s going to fail. 

And I think that whatever company you are, you can probably translate that failure into your own. The context, what you’re selling, and the message that you might be putting out there is just wrong. It’s wrong for the people that you’re giving it to.

And I had this experience in Germany. You know, the things we were doing and the message we were spreading were very aspirational, and they were really tugging on your desire to be the best or something along those lines. And what we found out was that what we really needed to be talking about was much more concrete and practical data-driven messages, or else they’re just not going to land. 

So, I think coming back to your forte, Getting it right is really the next level. It’s one thing to put in the plumbing; it’s another thing to think long-term about being international and global and what all that means. But when you’re actually entering the market, you have to do a good job. Not just getting the words right but getting the message right within the local context—and I think that’s where you guys are experts. 

Yes, that’s very true. First and foremost, we are experts. But secondly, you use the word “transcreation,” which is a word that was invented by some geek in a language company. When I first heard it, I had absolutely no idea what it meant, and I never used the word in our company because it needs a translation by itself. 

For “transcreation,” we use the word “acculturation,” which is a word from sociology that more people would understand, and that’s exactly what you’re talking about. 

This Harley-Davidson and macho culture thing is fine in a country with wide open spaces and massive highways, like ours or Canada. Those values and they are ultimate values, do not translate and do not work in other cultures that have totally different value systems. 

The other part of Harley-Davidson is the motorcycle culture, which is, you know, rugged. Individualism is a very negative concept in a lot of collective cultures where the group is much more important, and that, frankly, is most of the world: Certainly, the Middle East, India, the Indian subcontinent, East Asia, Africa, and Latin America, for example. 

So yes, when we have seen cases where people have translated their websites into English, and it’s a direct translation from their language; someone in their company translated it. You know who…as we say, Maria down the hall who used to live there. Well, Maria down the hall translated into American English. But it’s totally wrong for the United States. It was totally wrong for American culture. 

And similarly, companies need to be mindful that the cultural messages that resonate here do not necessarily resonate in the target country. And that’s where the acculturation comes in. And, you know, that’s where the software expertise comes in to ensure that not only the characters fit, but that the concepts work as well. 

For example, if you’re talking about something in Latin America, there should be an emphasis on the family. If you’re talking to Germans, as you said, it’s something very, very practical, data-driven, factual, and so forth. And in Asia, it’s about the group and the harmony of the group and how everyone can work together and so forth. 

So, these are very critical issues that a lot of companies don’t think about, and it’s wonderful that your firm does. And It’s great that you have the foresight to make those recommendations to your clients. 

Thank you. Yeah, I just see so many companies these days getting excited about generative AI Chat GPT, and oh, can’t we just have this AI develop all of this copy? And I think that’s the part we’ll be missing, at least at this early stage if they take that approach. 

Well, I hope these companies are wise enough to come to us, and we’ll be delighted to fix them. I

Thank you. This has been a wonderful talk with Ramsey Pryor of Port of Entry Partners, and I’m Philip Outback of Auerbach International (www.auerbach-intl.com). I hope you’ll join us next week for another edition of Global Gurus and their stories of international business. Thank you.