Sådan indfører du en global tankegang i ledelsen af internationale produktteams

Læs transskriptionen:

Vi prøver at transskribere vores podcasts ved hjælp af et softwareprogram. Bær over med eventuelle stavefejl, da botten ikke er korrekt 100 % af tiden.

Hannah Clark: I en tid med fjernarbejde kan produktteams antage mange former og er ikke længere begrænset til talentmassen i et bestemt geografisk område. Det betyder, at mange af os hver dag arbejder tæt sammen med kolleger i helt andre tidszoner, samtidig med at vi udvikler produkter til kunder over hele verden. Og selvom muligheden for at skabe forbindelse, samarbejde og sælge internationalt giver et væld af muligheder, medfører den også en hel verden af finesser og udfordringer.

Min gæst i dag er Craig Guarraci, som har brugt de seneste 30 år på at arbejde for store teknologivirksomheder som Amazon og Microsoft, og som nu bruger sin erfaring som karrierecoach. Med sin baggrund og sit nuværende fokus kender Craig nogle af de mere følsomme udfordringer ved at udvikle og lancere produkter internationalt særdeles godt. Vi talte om de overvejelser, som produktchefer, ledere og iværksættere bør gøre sig lige nu, når de arbejder på tværs af landegrænser, og om hvordan man sikrer, at ens bedste indsats ikke går tabt i oversættelsen. Lad os komme i gang.

Velkommen tilbage til The CPO Club-podcasten. Jeg er her sammen med Craig Guarraci. Han er karrierecoach og grundlægger af Tech PM Career Path.

Craig, mange tak, fordi du vil være med i dag.

Craig Guarraci: Ja, tak Hannah. Det er dejligt at være her.

Hannah Clark: Fantastisk.

Vi starter, som vi altid gør. Vil du fortælle os lidt om din baggrund, og hvordan du er nået dertil, hvor du er i dag?

Craig Guarraci: Selvfølgelig. Jeg har over 30 års erfaring fra teknologibranchen. Jeg har arbejdet hos Microsoft og Amazon samt i nogle nystartede virksomheder. Den ene havde kun omkring 20 eller 30 medarbejdere. Så jeg har arbejdet i virksomheder af mange forskellige størrelser. Jeg har bevæget mig gennem roller inden for tekniske projekter og programmer samt produktledelse.

Og du ved, roller som senior teknisk programleder. I forhold til dagens emne har jeg arbejdet med en række globale produkter, og jeg kan give dig et kort overblik over dem. De har blandt andet omfattet datalagre, der blev brugt i Microsofts MSN.com-afdeling, samt forskellige B2B- og B2C-løsninger og læringsplatforme.

For eksempel læringsplatforme, der blev brugt i 130 forskellige lande af 13.000 uddannelsesinstitutioner. Jeg har også arbejdet i Amazons detailhandelsafdeling. Her arbejdede jeg specifikt med AI- og ML-modeller samt understøttende værktøjer. Vi kan senere komme ind på brugen af AI og ML på tværs af forskellige kulturelle grænser og i forskellige lande, og jeg er karrierecoach for tekniske projekt-, program- og produktledere.

Hannah Clark: Fantastisk. Det er virkelig en interessant karriereudvikling. Det lyder, som om du helt sikkert har en stor dybde af erfaring inden for dagens fokusområde, nemlig tværkulturel produktledelse. Jeg tror, at det lige nu, hvor mange af os arbejder med fjernteams, er vigtigere end nogensinde at være opmærksom på nogle af de ting, man skal navigere i.

For at komme i gang: Vil du fortælle en historie, der sætter i kontekst, hvorfor produktchefer har gavn af en tværkulturel tilgang til deres arbejde?

Craig Guarraci: Ja, tværkulturel produktledelse er vigtig, fordi vi naturligvis lever i en forbundet verden. Især siden internettet for alvor eksploderede omkring 1995, har der været større mulighed for at samarbejde på tværs af landegrænser, men også for at betjene kunder i forskellige lande.

