Sådan opbygger du tillid i dit produktteam & får opbakning fra interessenter

Læs transskriptionen:

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

Hannah Clark: Lad mig sætte scenen: Du sidder i et mødelokale med alle dine vigtigste interessenter. Du kigger til venstre og ser Account Director afslutte en e-mail. Til højre har Head of Engineering armene over kors og ser skeptisk på dit præsentationsmateriale. Du er også ret sikker på, at Lead Product Designer bedømmer layoutet på dine slides. På en eller anden måde skal du overbevise alle disse mennesker om at bevæge sig i samme retning. Men før du kan gøre det, skal du have dem til at stole på dig. Så hvordan vinder du deres tillid og får deres opbakning?

I dag har jeg Noa Goldman med, Lead Product Manager hos DagsHub. Noas karriere begyndte inden for softwareudvikling, så hun har stået på begge sider – hvilket betyder, at hun ved, hvor svært det kan være at vinde gehør i tværfunktionelle teams og ende med en stærk løsning på kundernes problemer. Noa delte sin opskrift på at vinde interessenters opbakning, opbygge relationer og styrke teamets resultater. Lad os komme i gang.

Tusind tak, Noa, fordi du vil være med.

Noa Goldman: Selv tak. Jeg er glad for at være her. Tak, fordi du inviterede mig.

Hannah Clark: Ja, det er dejligt at have dig med. Noa, du har en baggrund inden for softwareudvikling, hvilket jeg er sikker på har været nyttigt på mange måder. Men jeg vil gerne høre lidt om, hvordan det har påvirket din tilgang til produktledelse.

Noa Goldman: Selvfølgelig. Jeg var full-stack-udvikler i otte år. En del af tiden var under min militærtjeneste. En del var i små startups og store virksomheder. Derefter skiftede jeg til at blive produktchef, og min ekspertise ligger i dag inden for udviklerværktøjer, hvor det har hjulpet mig, at jeg selv har været udvikler på området.

Det har naturligvis påvirket mig meget. Først og fremmest har det udviklet en stærk vane med også at tænke på brugeren og køberpersonaen. Jeg ved, at det er noget, de fleste produktchefer siger, er meget vigtigt for dem, og at de hele tiden tænker på brugeren og køberpersonaen. Men efter min erfaring gør de det ofte ikke.

For mig betyder det, at jeg som udvikler og nu produktchef for udviklerværktøjer altid tænker på både brugeren og køberpersonaen. Hvis vi for eksempel har en ny funktion, vi vil udgive, eller måske et nyt produkt, vi vil lancere, tænker jeg altid på mig selv, når jeg prøver funktionen. Hvordan ville jeg have det med denne funktion?

Hvordan ville min kollega have det med funktionen? Hvordan ville vi bruge den? Hvad bliver vi målt på? Det er noget, jeg oplever, ofte bliver overset. Når man udgiver en bestemt funktion, skal man altid tænke på, hvordan brugeren bliver målt – altså ud fra hvad – og om denne funktion eller dette specifikke produkt vil hjælpe brugeren med at forbedre sig eller hjælpe vedkommende med sine målinger og med, hvordan ledelsen ser på dem i det konkrete anvendelsestilfælde.

Det har naturligvis påvirket min vane med at tænke på brugerpersonaen, men det har også hjulpet mig meget, når det gælder køberpersonaen. Igen føler jeg, at køberpersonaen ofte bliver glemt i processen med at udgive nye funktioner og produkter.

Når vi prøver at lancere et nyt produkt, tænker jeg altid: Hvem er de involverede i købsprocessen? Hvem skal træffe beslutningen? Jeg tænker for eksempel på mig selv. Som udvikler ville jeg gå til min teamleder med en ny funktion eller et nyt produkt og sige: Hej, det her er smart.

Og teamlederne ville spørge: Hvorfor vil det hjælpe os, eller hvorfor skal vi betale denne specifikke virksomhed? Derfor prøver jeg altid også at tænke på disse personaer. Det er en meget stor del af mig som produktchef, men min baggrund som udvikler har virkelig hjulpet mig. Jeg synes også, den har påvirket mig meget, når det gælder prioritering.

For hver ny funktion behøver jeg ikke altid gå hen og spørge teamlederen. Jeg føler, at det er en proces, der kan være lidt svær for teamlederne eller R&D-lederne, når produktchefen hele tiden spørger dem, hvor lang tid noget vil tage, eller hvor stor indsatsen er. Derfor føler jeg, at det til en vis grad er noget, jeg selv kan gøre.

