In the age of remote work, product teams can take a lot of forms and are no longer limited to the talent pool of a specific geographic area.
That means many of us are working closely every day with colleagues in completely different time zones while also building products for customers around the world.
And while the ability to connect, collaborate and sell internationally offers a wealth of opportunities, also comes with a whole world of intricacies and challenges.
My guest today is Craig Garassi, who has spent the past 30 years working for big tech companies like Amazon and Microsoft, and is now putting his experience to work as a career coach.
Given his background and current focus, Craig is more than familiar with some of the more delicate challenges of building and launching products internationally.
We discuss the considerations PMs, executives, and entrepreneurs need to be thinking about right now when working across borders, and how to make sure your best efforts don't get lost in translation.
Let's jump in. Welcome back to the Product Manager Podcast.
I'm here with Craig Garassi.
he is the career coach and founder of Tech PM Career Path.
Greg, thank you so much for joining us today.
Yeah, thanks Hannah.
It's great to be here.
Awesome. We all started out the way we always started things off.
Do you mind telling us a little bit about your background and how you got to where you are today?
Sure. So I have over 30 years experience in the tech industry.
I worked at Microsoft, Amazon, as well as some startups.
One was as small as about 20 or 30 people.
So working at a range of companies of different sizes.
I've moved through roles in terms of like technical project program as well as product management roles and you know senior technical program manager roles and specific to our topic today i worked on a variety of global products and i can give you kind of a brief overview of those they've ranged from you
know data warehouses that were used within the microsoft msn .com division at microsoft and also working on different B2B and B2C solutions, working on learning platforms.
So, for example, learning platforms that were used in 130 different countries with 13 ,000 educational institutions.
Also working at the Amazon on a retail division there, working specifically on AI and ML models and supporting tools around that.
And we can get into later about, you know, using AI and ML across different cultural boundaries and in different countries.
And now I'm a career coach for technical project program and product managers.
Awesome. Well, it's quite an interesting career trajectory.
It sounds like you have definitely got a lot of depth of experience in today's focus topic, which is cross -cultural product management, which I think right now that while many of us are working with remote teams is it's more critical than ever to kind of be mindful of some of these things to navigate.
So to get us kicked off, do you mind telling me a story that just puts in context why PMs benefit from a cross -cultural approach to their work?
So yeah, cross -cultural product management is important because, you know, it's obvious we live in a connected world.
Certainly ever since the internet exploded in about, you know, 1995, there was greater opportunity to collaborate across borders, but also to serve customers in different countries.
And the important thing about cross -cultural product management is that we can't assume that what works in one country will automatically work in another country.
So here's a story related to that online learning platform I mentioned earlier at Microsoft.
It was running in about 130 different countries, and we localized the platform into 15 different languages.
And one of those languages was Arabic, and that's a language that's a right -to -left language.
So some of the challenges we ran into there were, it's essentially taking your site and mirroring it.
So everything had to be reflected in a different way.
So for example, you know, the search box, we're familiar with typing in text in a search box and then off to the right, you have like a magnifying glass or a go icon or something like that.
Well, that UI had to be flipped such that they could enter text from the right to the left, and then on the left side is where you actually trigger the search, you know, clicking that search icon.
Also, in the West, we're familiar with visiting websites that have the navigation menu down the left -hand side.
Well, for Arabic, for example, we had to move that over to the right side and also realign that text within those menus on the right side as well.
So if we hadn't done that successfully, then we wouldn't be able to successfully serve our Arabic users on that platform.
And really the, you know, PMs benefit because, you know, they're better serving customers in other countries around the world.
Yeah, absolutely. We want our products to thrive, not just in our immediate vicinity.
So that's good to be thinking about these things at all times.
And of course, when we're thinking about things like this, this is really coming back to inclusive design and addressing the needs of users from different cultural and socioeconomic backgrounds.
We recently did an episode about accessible design as well.
So how can PMs embed this kind of thinking into the product lifecycle?
So inclusive design, that's important that you are taking the needs of people in different cultures and different socioeconomic backgrounds, taking them into account when you're working on the next product and certainly extending that product through different releases.
So of course, that includes things like languages, You know, localization of text, globalization for time, date, and currency formats, and also careful review of any imagery and icons to make sure that they're appropriate for that particular, you know, culture.
And of course, when we talk about inclusive design, we are including accessibility, for example, people who may have different impairments, that they can still, you know, use your software to achieve their goals, whether they're professional or personal goals.
And to embed that work into the product lifecycle, it may sound kind of waterfall -ish, but it really is PM at the beginning of that release thinking end -to -end about all of that work, what needs to be done to serve these different customers in different countries, and ensuring that you're taking time
to understand the needs of customers in different countries, you know, doing research, having time to analyze the results of that research.
And then, you know, even as you build the release, are you building in ways of gathering feedback, you know, the quantitative feedback, like, you know, click -through rates and things like that, as well as qualitative feedback, you know, are we having surveys or, you know, customer feedback or even just
getting feedback from customer support, from customers from those different countries who are calling in with difficulty using your product.
So I think that PM looking broad at the beginning of that release and planning in those activities and breaking that apart and of course executing forward.
Okay, this is very interesting to me and I like to kind of push a little bit further on, let's just use the example of the specifically the version of the product that had to speak to Arabic users.
What are some of the, I imagine, difficult to navigate challenges associated with conducting things like qualitative research when you're trying to serve a demographic that has very different communication standards than you?
Maybe you don't have anyone on your team that necessarily has a fluency with that language.
What are some of the challenges that you've encountered and how have you managed to overcome those?
So some of those challenges are getting enough people who are in those target markets to provide enough feedback.
If that's not possible.
Is there a subject matter expert who is at least familiar enough with the cultural norms and even localization standards for those particular countries?
So, for example, when I was working on that learning platform, we were lucky enough to have a guy who was able to read Hebrew, and Hebrew is also a right -to -left language.
So he was kind of an expert able to advise us on how we should make changes to the UI and what to expect in the UI overall and how things should be perceived overall.
So first, yeah, ideally, getting customers in that marketplace to provide feedback, and if not, then having a subject matter expert to provide feedback on how you should adjust for different countries.
That must be a unique challenge to overcome if you're, you know, targeting a specific market like that.
Let's get into some pretty significant challenges now that we're on the topic of challenges and opportunities within cross -cultural product management.
I want to kind of start off with the effective use of AI technology because this is a hot topic.
This is something that we're considering no matter what kind of product we're building and for what market.
So could you share some insights on using AI transfer learning to adapt a model that's trained in one cultural context and then allow it to be effective in another?
So an example of that is once you've trained a model to process data within a particular country, within a particular language, then it's really up to PM to determine are there opportunities to apply those same learnings to other countries.
Let me give some examples here around anomaly detection and I'll give examples that I think most of your listeners should be familiar with.
So let's say that we're developing an AI model for anomaly detection in the United States.
So some anomalies could be security intrusion detection like on a corporate network are bad actors trying to gain access to our corporate network and what do their traffic patterns look like and training a model to identify those traffic patterns.
And of course, those are anomalies because the vast majority of your traffic and your network is going to be from normal employees, or that, you know, those bad actors on your network are going to have slightly different traffic patterns.
Or even customer experience anomalies, that customers using your software or your website may have difficulties, and you may only hear from a very small percentage of those customers about problems or issues that they're having.
Or even like potential customer fraud, that's also anomaly detection because a very small number of customers are gonna try and use nefarious techniques to defraud companies.
So those are just some examples of anomalies overall.
Let's say that we've trained a model within the US.
For PM to determine, can we use this same model in another country, it's determining the overlap between those anomalies.
So, you know, are the security intrusion detection anomalies in other countries, are those similar enough to the anomalies that we've identified and trained the model in the U .S.?
Or even customer experience anomalies, is the website that we have in different countries, does it expose most of the same functionality?
And therefore, it's likely that customers in other countries may run into those same same issues in other countries.
Once you've trained a model for one country, it's determining is there enough overlap with other countries and the traffic that they're likely to experience there.
Also, you want to determine the effort estimation for data science to actually ready that model to run in other marketplaces.
So there you've got work to be done around translation.
So if we trained it in English U .S.
and we want to run it in France and Germany and Italy, for example, we have to determine, are we going to translate those languages first into English and run the model on it?
Or are we going to have models running for each of those specific languages?
So there are different things to consider in terms of the overall cost that's involved to achieve that benefit of running that model in different marketplaces.
and i would imagine even the translation poses its own unique challenges not just the cost but how can you kind of safeguard around the precision of the translation from one insight to the next it sounds to me like there's a lot of risk there that's involved do you have any other insights as far as
some of the kind of more meticulous challenges around working with multiple data sets in different languages yeah so one is what you had touched on which is the quality of the translation.
So if we're going to translate to other languages into that common language, let's say English, what is the quality of that translation overall?
And another one, of course, is the traffic patterns, the type of anomalies you're looking for.
Are those similar enough to what the model already knows in order to be successfully run in other countries?
And this goes into another area that we tend to focus a lot on the model itself.
Everybody talks about the model and all the math and the techniques, but there's a lot of supporting infrastructure around these models as well.
So for example, if we're going to audit our anomaly detection model, and we're going to have people internal to the company auditing some of these results to ensure that the model is providing a high degree of accuracy and reliability, well, there's going to be tools, you know, tagging tools that are necessary.
And those tagging tools are also going to be necessary to run in other countries as well, because you're probably going to have contacts in each of those countries who work for your company that are going to say, and yeah, for this customer anomaly or this customer fraud detection, the model is identifying
it correctly. They'll use that tagging UI, the interface internal to the company, so that you're continually getting feedback on how well the model's performing in those different countries.
And if it starts to diverge, you've, you know, transferred your learnings from the U .S.
to those other countries and you're getting feedback from your taggers, from your auditors, and you're seeing that the model isn't performing very well.
Well, that's a signal that you need to dive deeper into the data for that country to say, you know, why is the model not performing as well in these other countries?
So that's just some of the finer points around language translation and the supporting tools.
And those supporting tools do need to be able to be run in other countries in order for the model to be successful.
Yeah, really interesting considerations.
I did want to also dive into another major challenge, which, of course, would be regulatory compliance across borders.
We're talking about, you know, dealing with the legal obligations that you have that that is very diverse according to which countries you're operating in.
With laws like the EU's GDPR or the EU AI Act or some of the emerging U .S.
state -level privacy laws that are also kind of in the mix, how should PMs design data collection strategies that can remain compliant and ethical and still be effective?
Yeah. So those data collection approaches that really relies on PM working closely with their legal counsel, that they're going to need that in order to navigate through these different regulations.
Like you'd mentioned, there are different regulations in different countries.
There's the EU GDPR, General Data Protection Regulation that covers the 27 EU countries plus the UK.
And there's also recently the EU AI Act that went into effect August of last year.
So that covers organizations that are developing or using AI, and that categorizes AI models into five different categories.
And of course, there's at least California and Virginia, that there's the California Privacy Rights Act and the Virginia Consumer Data Protection Act that protects the collection of customer information, as well as how customers can go about changing that information, updating it, and also the deletion of their
personal data. So overall, those are just a few regulations to consider for cross -cultural product management.
And it's really a cross -company effort between PM working with their legal counsel, working with accounting, finance, and there could be other departments as well.
And that's just something that they need to think about early on and plan it into their release overall.
And of course, once legal and PM have decided on specifically what needs to be built, of course, those are detailed requirements, you know, user stories and epics for PM to actually break out and build with their engineering team.
Speaking of the engineering team, I'd like to move on to more internal topics related to cross -cultural product management, because we're talking a little bit now about, you know, how do we make our products functional for a variety of external users?
Obviously, we are also working with internal teams that can often span multiple countries, multiple time zones.
And so this is a really interesting topic for me is navigating these differences across the demographics that we're working closely with.
So what are some practical tips for bridging communication gaps when you're managing engineering teams or a variety of different ICs across different countries and varying work styles and cultural norms and all these other considerations dealing with folks across borders?
Well, first, I think it's determining if there are language differences between different team members.
So for example, when I was leading a team in China, they spoke pretty good English.
And they were very eager to deliver results.
And in early sprint planning meeting, going through the stories that needed to be built for that sprint, they didn't have any questions.
I saw a lot of nodding heads and a lot of agreement.
So I assumed that they knew what needed to be built for that release.
But as that sprint was proceeding and I started to see some of the deliverables, I realized that they didn't really understand the full requirements of what those user stories and what they really meant.
Even though you have, you know, your measurable criteria within those stories, I could see that they didn't fully understand what they meant on a larger scale.
So it's really, you know, testing for understanding to determine, you know, are there communication gaps?
You know, We just discussed a set of user stories.
What's your understanding of these stories?
Or even asking for these stories, how do you think that these relate to the project release overall?
And asking if there's any questions around, you know, do you see any concerns with these stories falling short of meeting full customer needs?
And another thing around communication gaps is being aware of cultural slang.
You figure every country has a certain amount of slang they use in their language.
Like in America, we'll use things like, you know, getting a ballpark estimate.
Well, ballparks don't exist in other countries.
That's a baseball park.
Or even things like, you know, tech savvy, for example.
So those communication gaps can sometimes be caused by shortcuts, you know, the slang that we tend to use.
So I'd be careful with that.
So there's just, you know, a couple of things that I would look for, test for understanding and, you know, be careful of the language that you're using.
You know, and I find kind of interesting about that.
it kind of forces us to look at how much jargon we integrate into our day -to -day communication is i think especially you know in this industry we're rife with jargon that happens to be a little bit opaque even for those in the industry locally has this kind of forced you to evaluate some of the terms
that you use even with your local teams with local teams not so much so i think that you know the local teams they were all u .s based or there are folks that had been living here for like a decade or so.
So there wasn't that much of a challenge.
Typically, it is with folks where they're still residing in a country outside the U .S.
or English as a second language.
And I found myself actually double -checking my emails.
If I was sending mail to a team member overseas, I would read through it two and three times just to make sure I wasn't assuming anything or putting slang in there and making sure that things were kind of objective, just to make sure that I was communicating as clearly as I could to team members in another
location. Because if you don't get it right, then you incur that dreaded 24 -hour delay.
They get their email.
When you're sleeping, they reply.
You get to the office the next day.
It just leads to further delays in the projects.
Yeah, I imagine so.
Yeah, and I can only imagine how some of the language that we use, closing the loop, for example, like these kind of analogies that are just so integrated into our day -to -day talk that it's hard even to catch them until you do that extra due diligence.
So that's that's really interesting.
That's very interesting as far as if you're overseeing a project and you're working with a number of different teams that are kind of working under your direction.
How about between teams?
Have you found any cases of needing to help foster collaboration and kind of integrate a better trust between international teams that are collaborating together?
Yeah. So there, it's understanding, you know, different attitudes or approaches towards work.
What I mean by that is, well, one really good example is deadlines, that some cultures will see deadlines as very kind of fluid and flexible and negotiable.
And, you know, as long as we deliver around that date, we're fine.
Whereas other cultures, I know, especially in the U .S., that a date means a date.
If we say we're going to deliver on July 30th, it's going to be that date.
So it's trying to understand the perspectives on dates.
And it's just testing for understanding as you're going through the overall roadmap of the schedule for that release, saying, what's your understanding of these dates?
You know, how critical do you see these dates?
How important are these dates for the project overall?
And also for trust.
I think there it comes down to public rewards and recognition and really understanding our public rewards.
Are they honored? How should public rewards be given?
Should public rewards be to an individual who contributed or there are different cultures where they actually prefer that a reward be given to the team overall rather than to a specific individual?
so just taking the time to do the research and understand you know how do different cultures see that and in terms of trust i think it's it's also understanding and recognizing different national holidays so for example people in china about february celebrate you know the spring festival they take
about a week or so off you know it's taking some time before that to congratulate them and of course planning around those dates to make sure that there's still coverage for your project and production, but also building that time into the schedule.
And also for folks from India, they celebrate Diwali in about November.
So taking time to congratulate and kind of, you know, celebrate those different holidays.
I think that that goes a long way towards building trust on a particular project.
Yeah, that's really interesting.
It must foster a really lovely cultural atmosphere as well.
Engineering teams specifically operating in remote or hybrid setups, how can PMs kind of ensure that the collaboration and accountability across those time zones and cultural boundaries remain seamless and everybody is accountable to everything and is able to respond in a timely manner?
Yeah, so in addition to those other areas that I mentioned in terms of reviewing the schedule, testing for understanding, those kind of concrete things, this is where we touch on PM's soft skills.
And this is really PM walking around.
So after you've kicked off that particular sprint, it's just talking to your local engineers who are working with engineers in other countries and other time zones and just asking, hey, how's it going overall?
How are things progressing in this area with this feature?
Is there anything holding you up?
How's it going working with so -and -so in another country?
And also PM checking in with their counterpart in that other country as well.
Sometimes there's like a main country lead, like a project manager or another program manager who's working directly with the engineers in that other country.
And it's just checking in with them, you know, either email or chat and sometimes just having informal meetings to say, how are things going from your end?
You know, are you think you're making good progress?
Were there any issues we need to discuss?
Is there anything blocking you?
Just asking kind of open ended questions.
And I think that those morale items that I mentioned earlier also help to build collaboration.
But I think that that seamless collaboration, that's kind of a combination of, you know, reviewing the schedule, what needs to be done, as well as practicing those soft skills.
Just walking around and having informal conversations with people locally, as well as your engineering staff in other locations.
Before you wrap up, I'm just so curious if you have any anecdotes of maybe a moment where you found it to be especially rewarding or really interesting to be working in an environment that kind of exposes you to all these different cultural norms.
Yeah, so that would be that learning platform that I mentioned earlier at Microsoft.
And that's just because it was so broad, covered so many different countries.
And localizing and globalizing a product like that in the 15 or so languages, it really exposed me to a lot of different cultural attitudes and different ways that they see the product.
But just overall, I guess some specific things even during localization.
So, for example, the German language, when you localize into the German language, it can be quite long.
The German, you know, verbiage.
So trying to fit new translated German verbiage into the existing UI, you may have to make some UI changes to extend dialogue boxes and menus and things like that.
So, you know, you learn a lot of interesting things just doing the work for other customers in other countries.
Oh, that's so fascinating.
I think it's just such a cool thing to be able to learn more about people and how people live and operate in different countries.
It's just very cool.
Craig, thank you so much for joining us.
This has been a really interesting conversation and we've caught a lot of different angles on this one here.
Where can people follow your work online if they'd like to learn more?
So they can either go to my website, techbmcrewpath .com, or they can look me up on LinkedIn.
Awesome. Well, thank you so much for joining us.
Thank you. Thanks for listening in.
For more great insights, how -to guides and tool reviews, subscribe to our newsletter at theproductmanager .com slash subscribe.
You can hear more conversations like this by subscribing to The Product Manager wherever you get your podcasts.