Det vigtige ved tværkulturel produktledelse er, at vi ikke kan gå ud fra, at det, der fungerer i ét land, automatisk fungerer i et andet land. Her er en historie relateret til den online-læringsplatform, jeg nævnte tidligere hos Microsoft. Den kørte i omkring 130 forskellige lande, og vi lokaliserede platformen til 15 forskellige sprog.

Et af disse sprog var arabisk, og det er et sprog, der skrives fra højre mod venstre. Nogle af de udfordringer, vi stødte på, var, at man i praksis skal tage sit websted og spejlvende det. Alt skulle altså afspejles på en anden måde. For eksempel er vi vant til at skrive tekst i søgefeltet og derefter have et forstørrelsesglas eller et gå-ikon eller noget lignende til højre.

Denne brugergrænseflade skulle vendes, så brugerne kunne indtaste tekst fra højre mod venstre, og det var derefter i venstre side, at man faktisk startede søgningen ved at klikke på søgeikonet. I Vesten er vi også vant til at besøge websteder, der har navigationsmenuen i venstre side.

For arabisk skulle vi for eksempel flytte den over i højre side og også justere teksten i disse menuer i højre side. Hvis vi ikke havde gjort det korrekt, ville vi ikke have kunnet betjene vores arabiske brugere på platformen ordentligt. Og produktchefer får i sidste ende gavn af det, fordi de bedre kan betjene kunder i andre lande over hele verden.

Hannah Clark: Ja, helt sikkert. Vi ønsker, at vores produkter skal trives, ikke kun i vores umiddelbare nærhed. Så det er godt hele tiden at have disse ting i tankerne.

Og når vi naturligvis tænker på ting som dette, handler det i høj grad om inkluderende design og om at imødekomme behovene hos brugere fra forskellige kulturelle og socioøkonomiske baggrunde. Vi lavede for nylig også et afsnit om tilgængeligt design. Så hvordan kan produktchefer indarbejde denne tankegang i produktets livscyklus?

Craig Guarraci: Inkluderende design er vigtigt, fordi man tager hensyn til behovene hos mennesker fra forskellige kulturer og med forskellige socioøkonomiske baggrunde, når man arbejder på det næste produkt og naturligvis videreudvikler produktet gennem forskellige udgivelser.

Det omfatter selvfølgelig ting som sprog, lokalisering af tekst samt globalisering af tids-, dato- og valutaformater. Man skal også gennemgå billeder og ikoner grundigt for at sikre, at de passer til den pågældende kultur. Og når vi taler om inkluderende design, omfatter det også tilgængelighed, for eksempel at personer med forskellige funktionsnedsættelser stadig kan bruge softwaren til at nå deres mål, uanset om målene er professionelle eller personlige.

For at indarbejde dette arbejde i produktets livscyklus kan det måske lyde lidt vandfaldsagtigt, men det handler virkelig om, at produktchefen allerede i begyndelsen af en udgivelse tænker hele vejen rundt om alt det arbejde, der skal udføres for at betjene disse forskellige kunder i forskellige lande. Man skal sikre, at man tager sig tid til at forstå kundernes behov i forskellige lande, foretage undersøgelser og afsætte tid til at analysere resultaterne af disse undersøgelser.

Og selv når man udvikler udgivelsen, skal man overveje, om man bygger på måder, der gør det muligt at indsamle feedback. Det kan være kvantitativ feedback som klikrater og lignende, men også kvalitativ feedback. Gennemfører vi undersøgelser eller indsamler kundeudtalelser? Eller får vi måske bare feedback fra kundeservice om kunder fra de forskellige lande, der ringer ind, fordi de har problemer med at bruge vores produkt?

Jeg mener derfor, at produktchefen skal have et bredt perspektiv fra begyndelsen af udgivelsen, planlægge disse aktiviteter, opdele arbejdet og naturligvis føre det ud i livet.

Hannah Clark: Okay, det er meget interessant for mig, og jeg vil gerne gå lidt videre med eksemplet på den version af produktet, der specifikt skulle tale til arabiske brugere.

