Como adoptar uma mentalidade global para gerir equipas internacionais de produto

Ler a transcrição:

Estamos a experimentar transcrever os nossos podcasts utilizando um programa de software. Perdoe quaisquer erros tipográficos, uma vez que o bot não está correcto 100% das vezes.

Hannah Clark: Na era do trabalho remoto, as equipas de produto podem assumir muitas formas e já não estão limitadas ao conjunto de talentos de uma área geográfica específica. Isto significa que muitos de nós trabalham diariamente em estreita colaboração com colegas que se encontram em fusos horários completamente diferentes, enquanto desenvolvemos produtos para clientes de todo o mundo. E embora a possibilidade de nos ligarmos, colaborarmos e vendermos internacionalmente ofereça uma grande quantidade de oportunidades, também traz consigo todo um mundo de particularidades e desafios.

O meu convidado de hoje é Craig Guarraci, que passou os últimos 30 anos a trabalhar para grandes empresas tecnológicas como a Amazon e a Microsoft e que agora aplica a sua experiência como coach de carreira. Tendo em conta o seu percurso e o seu foco actual, Craig conhece bem alguns dos desafios mais delicados associados à criação e ao lançamento de produtos a nível internacional. Conversámos sobre os aspectos que os gestores de produto, executivos e empreendedores precisam de ter em consideração actualmente quando trabalham além-fronteiras, bem como sobre a forma de garantir que os nossos melhores esforços não se perdem na tradução. Vamos começar.

Bem-vindos de volta ao podcast The CPO Club. Estou aqui com Craig Guarraci. É coach de carreira e fundador da Tech PM Career Path.

Craig, muito obrigada por se juntar a nós hoje.

Craig Guarraci: Sim, obrigado, Hannah. É óptimo estar aqui.

Hannah Clark: Excelente.

Vamos começar da forma como começamos sempre. Importa-se de nos falar um pouco sobre o seu percurso e sobre como chegou onde está hoje?

Craig Guarraci: Claro. Tenho mais de 30 anos de experiência no sector tecnológico. Trabalhei na Microsoft, na Amazon e também em algumas empresas emergentes. Uma delas tinha apenas cerca de 20 ou 30 pessoas. Por isso, trabalhei numa variedade de empresas com diferentes dimensões. Ao longo do tempo, passei por funções técnicas de gestão de projectos e programas, bem como por funções de gestão de produto.

E, sabe, por funções de gestão sénior de programas técnicos. No que diz respeito ao nosso tema de hoje, trabalhei em vários produtos globais e posso dar-lhe uma breve visão geral dos mesmos. Abrangiam desde armazéns de dados utilizados na divisão Microsoft MSN.com da Microsoft até ao trabalho em diferentes soluções B2B e B2C e em plataformas de aprendizagem.

Por exemplo, plataformas de aprendizagem utilizadas em 130 países diferentes e por 13 000 instituições de ensino. Também trabalhei na divisão de retalho da Amazon, especificamente em modelos de IA e aprendizagem automática, bem como nas ferramentas de suporte associadas. Mais à frente podemos falar sobre a utilização de IA e aprendizagem automática em diferentes contextos culturais e países. Sou também coach de carreira para gestores técnicos de projectos, programas e produtos.

Hannah Clark: Excelente. É uma trajectória profissional bastante interessante. Parece que tem, sem dúvida, uma grande profundidade de experiência no tema em foco hoje, que é a gestão intercultural de produtos. Penso que, actualmente, enquanto muitos de nós trabalhamos com equipas remotas, é mais importante do que nunca ter em conta alguns destes aspectos para conseguirmos navegar por eles.

Para começarmos, importa-se de contar uma história que contextualize por que razão os gestores de produto beneficiam de uma abordagem intercultural ao seu trabalho?