Det har hjulpet mig og påvirket mig meget. Men jeg tror, det vigtigste, jeg tog med fra at være udvikler, er relationen til de andre udviklere. Jeg ved, hvordan jeg selv havde det med produktchefen som udvikler, og jeg ved, hvordan mine kolleger havde det med dem. Det er ikke altid rart og sjovt, og de er ikke altid enige med dem.

Det, jeg tager med mig, er, at jeg ønsker, at de udviklere, jeg arbejder sammen med, skal have det godt med mig og have lyst til at hjælpe mig. Jeg ved, hvor vigtig relationen er, og jeg ved – eller i det mindste tror jeg, at jeg ved – hvordan man vinder deres tillid. Derfor ved jeg også, hvordan jeg vælger, hvad det er værd at kæmpe for, hvad der er vigtigere, og hvad der er mindre vigtigt. Jeg tror, at det hjalp mig meget at indse, hvor vigtig tilliden er, fordi jeg først selv var udvikler.

Hannah Clark: Jeg vil gerne høre lidt mere om det. Hvis en produktchef, der lytter med, prøver at arbejde så godt som muligt sammen med sit udviklingsteam, ikke ønsker bitterhed eller spændinger, hvilke bedste praksisser bør produktchefer så have for øje, når de arbejder effektivt sammen med udviklingsteamet?

Noa Goldman: Ja, okay. Der opstår naturligvis mange konflikter, og det kan blive lidt frustrerende for begge sider. Jeg har selv stået på begge sider, så det kender jeg godt. Jeg tror, noget af det vigtigste er altid at forklare hvorfor – at forklare det og knytte det til forretningssiden.

Vi produktchefer befinder os midt i det hele og taler hele tiden med marketingteamet, salgsteamet eller den øverste ledelse. Det gør udviklere ikke så ofte. Når du præsenterer noget, du gerne vil have udviklet, for udviklerne og R&D-teamene, er det meget tydeligt for dig som produktchef, hvad du ønsker, hvorfor du ønsker det, og hvordan det skal hjælpe virksomheden.

Men de udviklere, der hører det for første gang, vil ikke nødvendigvis selv forbinde prikkerne. Derfor er det virkelig vigtigt at forklare hvorfor og knytte det til forretningssiden. Jeg ved specifikt, at hvis nogen kommer og beder mig om at gøre noget, er jeg ikke altid enig, fordi jeg ikke er sikker på hvorfor. Men hvis nogen forklarer mig hvorfor, hvad årsagen er, og hvordan det vil hjælpe virksomheden, vil jeg højst sandsynligt være med på den eller i det mindste være åben for en samtale. Jeg synes, det er meget vigtigt. Som produktchefer er det meste af vores arbejde afhængigt af andre.

Vi laver sjældent selv noget, der består i at udvikle en funktion eller stå for markedsføringen. Vi skal altid forklare andre, hvad vi vil gøre. Derfor er det vigtigt at forklare hvorfor og forbinde prikkerne set fra forretningssiden. Jeg synes også, det er meget vigtigt at vise data. Hvis du forklarer hvorfor, forklarer forretningssiden, og hvordan det vil hjælpe virksomheden med at vokse, har du brug for beviser og skal understøtte det med de rigtige data.

Jeg er sikker på, at alle eller de fleste produktchefer vil sige, at de er datadrevne. Men netop i disse situationer, når du viser det til udviklingsteamet, er det virkelig vigtigt at være datadrevet. Igen vil du have, at de stoler på dig, at du vinder deres tillid, og at de bakker op. Det er endnu en meget vigtig ting, vil jeg sige.

En anden ting, jeg har lært med tiden, er – det lyder måske mærkeligt – simpelthen at give ros. Som jeg sagde før, afhænger meget af vores arbejde af andre. Når en udvikler bakker op og udfører det hårde arbejde med at udvikle en funktion, er det virkelig vigtigt at anerkende og værdsætte det samt give ros og sige: “Godt arbejde” eller “Flot klaret” både én til én og i et større forum, så alle ved det.

Personligt får jeg lyst til at gøre et godt stykke arbejde, når nogen værdsætter mit arbejde. Jeg får lyst til at fortsætte og hjælpe. Så jeg vil sige, at det er de ting, der hjælper mig mest i samarbejdet med udviklingsteamet.