Hvilke udfordringer, som jeg forestiller mig kan være svære at navigere i, er forbundet med at gennemføre kvalitativ research, når man forsøger at betjene en demografisk gruppe, der har helt andre kommunikationsstandarder end en selv, og man måske ikke har nogen på teamet, der nødvendigvis behersker sproget?

Hvilke udfordringer har du mødt, og hvordan har du overvundet dem?

Craig Guarraci: Nogle af udfordringerne består i at få tilstrækkeligt mange personer fra de pågældende målmarkeder til at give tilstrækkelig feedback. Hvis det ikke er muligt, findes der så en fagekspert, der i det mindste er fortrolig nok med de kulturelle normer og lokaliseringsstandarderne for de pågældende lande?

Da jeg arbejdede på den læringsplatform, var vi for eksempel så heldige at have en medarbejder, der kunne læse hebraisk. Hebraisk skrives også fra højre mod venstre, så han var en slags ekspert, der kunne rådgive os om, hvordan vi burde ændre brugergrænsefladen, hvad vi kunne forvente af brugergrænsefladen generelt, og hvordan tingene overordnet set burde opfattes.

Så først og fremmest er det ideelt at få kunder på det pågældende marked til at give feedback. Hvis det ikke kan lade sig gøre, kan man få en fagekspert til at give feedback på, hvordan man bør tilpasse sig forskellige lande.

Hannah Clark: Og det må være en særlig udfordring at overvinde, hvis man målretter sig mod et specifikt marked som det.

Lad os nu se på nogle ret betydelige udfordringer, når vi taler om udfordringer og muligheder inden for tværkulturel produktledelse. Jeg vil gerne begynde med den effektive brug af AI-teknologi, fordi det er et aktuelt emne. Det er noget, vi overvejer, uanset hvilken slags produkt vi udvikler, og hvilket marked det er til.

Kan du dele nogle indsigter om brugen af overførselslæring i AI til at tilpasse en model, der er trænet i én kulturel kontekst, så den bliver effektiv i en anden?

Craig Guarraci: Et eksempel på det er, at når man først har trænet en model til at behandle data i et bestemt land og på et bestemt sprog, er det op til produktchefen at afgøre, om der er muligheder for at anvende de samme læringsresultater i andre lande.

Lad mig give nogle eksempler inden for anomalidetektion, og jeg vil bruge eksempler, som jeg tror, de fleste af dine lyttere kender. Lad os sige, at vi udvikler en AI-model til anomalidetektion i USA. Nogle anomalier kan være detektering af sikkerhedsindtrængen, for eksempel på et virksomhedsnetværk.

Forsøger uvedkommende at få adgang til vores virksomhedsnetværk? Og hvordan ser deres trafikmønstre ud? Man træner en model til at identificere disse trafikmønstre. Det er naturligvis anomalier, fordi langt størstedelen af trafikken på netværket kommer fra almindelige medarbejdere. De uvedkommende på netværket vil have lidt anderledes trafikmønstre.

Det kan også være anomalier i kundeoplevelsen, hvor kunder, der bruger softwaren eller webstedet, oplever vanskeligheder. Man hører måske kun fra en meget lille procentdel af disse kunder om de problemer eller udfordringer, de har. Det kan også være potentiel kundesvindel. Det er ligeledes anomalidetektion, fordi et meget lille antal kunder vil forsøge at bruge ondsindede teknikker til at bedrage virksomheder.

Det er blot nogle eksempler på anomalier generelt. Lad os sige, at vi har trænet en model i USA, og produktchefen skal afgøre, om vi kan bruge den samme model i et andet land. Det handler om at fastslå overlapningen mellem disse anomalier. Er anomalierne ved sikkerhedsindtrængen i andre lande tilstrækkeligt ens med de anomalier, vi har identificeret og trænet modellen til i USA? Eller hvad angår anomalier i kundeoplevelsen: Har vi det samme websted i forskellige lande, og viser det det meste af den samme funktionalitet, så det er sandsynligt, at kunder i andre lande støder på de samme problemer?

