What Language Do You Speak?

Knowledge / Inspiration

What Language Do You Speak?

Enabling the Team
UXDX Europe 2020
Slides

As Product Managers, we need to ensure we're building great products to satisfy a user need or solve a problem.
For this, we need to understand our users and stakeholders, make sense of data, understand tech and business implications, communicate and translate information across different teams.
We need to speak the ‘right language’ in order to be successful PMs. But what does it mean?
On one hand, through working on global products and platforms, as part of multicultural teams, I learned I was at an advantage for being multilingual. I was able to understand our users and align with them, be the voice of our users towards my teams and stakeholders, and ensure our products were of quality across different regions.
On the other hand, as PMs, we’re the connectors between different people and roles: users, designers, senior management, engineers, data scientists and they each communicate differently.
My talk covers contexts in which PMs need to speak different languages, with practical examples, spiced with a few 'no-nos' and suggestions on how to adapt our language depending on the groups we’re interacting with.
We’ll understand what 'speaking the right language' means for a PM and that it can be a 'make or break' our products.

Hi everyone, I'm really pleased to meet you. Thank you for the invitation. I'm really excited to be part of this year's UXDX conference as you already know, my talk is going to be about ‘What language do you speak’.
I'm going to touch upon how to adapt your communication depending on different languages and cultures, but also depending on differences in disciplines or professional backgrounds or seniority level for the people you interact with.
To begin with, I'd like to tell you a bit about myself and my story so that you understand what I'm talking about and you get a bit more context around where this topic came from and what I'm going to present today. So, my name is Mihaela Draghici. I currently work as a Product Manager for Volkswagen Digital Solutions, the software development center in Lisbon in Portugal. I'm originally from Romania. I've lived and worked in the UK for over seven years before I moved to Portugal. So, as you can probably guess I speak Romanian-English, and I'm currently learning Portuguese. I'm proud to say I've reached a decent level of fluency. I have a bachelor's degree with a major in English and a minor in French. So, I studied literature and linguistics and at the same time alongside I studied Spanish and Italian. So, as you can see, I am multilingual. Funnily enough, throughout my studies, I wanted to become a French teacher. I wanted to work with the European Commission as an interpreter and translator, as you can see, obviously none of that happened and as I moved on to work as a marketing manager and then moved on to product manager roles, working with very technical teams with engineers, data scientists. I felt for a while that my studies have gone to waste I was saying, well, I've gone through all of these 12 years and now I actually not using anything from what I've learned in my day to day work and it took me a while to realize that actually my studies have benefited me greatly and that I'm actually using a lot of my knowledge from my high school and university or my master's degree as well iIn my day to day work and in my interactions with different stakeholders, with users, with my colleagues. I'm going to give you some examples and throughout the presentation, the insights I'm offering are mostly coming from my experience as a product manager. Firstly, working in London with remote teams in Asia and Europe and building global products. And also, from my current experience, working in Lisbon on building software for users in Germany.
So, what are we going to talk about today? We're going to talk about how to build stronger connections and relationships with your stakeholders. Of course, English is the common work language in many companies that we are part of nowadays, however, most of our colleagues and most of our stakeholders come from different countries. So, English is not their native language. And it's important to be able to understand each other, to make sure we get the right things from each other Even if we are not native English speakers. The second point I will touch upon is making sure we understand our users and we build the right products to suit their needs, irrespective from where our users come from. And that's very important nowadays, because we mostly build products for global use or build products for specific markets. And the third point is about how you can translate information for different stakeholder groups, for different people that come from different professional backgrounds or have different levels of expertise. And you need to adapt your communication to that.
Now, I would like to touch upon the parts of building stronger connections and building stronger relationships with stakeholders and if I might ask, "Okay, so what's this whole thing about being multilingual? How has being multilingual benefited me apart from the fact that I can understand more memes and listen to songs in their original languages? It actually helped me a lot throughout my years as a product manager because I managed to create closer relationships and connections with my colleagues first of all and my stakeholders. And there's a quote by Trevor Noah, the standup comedian who wrote in his book something really interesting. And he said, "When you make the effort to speak to someone in their native language even if it's basic phrases here and there, what you basically say to people is, but I understand you. I understand that you have a culture and identity that exists beyond me. I see you as a human being." I love this statement because if you go by it it actually helps you create a closer relation and to show your colleagues or collaborators that beyond the fact that. They have a role in the business or they have a role in the company or their involvement in the product working on, they are individuals, they are human beings. So, you show that you care, you show empathy and how can you show that you care? Well, you can start your calls or your meetings by just taking five minutes here and there to ask you or stakeholders about their day or about how they're feeling or if you can help them in any way and you can do that by speaking their language, for example. If that's possible and this way you show that you want to go beyond the simple, let's talk about work and let's talk about the technical things that we need to clarify at the moment. So, you show that you're interested in that person's culture, in their origins. You connect to them on a different level by showing empathy. I have a lot of situations where I used to do this with my stakeholders from France or Italy, for example. And once they got past the surprise of finding out that I could actually speak their language, we could have these genuine, honest conversations and relate on a different level before moving on to the agenda of that specific meeting. and it was always enriching for me and for them as well. And you say, "Okay, fine. You're multilingual, not everyone is." And that's true, but you don't necessarily need to be proficient in a foreign language or in a different language than yours to have this kind of connections and relationships. Sometimes it takes just a few basic simple words that you can say here and there to show that you care about your colleagues or collaborators, and you're willing to go the extra mile. Sometimes it's as simple as a ‘Ça va’ in French and what you're reading here, it's actually a fully legit conversation in French. So, it's as simple as that in many cases.
Moving on to another topic with regards to working with people whose native language is not English. Sometimes it takes extra focus, extra consideration to understand what people want to say, especially when English is not their native language and I'm going to give you a few examples. I have a recent situation, actually. We got a message a few weeks ago from one of our colleagues in a different department who is giving us some information about the fact that they were just made aware that a specific value supposed to be missing and for the contract, we cannot confirm this. What you would read from this is that the value should be missing but we cannot confirm. It should be missing from the contract. What they actually really meant was it was reported that the value was missing for the contract but we actually know it is present. So, what do you can see in this example is, the fact but it's essential that you really understand the messages you received from your stakeholders and your colleagues that you double check the information, maybe ask for clarification, maybe ask for confirmation regarding what they meant to make sure you got the thing right because otherwise you risk taking wrong decisions, for example. In my case here, I had advantage of knowing the overall context and also having access to more information from separate conversation channels. Gave me access to other discussions. So, I was able to put pieces to yeah. They're and understand the bigger picture and understand what the actual meaning was and this can make or break your next move, your next decision and what you build in your product.
Another example I can get here is in many situations people that you've talked to find it difficult to come up with a specific word in English to express what they want to say. I don't know if you've been, for example, in situations when someone is describing something or doing a presentation or introducing a report and they stopped mid-sentence. "Oh, what do you say in English to this specific thing?" And you have two options here. You either ask them to mention that word in their native language. Obviously, if you can understand that language, or you can ask them to explain that specific word with their own phrases and you can work together on coming up with the right meaning in English to make sure you understand each other.
What about when English is actually someone's native language and, in many cases, what they say is not actually what they need. I think in this case, it's very important to pay attention to what people say and try to read between the lines sometimes there's a funny meme online with these phrases or regarding what the British people say and what they actually need versus what other people understand they're trying to say. And I find this really funny and I think it applies in many other languages as well. In fact, you can think of similar phrases in situations, in your own culture and see what you can come up with.
Moving on to another important topic I want to touch upon here is the users we built products for. Obviously, it is essential that we understand our users very well between their stents, the problems that they have, the needs that they have very well in order to build the right products, to serve their needs and to enable them to benefit from those products. In many cases, we build products for specific markets. My current example would be, we're building software for users in Germany, but in other cases, we roll out products globally. So, we need to make sure that they can be used by people from Brazil or the United Arab Emirates or as far as China. And one of the things you use and focus on in order to make sure you do that is by doing user research in the user's native language. I'm a strong advocate for that user research, user testing and validations and why is that? Because sometimes if you ask people to give you feedback or talk about their problems, or their needs in English they sometimes struggle to find the right words to express themselves, or they focus too much on the vocabulary and you lose the aspect of their emotions and their feelings. So, there are nuances that can be transmitted in a native language that you might lose when you ask people to translate what they feel and what they think. Words express emotion. So, it's important to get the real thing from people by allowing them to express themselves in their native language. Another important aspect I would like to touch upon is making sure that the products you roll out, apps, websites SAS platforms, anything you name it, making sure they are available to users no matter where these people come from. I'd still hear I would like to touch upon localization and internationalization. And highlight that I've seen situations where products being rolled out to specific markets, non-English speakers in English, or with poorly translated interfaces and poorly localized interfaces which leads to a core user experience and overall dissatisfaction and negative user feedback. And to highlight the importance of internationalization and localization here. First of all, you show that you want to give a good user experience to your users and by that you show that you care and then you also avoid misunderstandings and you avoid your product being misused. And in some cases you can even avoid legal issues, right? I could have a fully dedicated presentation around internationalization and localization so in order to keep this short, I would just like to touch upon some essential points that you should keep in mind one of them making content understandable and intuitive for users. I've seen situations where the interfaces and the platforms are being built with English as the starting language. And then from that being translated to other language and it is important to make sure you don't do literal translation into any language but you actually think of what the equivalent phrases or words are in a specific language. Because something might sound okay in English, but it's off or total nonsense in French or Arabic or German. Right. So, you need to make sure that the sentences and the calls to action and the messages you have in your interfaces are intuitive and relevant for users in their own language and to give some simple illustrations here you have this very basic example with the ‘unexpected error’ message which I've seen translated in French in many ways. And these are the two most common ones I've come across. And another example also from English to French which if someone, a French user would with reads this, they would not quite understand what it means because it doesn't really make sense in French. So, again, to illustrate how important it is to make sure that in the specific language you're translating into the meaning is relevant for the user.
The same thing about using the right local language again, it's not as simple as "Oh, we're releasing for the German markets. Let's translate the interfacing German because the German spoken in Germany is different from the one spoken in Austria or the one spoken in Switzerland, for example. And the same case with Portuguese, right. If she wants to roll out the product in Brazil make sure that your interface is available in Brazilian-Portuguese. First of all, to show respect for your users and second of all, because many words in Brazilian-Portuguese have different meanings than the ones in Portuguese and so on. So, just make sure you cover the right local language. The same applies for French, for example, and many, many other languages. Another point would be adapting specific terminology depending on the industry you're working in to the local market specifics it could be automotive. It could be education. It could be finance, it could be travel. It could be fashion, right? May ensure that the specific terminology is adapted to the local market context. I'm going to give a very simple example to illustrate this. In the world of cars, for example, in dealerships when sales persons are talking about placing car orders and signing car contracts. There is a very common term they use which is a specific identification number for a specific car model ,it's like a car seat, serial number if you'd like which in English is commission number. In German, it's a commission noir. It's similar but this translates to numero da comissao in Portuguese which actually means order number in English. And it translates to numar de referinta in Romanian which would be reference number in English. So, as you can see commission number, it means something else in other languages and it's referred to as something else in other languages. And if you try to translate it commission number, literally in Romanian in that specific context, it might mean something else or it might not mean anything at all for the salespersons. Where it would take them a long time to figure out what. We're talking about. These kinds of examples are meant to illustrate that it's very important that the terminology is not translated literally but adapted to the specifics of a certain market. And another interesting point to highlight here is to make sure that your platform, your interface supports special characters. Make sure you have the right encoding, do very thorough testing because you want to avoid situations like this. And there are a lot of points with regards to internationalization like date and time formatting, numbers formatting other special characters or currency formatting that we can touch upon here but I would like to leave you at this for now and move on to the next topic which is about being able to translate different information for different stakeholder groups.
And I was mentioning earlier that English is currently the most common language spoken in many of the companies. We are a part of where we have people coming from different backgrounds and nationalities but we're using English to communicate on a daily basis. However, the language that we use differs depending on the disciplines and the roles people have or their backgrounds from a professional perspective, their expertise or seniority levels. So, in this case, I'm talking about how to adapt your language, to talk to your engineer or to talk to your business stakeholders, to talk to senior level management or to talk to the data team. So, in this case, it's very important to adapt your language to what is relevant for each stakeholder group. One specific example I could give you, if you think of product manager job descriptions, one of the lines and the requirements in there is around being able to translate business requirements into technical specifications and that's always one of the key parts or a product manager role and I want to give some examples around being able to translate into business talk. For me, this one was a key challenge especially because I was coming from a nontechnical background, so I had to learn a lot and to illustrate this with a specific case, you're in touch with a customer success representative from your company has been in touch with the client. That's having issues with getting prices for the options they've configured on the product they're purchasing and you'll go to your engineering team and they say, "Well, actually the service we're using returns a 500 error when we do our GET requests and there's a null in the response bodies. So, we don't know much about it, but we're working with the other team to fix the issue. You can't really give this information to a customer success representative because they won't understand much from it. They will be like, "Okay, what are you talking about? What does it mean? So, you need to adapt it so they can relate to the clients as well. And you can say something more simple, like we cannot access the price quotes from the provider and we're working with the teams to identify the problem. We'll let you know as soon as we have more information because at that stage, you actually don't have more details.
Another example I could give here, your engineering team says, "Well, what are the new accepted values or the transaction status? We need to update our API in our folder so that the team X knows what to send in their request and you need to know that from your business stakeholders instead of saying all of this to them, you can just simply ask them about what the acceptable status is or what the possible statuses for the transaction might be. Another situation is around translating business requirements for your engineers or for your data engineers. And let's take this, for example, your commercial director would like to know what the adoption rate is for the new campaign manager feature in the APAC and EMEA regions over the last quarter compared to the previous quarter and you would go to your or data engineers and you need to give them specific data points and more instructions on what you would like to have included in the report so that you make sure you get enough data so, you compile what your commercial director has requested. Another illustration here would be talking to your senior management, right? Many cases you want to discuss with directors of departments or heads of departments or the C-level execs. And they're very busy people, they receive a lot of communications every day. A lot of information and you want to give them some key information and you want to make sure it gets to them and then they read it. So, in this case, for example, you have a yearly report around the success of your product. And it has a lot of information and you want to communicate that to your senior management. An easy way to do it would be send an email or a message or the communication channels you are commonly using in the company and just use some key numbers that you would like to highlight for them to read through very quickly, easily understood what you're trying to send, what information you're trying to tell them and just making sure easy for them to read it at a glance. That's it. That's the key information I want to send. And then of course, make the full report available for their later reference, if they want to check more details. In some cases, it's even better if you don't use any words and you replace words with graphs or images that can very easily bring clarity to your message in a very concise way.
And just to recap, I've given you some various examples of how using the right language can help you build great products by helping you creating closer and stronger relationships with your stakeholders by better understanding your users, their problems, and their needs, and making sure you build products that cater for these needs and that you build products that can be easily used and accessed by your end users. And last but not least, how you can translate information and communicate across different disciplines and levels of expertise across different roles within your company or with your collaborators to make sure that you get the right message across.
I hope this information is useful for you all. You can take some learnings from what you just found out today and if you would like to keep in touch, you can find me on LinkedIn and Twitter and Medium. I'm happy to answer any of your questions related to this presentation or Product Management in general. Thank you very much.