Craig Guarraci: Sim, a gestão intercultural de produtos é importante porque, como é óbvio, vivemos num mundo interligado. Certamente, desde que a Internet explodiu por volta de 1995, houve uma maior oportunidade de colaborar além-fronteiras, mas também de servir clientes em diferentes países.

O aspecto importante da gestão intercultural de produtos é que não podemos partir do princípio de que aquilo que funciona num país funcionará automaticamente noutro. Eis uma história relacionada com a plataforma de aprendizagem online que mencionei anteriormente, na Microsoft. Funcionava em cerca de 130 países diferentes e localizámos a plataforma em 15 línguas diferentes.

Uma dessas línguas era o árabe, que é uma língua escrita da direita para a esquerda. Por isso, alguns dos desafios que encontrámos consistiam essencialmente em pegar no nosso site e espelhá-lo. Tudo tinha de ser reflectido de uma forma diferente. Por exemplo, estamos habituados a escrever texto na caixa de pesquisa e, à direita, a ter uma lupa ou um ícone para iniciar a pesquisa.

Essa interface tinha de ser invertida para que os utilizadores pudessem introduzir texto da direita para a esquerda e, depois, no lado esquerdo, era onde accionavam efectivamente a pesquisa, clicando no ícone correspondente. Além disso, no Ocidente estamos habituados a visitar sites que têm o menu de navegação do lado esquerdo.

No caso do árabe, por exemplo, tivemos de o deslocar para o lado direito e também realinhar o texto dentro desses menus no lado direito. Se não tivéssemos feito isso correctamente, não teríamos conseguido servir adequadamente os nossos utilizadores árabes nessa plataforma. E, na realidade, os gestores de produto beneficiam porque conseguem servir melhor os clientes noutros países do mundo.

Hannah Clark: Sim, sem dúvida. Queremos que os nossos produtos prosperem, não apenas na nossa área imediata. É bom pensar nestes aspectos em permanência.

E, naturalmente, quando pensamos em coisas como esta, tudo isto está realmente relacionado com o design inclusivo e com a resposta às necessidades de utilizadores de diferentes contextos culturais e socioeconómicos. Fizemos recentemente um episódio sobre design acessível. Como podem os gestores de produto integrar este tipo de pensamento no ciclo de vida do produto?

Craig Guarraci: O design inclusivo é importante porque devemos ter em conta as necessidades de pessoas de diferentes culturas e contextos socioeconómicos quando trabalhamos no produto seguinte e, certamente, quando prolongamos esse produto através de diferentes lançamentos.

Isto inclui, naturalmente, aspectos como as línguas, a localização do texto e a globalização dos formatos de hora, data e moeda. Inclui também uma análise cuidadosa de todas as imagens e ícones, para garantir que são adequados à cultura em questão. E, claro, quando falamos de design inclusivo, incluímos a acessibilidade: por exemplo, pessoas que possam ter diferentes incapacidades devem continuar a poder utilizar o software para atingir os seus objectivos, sejam eles profissionais ou pessoais.

Para integrar esse trabalho no ciclo de vida do produto, pode parecer algo semelhante ao modelo em cascata, mas, na realidade, trata-se de o gestor de produto, no início desse lançamento, pensar de ponta a ponta em todo o trabalho e no que é necessário fazer para servir estes diferentes clientes em diferentes países. É importante garantir que se reserva tempo para compreender as necessidades dos clientes em diferentes países, realizar investigação e analisar os resultados dessa investigação.

Depois, mesmo durante a criação do lançamento, é necessário incluir formas de recolher feedback: feedback quantitativo, como taxas de cliques e outros dados semelhantes, bem como feedback qualitativo. Estamos a realizar inquéritos? Estamos a recolher opiniões dos clientes? Estamos a obter feedback do apoio ao cliente, através de clientes desses diferentes países que ligam porque têm dificuldades em utilizar o nosso produto?

Por isso, penso que o gestor de produto deve adoptar uma visão ampla no início desse lançamento, planear essas actividades, dividi-las e, naturalmente, avançar para a execução.