Når man har trænet en model for ét land, skal man altså afgøre, om der er tilstrækkeligt overlap med andre lande og den trafik, de sandsynligvis vil opleve. Man skal også fastslå, hvor stor en indsats datavidenskabsteamet skal bruge på at gøre modellen klar til at køre på andre markeder.

Her er der arbejde, der skal udføres i forbindelse med oversættelse. Hvis vi har trænet modellen på amerikansk engelsk og vil køre den i for eksempel Frankrig, Tyskland og Italien, skal vi afgøre, om vi først vil oversætte disse sprog til engelsk og køre modellen på det, eller om vi vil have modeller, der kører for hvert af de specifikke sprog.

Der er altså forskellige ting, man skal overveje i forhold til de samlede omkostninger ved at opnå fordelene ved at køre modellen på forskellige markeder.

Hannah Clark: Jeg forestiller mig, at oversættelsen også medfører sine egne særlige udfordringer, ikke kun omkostningerne. Hvordan kan man sikre præcisionen i oversættelsen fra den ene indsigt til den næste? Det lyder, som om der er en stor risiko forbundet med det.

Har du andre indsigter i nogle af de mere omhyggelige udfordringer ved at arbejde med flere datasæt på forskellige sprog?

Craig Guarraci: Ja. Den ene ting er det, du nævnte, nemlig kvaliteten af oversættelsen. Hvis man oversætter andre sprog til det fælles sprog, lad os sige engelsk, hvad er så den overordnede kvalitet af oversættelsen?

En anden ting er trafikmønstrene og den type anomalier, man leder efter. Er de tilstrækkeligt ens med det, modellen allerede kender, til at den kan køre korrekt i andre lande? Det fører os ind på et andet område, hvor vi ofte fokuserer meget på selve modellen.

Alle taler om modellen, al matematikken og teknikkerne, men der er også en masse understøttende infrastruktur omkring disse modeller. Hvis vi for eksempel skal revidere vores anomalidetektionsmodel, vil vi have medarbejdere internt i virksomheden til at revidere nogle af resultaterne for at sikre, at modellen leverer en høj grad af nøjagtighed og pålidelighed.

Så er der behov for værktøjer, for eksempel mærkningsværktøjer. Disse mærkningsværktøjer skal også kunne bruges i andre lande, fordi man sandsynligvis vil have kontakter i hvert af disse lande, som arbejder for virksomheden, og som kan sige: Ja, modellen identificerer denne kundeanomali eller denne detektering af kundesvindel korrekt. De bruger mærkningsbrugergrænsefladen, altså den interne virksomhedsgrænseflade, så man løbende får feedback på, hvor godt modellen fungerer i de forskellige lande.

Hvis modellen begynder at afvige, har man overført sin læring fra USA til de andre lande, og man får feedback fra sine mærkere og revisorer. Så kan man konstatere, at modellen ikke fungerer særlig godt. Det er et signal om, at man er nødt til at gå mere i dybden med dataene for det pågældende land og spørge: Hvorfor fungerer modellen ikke lige så godt i disse andre lande?

Det er nogle af de finere detaljer omkring sprogoversættelse og de understøttende værktøjer. De understøttende værktøjer skal kunne bruges i andre lande, for at modellen kan blive en succes.

Hannah Clark: Ja, det er virkelig interessante overvejelser.

Jeg ville også gerne se nærmere på en anden stor udfordring, nemlig overholdelse af lovgivningen på tværs af landegrænser. Vi taler om juridiske forpligtelser, som er meget forskellige alt efter, hvilke lande man opererer i. Med love som EU’s GDPR, EU’s AI-forordning og nogle af de nye amerikanske privatlivslove på delstatsniveau, som også spiller ind, hvordan bør produktchefer designe strategier for dataindsamling, der fortsat er lovlige og etiske, men stadig effektive?