Hannah Clark: Ja, jeg synes, det med ros er så vigtigt i næsten alle roller. Det er en af de simple ting, som folk tilsyneladende bare forsømmer, selvom det gør en stor forskel i alle former for tværfunktionelt samarbejde.

Men i den forbindelse: Når du tænker på samarbejde med tværfunktionelle teams ud over selve udviklingsteamet, hvilke bedste praksisser har du så fundet nyttige for at sikre, at udviklingen af din funktion forløber gnidningsfrit, og at alle er på samme side, uanset deres fagområde?

Noa Goldman: Ja, jeg husker en bestemt funktion, som virkelig hjalp mig med at skabe min egen opskrift på, hvordan man håndterer langsigtede funktioner, der kræver en stor indsats og meget tid. Det var en konkret funktion. Vi forbedrede onboardingprocessen i en virksomhed, hvor jeg arbejdede som produktchef, og det lykkedes faktisk at øge konverteringsraten fra 15 % til 90 %.

Det var fantastisk, men det var en meget lang rejse. Jeg var en ny produktchef, så det var virkelig svært for mig at arbejde med tværfunktionelle teams og samarbejde med marketing, salg og den øverste ledelse. Men det var her, jeg lavede min egen kogebog for, hvordan man gør. Det første skridt for mig er – allerede inden du præsenterer den nye funktion for teamet – at sikre, at motivet er det rigtige, og at det internt er det rigtige at gøre lige nu.

Før jeg vil præsentere den for andre, skal jeg selv være sikker på, at jeg gør det rigtige. Uanset hvor krævende funktionen er, prøver jeg altid at sikre mig, at jeg har forstået kortet korrekt. Det betyder, at jeg altid lytter til forretningssiden og dens ønsker, holder en liste over brugernes funktionsønsker og ser på, hvordan brugerne anvender produktet.

Jeg prøver altid at sikre, at jeg har et overblik over, hvordan tingene ser ud lige nu, hvad der er vigtigt for virksomheden, og hvad der ikke er. Når en stor funktion kommer ind, er det første, jeg gør, at sikre mig selv, at det er det rigtige. Jeg sammenligner den med det overblik, jeg har, og sikrer mig: Okay, det er det, der giver mest mening at gøre nu, og jeg er indforstået med, at det er det, vi gør.

Jeg sikrer mig altså, at jeg er tilfreds med beslutningen. Når jeg har gjort det, dobbelttjekker jeg mig selv med data. Jeg sikrer, at tallene giver mening. Jeg rydder virkelig pænt op i dem, gennemgår dem og sikrer, at tallene giver mening, og at det at udvikle denne specifikke langsigtede funktion vil øge det, vi ønsker at opnå.

Jeg sikrer, at dataene er korrekte og giver mening. På den måde sikrer jeg også, at det ikke bare er mig, der forelsker mig i en bestemt funktion. Dataene overbeviser mig faktisk om, at det er det rigtige at gøre. Når jeg er fuldt overbevist om, at det er det rigtige at gøre, finder jeg en meget tydelig måde at præsentere det på. Det betyder, at jeg prøver at formulere en eller to sætninger om problemet og om, hvorfor det er vigtigt at løse det med det samme.

Sætningerne skal forklare det både for den mest tekniske og den mindst tekniske person i rummet. Da det er en tværfunktionel teamindsats, vil jeg have, at salg, marketing, den øverste ledelse og R&D-teamlederne alle forstår helt klart: Dette er problemet, og sådan vil løsningen hjælpe med at forbedre forretningen.

Jeg sørger for at præsentere det meget enkelt, som om jeg forklarede det til en fireårig, og derefter tager jeg de data, jeg allerede har ryddet op i, og præsenterer dem meget tydeligt. Det lyder måske mærkeligt, men man skal altid sikre, at dataene er veldefinerede og godt præsenteret. For eksempel: Grøn er godt. Rød er dårligt. Brug den rigtige graf.

Det er ting, der lyder meget banale, men de bliver ofte ikke præsenteret korrekt. Jeg sørger derfor for, at problemet og de data, der understøtter det, bliver præsenteret på en rigtig god og tydelig måde, så alle i rummet forstår det. Det er det andet skridt. Det tredje skridt lyder mærkeligt, men i min bog kalder jeg det Del og erobr, hvilket kan have en lidt negativ betydning, men det er slet ikke negativt.