Hannah Clark: Está bem. Isto é muito interessante para mim e gostaria de aprofundar um pouco, utilizando especificamente o exemplo da versão do produto que tinha de servir utilizadores árabes.

Quais são alguns dos desafios difíceis de gerir associados à realização de investigação qualitativa quando se tenta servir um grupo demográfico que tem padrões de comunicação muito diferentes dos nossos, especialmente se não tivermos ninguém na equipa que domine necessariamente essa língua?

Quais foram alguns dos desafios que encontrou e como conseguiu ultrapassá-los?

Craig Guarraci: Alguns desses desafios consistem em encontrar pessoas suficientes nos mercados-alvo que possam fornecer feedback suficiente. Se isso não for possível, haverá um especialista no assunto que esteja pelo menos suficientemente familiarizado com as normas culturais e os padrões de localização desses países específicos?

Por exemplo, quando trabalhava nessa plataforma de aprendizagem, tivemos a sorte de contar com uma pessoa capaz de ler hebraico. O hebraico também é uma língua escrita da direita para a esquerda, por isso essa pessoa era uma especialista que nos podia aconselhar sobre as alterações que devíamos fazer à interface, o que esperar da interface em geral e a forma como as coisas deveriam ser percepcionadas.

Portanto, em primeiro lugar, o ideal é obter feedback de clientes nesse mercado. Se isso não for possível, é importante contar com um especialista no assunto que possa dar feedback sobre a forma de adaptar o produto aos diferentes países.

Hannah Clark: E isso deve ser um desafio único quando se está a visar um mercado específico como esse.

Vamos agora abordar alguns desafios bastante significativos, já que estamos a falar de desafios e oportunidades na gestão intercultural de produtos. Gostaria de começar pela utilização eficaz da tecnologia de IA, porque este é um tema muito actual. É algo que temos de considerar independentemente do tipo de produto que estamos a desenvolver e do mercado a que se destina.

Pode partilhar algumas perspectivas sobre a utilização da aprendizagem por transferência em IA para adaptar um modelo treinado num contexto cultural e torná-lo eficaz noutro?

Craig Guarraci: Um exemplo seria o seguinte: depois de treinar um modelo para processar dados num determinado país e numa determinada língua, cabe ao gestor de produto determinar se existem oportunidades para aplicar esses mesmos conhecimentos noutros países.

Vou dar alguns exemplos relacionados com a detecção de anomalias, utilizando situações que penso serem familiares à maioria dos seus ouvintes. Suponhamos que estamos a desenvolver um modelo de IA para detecção de anomalias nos Estados Unidos. Algumas anomalias podem ser intrusões de segurança, como numa rede empresarial.

Será que agentes mal-intencionados estão a tentar aceder à nossa rede empresarial? Como são os seus padrões de tráfego? Podemos treinar um modelo para identificar esses padrões. Naturalmente, são anomalias porque a grande maioria do tráfego da nossa rede provém de funcionários normais. Os agentes mal-intencionados terão padrões de tráfego ligeiramente diferentes. Também podemos ter anomalias na experiência do cliente: clientes que utilizam o nosso software ou site podem ter dificuldades.

Talvez apenas uma pequena percentagem desses clientes nos contacte sobre os problemas que estão a ter. Podemos ainda ter possíveis situações de fraude por parte de clientes. Isto também é detecção de anomalias, porque um número muito reduzido de clientes tentará utilizar técnicas maliciosas para defraudar as empresas.

Estes são apenas alguns exemplos de anomalias. Suponhamos que treinámos um modelo nos Estados Unidos. O gestor de produto tem de determinar se podemos utilizar esse mesmo modelo noutro país. É necessário analisar a sobreposição entre essas anomalias. As anomalias de detecção de intrusões de segurança noutros países são suficientemente semelhantes às anomalias que identificámos e com base nas quais treinámos o modelo nos Estados Unidos? Ou, no caso das anomalias na experiência do cliente, o site que temos noutros países apresenta a maior parte da mesma funcionalidade, tornando provável que os clientes desses países se deparem com os mesmos problemas?