Craig Guarraci: Disse tilgange til dataindsamling afhænger i høj grad af, at produktchefen arbejder tæt sammen med virksomhedens juridiske rådgiver. Det er nødvendigt for at kunne navigere i de forskellige regler. Der er forskellige regler i forskellige lande. Der er EU’s generelle forordning om databeskyttelse, GDPR, som dækker de 27 EU-lande samt Storbritannien.

Der er også EU’s AI-forordning, som trådte i kraft i august sidste år. Den omfatter organisationer, der udvikler eller anvender AI, og kategoriserer AI-modeller i fem forskellige kategorier. Der er naturligvis også mindst Californien og Virginia, hvor henholdsvis California Privacy Rights Act og Virginia Consumer Data Protection Act beskytter indsamlingen af kundeoplysninger samt kundernes muligheder for at ændre og opdatere disse oplysninger og få deres personlige data slettet.

Samlet set er det blot nogle få regler, man skal overveje i forbindelse med tværkulturel produktledelse. Det er virkelig en indsats på tværs af virksomheden, hvor produktchefen arbejder sammen med den juridiske rådgiver, regnskabsafdelingen, økonomiafdelingen og muligvis andre afdelinger. Det er noget, man skal tænke over tidligt og planlægge ind i udgivelsen.

Når jura og produktledelse har besluttet præcis, hvad der skal bygges, bliver det naturligvis til detaljerede krav, brugerhistorier og epics, som produktchefen skal opdele og bygge sammen med sit udviklingsteam.

Hannah Clark: Når vi nu taler om udviklingsteamet, vil jeg gerne gå videre til nogle mere interne emner relateret til tværkulturel produktledelse, for indtil videre har vi talt lidt om, hvordan vi gør vores produkter funktionelle for en række eksterne brugere.

Vi arbejder naturligvis også med interne teams, der ofte kan spænde over flere lande og tidszoner. Det er et meget interessant emne for mig: at navigere i disse forskelle på tværs af de demografiske grupper, vi arbejder tæt sammen med. Hvilke praktiske råd har du til at bygge bro over kommunikationskløfter, når man leder udviklingsteams eller forskellige individuelle bidragydere i forskellige lande med varierende arbejdsformer, kulturelle normer og alle de andre overvejelser, der følger med arbejdet på tværs af landegrænser?

Craig Guarraci: Først mener jeg, at man skal afgøre, om der er sproglige forskelle mellem de forskellige teammedlemmer. Da jeg for eksempel ledede et team i Kina, talte de forholdsvis godt engelsk, og de var meget ivrige efter at levere resultater. På et tidligt møde om sprintplanlægning gennemgik vi de historier, der skulle bygges til sprintet.

De havde ingen spørgsmål. Jeg så mange nik og stor enighed. Derfor gik jeg ud fra, at de vidste, hvad der skulle bygges til udgivelsen. Men efterhånden som sprintet skred frem, og jeg begyndte at se nogle af leverancerne, indså jeg, at de ikke rigtig forstod de fulde krav til brugerhistorierne, eller hvad de egentlig betød.

Selvom man har målbare kriterier i historierne, kunne jeg se, at de ikke fuldt ud forstod, hvad de betød i større skala. Man skal altså teste forståelsen for at afgøre, om der er kommunikationskløfter. Vi har netop gennemgået en række brugerhistorier. Hvad er jeres forståelse af disse historier? Man kan også spørge: Hvordan mener I, at disse historier hænger sammen med projektudgivelsen som helhed?

Man kan spørge, om der er nogen bekymringer for, at historierne ikke opfylder kundernes fulde behov. En anden ting i forbindelse med kommunikationskløfter er at være opmærksom på kulturelt slang.

Alle lande har en vis mængde slang, som de bruger på deres sprog. I USA bruger vi for eksempel udtryk som at få et overslag. Men baseballparker findes ikke i andre lande. Eller udtryk som teknologisk kyndig. Sådanne kommunikationskløfter kan nogle gange skyldes genveje i sproget, altså det slang, vi har tendens til at bruge. Det skal man være forsigtig med.

Det er nogle af de ting, jeg ville holde øje med: at teste forståelsen og være forsigtig med det sprog, man bruger.