Det betyder grundlæggende, at jeg, før jeg præsenterer funktionen for hele rummet og alle lederne fra det tværfunktionelle team, prøver at have individuelle samtaler med hver leder fra hvert tværfunktionelt team. Det tager meget længere tid, men det er det værd. Jeg sætter mig individuelt med marketingchefen, salgschefen, R&D-chefen og alle andre, der er involveret i processen, og som jeg har brug for at overbevise om at bakke op.

På den måde får jeg dem først og fremmest til at føle sig hørt og lyttet til. Som jeg sagde før: Hvis du vil have nogen med om bord, behøver de ikke lytte til dig, og de behøver ikke være enige. De har andre ting i tankerne. Hvis du vil have dem med, skal du få dem til at føle, at de tæller, og at de er vigtige.

Så det er det værd at sidde med dem én til én og have en kort eller lang samtale eller hvad end, der er nødvendigt, også selvom det tager lidt længere tid for dig. Det hjælper dem med at føle sig hørt, og når de føler sig hørt, får de lyst til at hjælpe dig. Det andet, det gør, er, at det virkelig forbereder mig på det næste skridt, som er mødet med alle i samme rum.

Jeg ved allerede, hvad alle føler. Jeg er forberedt med svar på det, de vil sige, og jeg ved, hvordan de vil reagere på det, der bliver sagt om funktionen. Endelig hjælper disse individuelle samtaler dig, fordi andre ofte har rigtig gode idéer, som du gerne vil integrere i funktionen.

Det får dem naturligvis til at føle sig mere som en del af det, fordi deres idéer tæller, men de kan også have gode idéer, som du gerne vil høre. Ved at gennemføre disse individuelle samtaler hjælper du faktisk dig selv med at skabe en bedre funktion, som de fleste i teamet vil bakke op om at udvikle. Det er altså et skridt at have en individuel samtale med hver eneste af dem.

Ud fra min erfaring vil de fleste involverede allerede bakke op på dette tidspunkt, fordi de føler, at de er en del af processen, og at der bliver lyttet til dem. Det næste skridt er teammødet, hvor alle samles i samme rum. Det er lidt svært.

Det gør dig lidt nervøs, men du burde være forberedt nu, fordi du har haft alle de individuelle samtaler. Du sætter dem alle i samme rum og samler dem, og så præsenterer du bare det samme, som du præsenterede i de individuelle samtaler. Hvis du husker de tidligere skridt, har du en eller to sætninger, der meget enkelt beskriver problemet, og du har dataene, og du har allerede talt med alle i rummet.

Så du gør det bare igen og præsenterer det igen. På dette tidspunkt vil de fleste være med på den eller i det mindste åbne for en samtale. Det, du ønsker i mødet, er først og fremmest at sikre, at alle bliver hørt i det samme forum, i et større forum, og at få de flestes accept.

Du får aldrig – eller næsten aldrig – alle i rummet til at være enige, men når de alle føler, at der bliver lyttet til dem, er de i det mindste åbne over for idéen. På dette trin bør de fleste være med. Det er det sidste skridt i at få alle med om bord. Skridtene derefter kalder jeg bare at gå på scenen.

Når alle er grønne, eller når udviklingen af funktionen allerede er i gang, skal du sikre dig, at du hele tiden holder alle opdateret. Gå på scenen, uanset om det er ugentligt eller månedligt, eller brug et eksisterende statusmøde og brug nogle minutter på at opdatere alle. Jeg kan altid godt lide at vise de visuelle ændringer.

Jeg kan godt lide at dele en stor funktion op i mindre, hurtige gevinster. Så kan vi visuelt se ændringerne og fremskridtene. Ved at opdatere alle holder de engagementet ved lige. De vil høre om det, de kan se, at vi gør fremskridt, og det hjælper virkelig. Det er også en god mulighed for at vise dataene, hvis funktionen allerede er udgivet, og vise både succeser og fiaskoer.

Sørg bare for at være meget tydelig og ærlig om processen, så vil alle bakke op. Det er også en god mulighed for igen at høre deres tanker, høre deres idéer og høre, hvad de synes om de fremskridt, vi allerede har gjort. At gøre det under hele udviklingen af funktionen er grundlæggende det, der skal hjælpe alle de tværfunktionelle teams med hele tiden at bakke op og have lyst til at hjælpe.

Hannah Clark: Det er en fantastisk proces. Jeg synes også, den er meget let at følge. Men jeg er nysgerrig: Hvad sker der, eller hvordan griber du det an, når der er lidt mere delte meninger, når der ikke er fuld enighed hele vejen rundt, eller når der ikke er tilstrækkelig konsensus til at føre en funktion videre?