Depois de treinarmos um modelo para um país, temos de determinar se existe sobreposição suficiente com os outros países e com o tráfego que provavelmente será registado nesses locais. Também devemos determinar o esforço necessário por parte da equipa de ciência de dados para preparar o modelo para funcionar noutros mercados.

Nesse caso, haverá trabalho relacionado com a tradução. Se treinámos o modelo em inglês nos Estados Unidos e queremos utilizá-lo em França, na Alemanha e em Itália, por exemplo, temos de decidir se traduzimos primeiro essas línguas para inglês e executamos o modelo sobre essa tradução ou se criamos modelos para cada uma dessas línguas específicas.

Há, portanto, diferentes aspectos a considerar em termos do custo global envolvido para obter esse benefício: executar o modelo em diferentes mercados.

Hannah Clark: Imagino que até a tradução apresente desafios próprios, não apenas em termos de custo. Como podemos salvaguardar a precisão da tradução de uma perspectiva para a seguinte? Parece-me que existe muito risco envolvido.

Tem outras perspectivas sobre alguns dos desafios mais meticulosos associados ao trabalho com vários conjuntos de dados em línguas diferentes?

Craig Guarraci: Sim. Um deles é aquilo que mencionou: a qualidade da tradução. Se vamos traduzir outras línguas para uma língua comum, digamos o inglês, qual é a qualidade global dessa tradução?

Outro aspecto são os padrões de tráfego e o tipo de anomalias que procuramos. São suficientemente semelhantes àquilo que o modelo já conhece para que possa funcionar correctamente noutros países? Isto leva-nos a outra área em que tendemos a concentrar-nos muito no próprio modelo.

Toda a gente fala do modelo, de toda a matemática e das técnicas, mas existe também muita infraestrutura de suporte à volta desses modelos. Por exemplo, se vamos auditar o nosso modelo de detecção de anomalias e se algumas pessoas dentro da empresa vão auditar os resultados para garantir que o modelo apresenta um elevado grau de precisão e fiabilidade, serão necessárias ferramentas, nomeadamente ferramentas de etiquetagem.

Essas ferramentas de etiquetagem também terão de funcionar noutros países, porque provavelmente teremos contactos em cada um desses países que trabalham para a nossa empresa e que dirão: “Sim, no caso desta anomalia do cliente ou desta detecção de fraude do cliente, o modelo está a identificá-la correctamente.” Utilizarão essa interface de etiquetagem interna da empresa, permitindo obter continuamente feedback sobre o desempenho do modelo nesses diferentes países.

Se o desempenho começar a divergir, teremos transferido os nossos conhecimentos dos Estados Unidos para esses outros países e estaremos a receber feedback dos responsáveis pela etiquetagem e dos auditores. Se verificarmos que o modelo não está a funcionar muito bem, isso é um sinal de que precisamos de analisar mais profundamente os dados desse país e perguntar por que razão o modelo não está a ter um desempenho tão bom nesses outros países.

São apenas alguns dos aspectos mais pormenorizados relacionados com a tradução linguística e com as ferramentas de suporte. Essas ferramentas de suporte têm de conseguir funcionar noutros países para que o modelo seja bem-sucedido.

Hannah Clark: Sim, são considerações realmente interessantes.

Também queria abordar outro grande desafio, que é, naturalmente, a conformidade regulamentar além-fronteiras. Estamos a falar de lidar com obrigações legais muito diferentes, consoante os países onde operamos. Temos leis como o RGPD da União Europeia, o Regulamento Europeu da IA e algumas das leis de privacidade emergentes a nível dos estados norte-americanos. Como devem os gestores de produto conceber estratégias de recolha de dados que se mantenham conformes e éticas, sem deixarem de ser eficazes?