Hannah Clark: Jeg synes, det interessante ved det er, at det tvinger os til at se på, hvor meget fagjargon vi integrerer i vores daglige kommunikation. Især i denne branche er vi fyldt med jargon, der kan være lidt uigennemsigtig, selv for folk i branchen lokalt.

Har det tvunget dig til at evaluere nogle af de udtryk, du bruger, også sammen med dine lokale teams?

Craig Guarraci: Ikke så meget med lokale teams. De lokale teams var enten alle baseret i USA eller bestod af folk, der havde boet her i omkring et årti. Så det var ikke den store udfordring.

Det er typisk med folk, der stadig bor i et land uden for USA, eller hvor engelsk er deres andetsprog. Jeg begyndte faktisk at gennemlæse mine e-mails to gange, hvis jeg sendte en besked til et teammedlem i udlandet. Jeg læste dem to eller tre gange for at sikre, at jeg ikke antog noget eller brugte slang, og for at sikre, at tingene var objektive, så jeg kommunikerede så klart som muligt til teammedlemmer på et andet sted.

Hvis man ikke får det rigtigt, får man den frygtede forsinkelse på 24 timer. De modtager e-mailen, mens man sover, svarer, og man kommer på kontoret næste dag. Det fører bare til yderligere forsinkelser i projekterne.

Hannah Clark: Ja, det kan jeg forestille mig. Og jeg kan kun forestille mig, hvordan noget af det sprog, vi bruger, for eksempel at lukke sløjfen, er analogier, der er så integrerede i vores daglige tale, at det selv er svært at opdage dem, før man foretager den ekstra kontrol. Det er virkelig interessant.

Hvis man fører tilsyn med et projekt og arbejder med en række forskellige teams, der på en måde arbejder under ens ledelse, hvad så med samarbejdet mellem teams? Har du oplevet situationer, hvor du skulle hjælpe med at fremme samarbejdet og skabe større tillid mellem internationale teams, der arbejder sammen?

Craig Guarraci: Ja, her handler det om at forstå forskellige holdninger til eller tilgange til arbejdet. Et rigtig godt eksempel er deadlines. Nogle kulturer opfatter deadlines som meget flydende, fleksible og til forhandling, og så længe vi leverer omkring den dato, er det fint.

Andre kulturer, især i USA, mener, at en dato er en dato. Hvis vi siger, at vi leverer den 30. juli, så bliver det den dato. Man skal altså forsøge at forstå forskellige perspektiver på datoer. Det handler igen om at teste forståelsen, når man gennemgår den overordnede køreplan for udgivelsen, og spørge: Hvad er jeres forståelse af disse datoer?

Hvor kritiske mener I, at disse datoer er? Hvor vigtige er datoerne for projektet som helhed? Når det gælder tillid, handler det også om offentlige belønninger og anerkendelse og om virkelig at forstå, hvordan offentlige belønninger opfattes. Bliver de værdsat? Hvordan bør de gives? Skal en offentlig belønning deles med en person, der har bidraget, eller findes der kulturer, hvor man foretrækker, at belønningen gives til hele teamet frem for en bestemt person?

Man skal altså tage sig tid til at undersøge og forstå, hvordan forskellige kulturer ser på det. Hvad angår tillid, handler det også om at forstå og anerkende forskellige nationale helligdage. Folk i Kina fejrer for eksempel forårsfestivalen omkring februar og holder omkring en uges fri.

Man skal tage sig tid til at ønske dem tillykke på forhånd og naturligvis planlægge omkring disse datoer for at sikre, at der stadig er dækning for projektet og driften, men også indarbejde tiden i tidsplanen. Folk fra Indien fejrer Diwali omkring november. Man bør tage sig tid til at ønske dem tillykke og på en måde fejre de forskellige helligdage.

Jeg mener, at det gør en stor forskel for at opbygge tillid til et bestemt projekt.

Hannah Clark: Ja, det er virkelig interessant. Det må også skabe en rigtig god kulturel atmosfære.