Noa Goldman: Okay. Hvis jeg er sikker på, at det er det rigtige at gøre, og at det giver mening for virksomheden, prøver jeg altid at huske på, at vi i sidste ende er på samme team, og at vi alle ønsker, at virksomheden skal lykkes. Derfor prøver jeg igen at dele og erobre, forklare forretningen og hvorfor og overbevise dem om, at vi er på samme team.

Til sidst virker det. Hvis det stadig ikke virker, prøver jeg at vælge mine kampe. Hvis nogen for eksempel ikke bakker op, prøver jeg at vælge, hvordan jeg vil overbevise dem – om det betyder at lade dem få andre funktioner, eller måske hjælpe dem med at fremme deres egen dagsorden på bestemte måder.

Igen handler det for mig alt sammen om relationer. Når du hjælper nogen, vil de ofte gerne hjælpe dig tilbage. Det handler derfor om at navigere gennem disse forhandlinger og sikre, at alle til sidst får det, de ønsker.

Hannah Clark: Ja, det giver mening. Lad os skifte spor til prioritering. Som jeg altid siger, er funktionsprioritering en stor del af det, når vi taler om at lede og udvikle funktioner. Hvad er dine hemmeligheder bag succes, eller hvilke metoder har du brugt til at prioritere funktioner?

Noa Goldman: Okay. Jeg har min egen nordstjernemåling, og det er forretningen. Hvad end virksomheden har brug for for at vokse, er min nordstjernemåling. Det er det, jeg sammenligner alt med. Når alt kommer til alt, er mit arbejde at hjælpe forretningen og virksomheden med at vokse.

Det handler ikke om, hvilke funktioner jeg elsker, eller hvad mine teams ønsker at udvikle lige nu. Det handler om at hjælpe virksomheden. Jeg beskrev det overblik, jeg altid har. Jeg holder hele tiden øje med, hvad brugerne efterspørger, virksomhedens ønsker, hvad marketing vil, og hele markedet.

Jeg prøver at tænke på forretningen. For hver eneste funktion spørger jeg: Er dette det, der vil hjælpe virksomheden mest med at vokse lige nu? Hvis det giver mening, og svaret er ja, spørger jeg derefter: Er dette den nemmeste måde at udvikle funktionen på?

Når det gælder prioritering, vælger jeg altid det, der hjælper forretningen mest, og som er nemmest at udvikle og kræver mindst indsats. Det er de to spørgsmål, jeg stiller mig selv. Hvis du kan besvare de to spørgsmål, kan du prioritere alt.

Hannah Clark: Vi er næsten løbet tør for tid, men jeg ville gerne slutte med noget lidt sjovere. Jeg har efterhånden spurgt nogle af vores gæster om musik, og det er lidt et sidespring. Uanset om du lytter til musik på arbejdet eller uden for arbejdet: Er der en kunstner, et album eller en musikgenre, du virkelig er optaget af lige nu?

Noa Goldman: Wow. Det er et meget sjovt spørgsmål. Jeg er så glad for, at du spurgte. Jeg ved ikke engang, hvorfor jeg er så glad. Jeg lytter helt sikkert til musik hele tiden. Jeg prøver at gøre det, mens jeg arbejder på ting, der ikke kræver så meget tænkning, for ellers bliver jeg forvirret. Den kunstner, jeg primært lytter til lige nu, er Paulo Nutini.

Jeg ved ikke, om du har hørt om ham, men han er fantastisk. Han har lige udgivet et nyt album, som jeg elsker, og min drøm er at se ham spille koncert, hvilket nok ikke kommer til at ske, men jeg vil arbejde på det, så vi får se.

Hannah Clark: Det lyder godt. Jeg har ikke hørt om ham, men jeg håber, at vi kan lave en playliste med produktchef-podcasts fra alle vores gæster.

Noa Goldman: Det ville jeg elske.

Hannah Clark: Ja. Jeg vil gerne tjekke ham ud. Mange tak, fordi du ville være med i dag, Noa. Jeg sætter virkelig pris på din tid, og jeg elsker, at du gav os en opskrift. Det er et så godt og letforståeligt format til at få konkret viden med sig. Så jeg sætter virkelig pris på din tid her.

Noa Goldman: Selv tak. Jeg nød det virkelig meget. Tusind 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å Product Manager, uanset hvor du får dine podcasts.