Craig Guarraci: Essas abordagens de recolha de dados dependem realmente de o gestor de produto trabalhar em estreita colaboração com o seu consultor jurídico. Será necessário esse apoio para navegar pelas diferentes regulamentações. Existem regulamentações diferentes em diferentes países. Temos o RGPD, o Regulamento Geral sobre a Protecção de Dados da União Europeia, que abrange os 27 países da UE e o Reino Unido.

Existe também o Regulamento Europeu da IA, que entrou recentemente em vigor, em Agosto do ano passado. Abrange organizações que desenvolvem ou utilizam IA e classifica os modelos de IA em cinco categorias diferentes. Além disso, pelo menos a Califórnia e a Virgínia têm legislação própria: a California Privacy Rights Act e a Virginia Consumer Data Protection Act. Estas leis protegem a recolha de informações dos clientes, bem como a forma como os clientes podem alterar e actualizar essas informações e solicitar a eliminação dos seus dados pessoais.

De um modo geral, estas são apenas algumas regulamentações a considerar na gestão intercultural de produtos. Trata-se realmente de um esforço transversal à empresa, entre o gestor de produto e o consultor jurídico, a contabilidade, as finanças e possivelmente outros departamentos. É algo que deve ser ponderado desde cedo e integrado no planeamento global do lançamento.

Naturalmente, depois de o departamento jurídico e o gestor de produto decidirem especificamente o que precisa de ser construído, isso dará origem a requisitos detalhados, histórias de utilizador e épicos que o gestor de produto poderá decompor e desenvolver com a equipa de engenharia.

Hannah Clark: Falando da equipa de engenharia, gostaria de passar para temas mais internos relacionados com os gestores interculturais de produto, porque temos falado um pouco sobre como tornar os nossos produtos funcionais para uma variedade de utilizadores externos.

Obviamente, também trabalhamos com equipas internas que podem abranger vários países e fusos horários. Este é um tema muito interessante para mim: saber como navegar pelas diferenças entre os grupos demográficos com os quais trabalhamos de perto. Quais são algumas dicas práticas para ultrapassar falhas de comunicação quando se gerem equipas de engenharia ou vários colaboradores individuais em diferentes países, com estilos de trabalho, normas culturais e outras considerações distintas?

Craig Guarraci: Em primeiro lugar, penso que é necessário determinar se existem diferenças linguísticas entre os vários membros da equipa. Por exemplo, quando liderava uma equipa na China, os seus membros falavam inglês bastante bem e estavam muito empenhados em produzir resultados. Numa reunião inicial de planeamento de um ciclo, analisámos as histórias que precisavam de ser desenvolvidas nesse ciclo.

Não fizeram perguntas. Vi muitas cabeças a acenar e muita concordância. Por isso, presumi que sabiam o que precisava de ser construído para esse lançamento. Mas, à medida que o ciclo avançava e comecei a ver alguns dos resultados, percebi que não tinham realmente compreendido todos os requisitos nem o verdadeiro significado das histórias de utilizador.

Mesmo tendo critérios mensuráveis nessas histórias, percebi que não compreendiam totalmente o que significavam numa escala mais ampla. Por isso, é muito importante testar a compreensão para determinar se existem falhas de comunicação. Acabámos de discutir um conjunto de histórias de utilizador. Qual é a vossa interpretação dessas histórias? Também podemos perguntar: como pensam que estas histórias se relacionam com o lançamento global do projecto? Existem preocupações relativamente à possibilidade de estas histórias não responderem plenamente às necessidades dos clientes?

Outro aspecto relacionado com as falhas de comunicação é estar atento ao calão cultural. Cada país tem uma determinada quantidade de calão na sua língua. Na América, por exemplo, usamos expressões como “uma estimativa aproximada”. Mas os estádios de basebol não existem noutros países. Ou usamos expressões como “à vontade com tecnologia”.