Når det gælder udviklingsteams, der specifikt arbejder på afstand eller i hybride opsætninger, hvordan kan produktchefer så sikre, at samarbejde og ansvarlighed på tværs af tidszoner og kulturelle grænser forbliver gnidningsfri, og at alle tager ansvar for alt og er i stand til at svare rettidigt?

Craig Guarraci: Ud over de andre områder, jeg nævnte, såsom at gennemgå tidsplanen og teste forståelsen, altså de konkrete ting, er det her, vi kommer ind på produktchefens bløde færdigheder. Det handler virkelig om, at produktchefen går rundt.

Når man har startet det pågældende sprint, handler det om at tale med de lokale udviklere, der arbejder sammen med udviklere i andre lande og tidszoner, og bare spørge: Hvordan går det? Hvordan skrider tingene frem på dette område med denne funktion? Er der noget, der holder jer tilbage?

Hvordan går det med at arbejde sammen med den og den i et andet land? Produktchefen bør også følge op med sin modpart i det andet land. Nogle gange er der en hovedansvarlig i det pågældende land, for eksempel en projektleder eller en anden programleder, som arbejder direkte med udviklerne i et andet land.

Når man følger op med dem via e-mail eller chat, eller nogle gange holder uformelle møder, kan man spørge: Hvordan går det fra jeres side? Synes I, at I gør gode fremskridt? Er der problemer, vi skal tale om? Er der noget, der blokerer jer? Man skal stille åbne spørgsmål.

Jeg mener også, at de ting, jeg nævnte tidligere om arbejdsmoral, er med til at opbygge samarbejdet. Men gnidningsfrit samarbejde er efter min mening en kombination af at gennemgå tidsplanen og afklare, hvad der skal gøres, samt at bruge de bløde færdigheder.

Man skal gå rundt og have uformelle samtaler med folk lokalt såvel som med udviklingsmedarbejdere andre steder.

Hannah Clark: Før vi afslutter, er jeg meget nysgerrig efter at høre, om du har nogle anekdoter om et øjeblik, hvor du syntes, det var særligt givende eller interessant at arbejde i et miljø, der på en måde udsatte dig for alle disse forskellige kulturelle normer.

Craig Guarraci: Det må være den læringsplatform, jeg nævnte tidligere hos Microsoft. Det skyldes, at den var så omfattende og dækkede så mange forskellige lande, og at lokaliseringen og globaliseringen af et produkt som det til omkring 15 sprog virkelig udsatte mig for mange forskellige kulturelle holdninger og forskellige måder at se produktet på.

Der var også nogle specifikke ting under lokaliseringen. Når man for eksempel lokaliserer til tysk, kan det tyske ordforråd være ret langt. Hvis man forsøger at få en tysk oversættelse ind i den eksisterende brugergrænseflade, kan det være nødvendigt at foretage ændringer i brugergrænsefladen for at gøre dialogbokse, menuer og lignende længere.

Man lærer altså mange interessante ting ved at udføre arbejdet for andre kunder i andre lande.

Hannah Clark: Det er fascinerende. Jeg synes, det er så fantastisk at kunne lære mere om mennesker, og hvordan de lever og arbejder i forskellige lande. Det er virkelig spændende.

Craig, mange tak, fordi du ville være med. Det har været en meget interessant samtale, og vi har været omkring mange forskellige vinkler. Hvor kan folk følge dit arbejde online, hvis de gerne vil vide mere?

Craig Guarraci: De kan enten gå til mit websted, techpmcareerpath.com, eller finde mig på LinkedIn.

Hannah Clark: Fantastisk. Mange tak, fordi du ville være med.

Craig Guarraci: Selv tak.

Hannah Clark: Tak, fordi du lyttede med. Du kan få flere gode indsigter, vejledninger og værktøjsanmeldelser ved at abonnere på vores nyhedsbrev på theproductmanager.com/subscribe. Du kan høre flere samtaler som denne ved at abonnere på The CPO Club, uanset hvor du henter dine podcasts.