Por vezes, essas falhas de comunicação são causadas por atalhos linguísticos, pelo calão que tendemos a utilizar. Por isso, teria cuidado com isso. São apenas algumas coisas a que prestaria atenção: testar a compreensão e ter cuidado com a linguagem utilizada.

Hannah Clark: Sabe o que acho interessante nisso? Obriga-nos a analisar a quantidade de jargão que integramos na nossa comunicação diária. Penso que, especialmente neste sector, estamos cheios de jargão que pode ser um pouco opaco, até para pessoas do sector a nível local.

Isto levou-o a avaliar alguns dos termos que utiliza, mesmo com as suas equipas locais?

Craig Guarraci: Com as equipas locais, nem por isso. As equipas locais eram todas dos Estados Unidos ou constituídas por pessoas que viviam aqui há cerca de uma década. Por isso, não foi um grande desafio.

Normalmente, isso acontece com pessoas que ainda vivem num país fora dos Estados Unidos ou para quem o inglês é uma segunda língua. Eu próprio comecei a verificar duas vezes os meus e-mails quando os enviava para um membro da equipa no estrangeiro. Lia-os duas ou três vezes para garantir que não estava a partir de pressupostos, a utilizar calão ou a assegurar que as coisas eram objectivas. Queria ter a certeza de que comunicava da forma mais clara possível com membros da equipa noutra localização.

Porque, se não fizermos isso correctamente, incorremos no temido atraso de 24 horas. A pessoa recebe o e-mail enquanto estamos a dormir, responde, nós chegamos ao escritório no dia seguinte e isso conduz simplesmente a mais atrasos nos projectos.

Hannah Clark: Sim, imagino. Também consigo imaginar como algumas das expressões que usamos, como “fechar o ciclo”, são analogias tão integradas no nosso discurso diário que é difícil detectá-las até realizarmos esse esforço adicional. Isso é realmente interessante quando se supervisiona um projecto e se trabalha com várias equipas que actuam sob a nossa direcção.

E entre equipas? Já teve situações em que precisou de ajudar a promover a colaboração e a criar uma maior confiança entre equipas internacionais que trabalhavam em conjunto?

Craig Guarraci: Sim. Nesse caso, é necessário compreender as diferentes atitudes ou abordagens em relação ao trabalho. Um bom exemplo são os prazos. Algumas culturas encaram os prazos como algo muito fluido, flexível e negociável: desde que entreguemos por volta dessa data, está tudo bem.

Já outras culturas, especialmente nos Estados Unidos, entendem que uma data é uma data. Se dissermos que vamos entregar a 30 de Julho, será nessa data. É importante tentar compreender as perspectivas relativamente às datas e testar a compreensão à medida que analisamos o roteiro geral do calendário desse lançamento: qual é a vossa interpretação destas datas? Quão críticas consideram que são? Qual é a importância destas datas para o projecto em geral?

No que diz respeito à confiança, penso que também é necessário compreender as recompensas e o reconhecimento públicos. São valorizados? Como devem ser atribuídas e partilhadas as recompensas públicas? Devem ser atribuídas a uma pessoa que contribuiu ou existem culturas em que se prefere que a recompensa seja atribuída à equipa no seu conjunto, em vez de a uma pessoa específica?

É importante reservar tempo para investigar e compreender a forma como as diferentes culturas encaram estas questões. Em termos de confiança, penso também que é importante compreender e reconhecer os diferentes feriados nacionais. Por exemplo, na China, por volta de Fevereiro, celebra-se o Festival da Primavera e as pessoas tiram cerca de uma semana de férias.

É importante reservar algum tempo antes dessa data para as felicitar e, naturalmente, planear em torno dessas datas para garantir que existe cobertura para o projecto e para a produção, incorporando também esse período no calendário. Na Índia, por exemplo, celebra-se o Diwali por volta de Novembro. É importante felicitar as pessoas e celebrar esses diferentes feriados.

Penso que isso contribui muito para criar confiança num determinado projecto.

Hannah Clark: Sim, é muito interessante. Também deve promover uma atmosfera cultural muito agradável.

No caso específico das equipas de engenharia que trabalham remotamente ou em modelos híbridos, como podem os gestores de produto garantir que a colaboração e a responsabilização entre esses fusos horários e fronteiras culturais continuam a ser perfeitas? Como garantir que todos são responsáveis por tudo e conseguem responder atempadamente?

Craig Guarraci: Para além das outras áreas que mencionei, como a análise do calendário e o teste da compreensão, este é o ponto em que entram em jogo as competências interpessoais do gestor de produto. Trata-se realmente de o gestor de produto circular pela equipa.

Depois de iniciar esse ciclo específico, é importante falar com os engenheiros locais que trabalham com engenheiros noutros países e fusos horários e perguntar simplesmente: “Como estão a correr as coisas? Como está a progredir esta área ou esta funcionalidade? Há alguma coisa a impedir o avanço?” Também é importante perguntar como está a correr o trabalho com determinada pessoa noutro país e contactar o seu homólogo nesse outro país.

Por vezes existe um responsável principal num país, como um gestor de projecto ou outro gestor de programas, que trabalha directamente com os engenheiros de outro país. Ao falar com essa pessoa, por e-mail ou por chat, ou ao realizar reuniões informais, podemos perguntar: “Como estão as coisas do seu lado? Acha que estão a fazer bons progressos? Há algum problema que devamos discutir? Existe alguma coisa a bloqueá-los?”

É importante fazer perguntas abertas. Penso que os aspectos relacionados com a motivação que mencionei anteriormente também ajudam a criar colaboração. Essa colaboração perfeita resulta, de certa forma, de uma combinação entre analisar o calendário e o trabalho necessário e praticar essas competências interpessoais: circular pela equipa e ter conversas informais com as pessoas localmente, bem como com os membros da equipa de engenharia noutras localizações.

Hannah Clark: Antes de terminarmos, estou muito curiosa: tem alguma história sobre um momento em que tenha considerado especialmente gratificante ou interessante trabalhar num ambiente que o expôs a todas estas normas culturais diferentes?

Craig Guarraci: Sim, seria a plataforma de aprendizagem que mencionei anteriormente, na Microsoft. Isso deve-se simplesmente ao facto de ser tão abrangente, cobrir tantos países diferentes e envolver a localização e a globalização de um produto em cerca de 15 línguas. Expôs-me realmente a muitas atitudes culturais diferentes e a diferentes formas de as pessoas verem o produto.

De um modo geral, recordo alguns aspectos específicos, mesmo durante a localização. Por exemplo, ao localizar para alemão, o texto alemão pode ser bastante longo. Por isso, quando se tenta inserir uma tradução alemã na interface existente, pode ser necessário efectuar alterações na interface para ampliar caixas de diálogo, menus e outros elementos.

Aprendemos, portanto, muitas coisas interessantes simplesmente ao realizar o trabalho para clientes de outros países.

Hannah Clark: Isso é fascinante. Penso que é muito interessante podermos aprender mais sobre as pessoas e sobre a forma como vivem e trabalham em diferentes países. É muito interessante.

Craig, muito obrigada por se juntar a nós. Esta foi uma conversa muito interessante e abordámos muitos ângulos diferentes. Onde podem as pessoas acompanhar o seu trabalho online se quiserem saber mais?

Craig Guarraci: Podem visitar o meu site, techpmcareerpath.com, ou procurar-me no LinkedIn.

Hannah Clark: Excelente. Muito obrigada por se juntar a nós.

Craig Guarraci: Obrigado.

Hannah Clark: Obrigada por nos ouvirem. Para obterem mais perspectivas, guias práticos e análises de ferramentas, subscrevam a nossa newsletter em theproductmanager.com/subscribe. Podem ouvir mais conversas como esta subscrevendo The CPO Club, onde quer que ouçam os vossos podcasts.