Slik bygger du tillit i produktteamet ditt og får støtte fra interessentene

Les utskriften:

Vi prøver ut et dataprogram for å transkribere podkastene våre. Tilgi eventuelle skrivefeil, ettersom boten ikke er korrekt 100 % av tiden.

Hannah Clark: La meg sette scenen: Du sitter i et møterom med alle de viktigste interessentene dine. Du ser til venstre og ser kundeansvarlig gjøre ferdig en e-post. Til høyre har utviklingssjefen armene i kors og ser skeptisk på presentasjonen din. Du er også ganske sikker på at den ledende produktdesigneren vurderer utformingen av lysbildene dine. På en eller annen måte må du overbevise alle disse menneskene om å bevege seg i samme retning. Men før du kan gjøre det, må du få dem til å stole på deg. Så hvordan vinner du den tilliten og får støtte?

I dag har jeg med meg Noa Goldman, ledende produktsjef i DagsHub. Noas karriere startet innen programvareutvikling, så hun har vært på begge sider – noe som betyr at hun vet hvor vanskelig det kan være å vinne gehør i tverrfunksjonelle team og ende opp med en sterk løsning på kundenes problemer. Noa delte oppskriften sin på hvordan man vinner interessentenes støtte, bygger relasjoner og styrker teamets resultater. La oss sette i gang.

Tusen takk for at du ville være med, Noa.

Noa Goldman: Takk. Jeg er glad for å være her. Takk for invitasjonen.

Hannah Clark: Ja, hyggelig å ha deg her. Noa, du har bakgrunn innen programvareutvikling, noe jeg er sikker på har vært nyttig på mange måter. Men jeg vil gjerne høre litt om hvordan det har påvirket tilnærmingen din til produktledelse.

Noa Goldman: Klart. Jeg var fullstack-utvikler i åtte år. En del av det var militærtjenesten min. En del var i små oppstartsbedrifter og store selskaper. Deretter gikk jeg over til å bli produktsjef, og i dag ligger ekspertisen min innen utviklerverktøy, noe det har hjulpet meg å være utvikler innen.

Det har selvfølgelig påvirket meg mye. Først og fremst utviklet det en sterk vane med å tenke på brukeren og kjøperprofilen. Jeg vet at dette er noe de fleste produktsjefer sier er veldig viktig for dem, og at de hele tiden tenker på brukeren og kjøperprofilen. Men ut fra min erfaring gjør de ofte ikke det.

For meg, som utvikler og nå produktsjef for utviklerverktøy, tenker jeg alltid på både brukeren og kjøperprofilen. Hvis vi for eksempel har en ny funksjon vi ønsker å lansere, eller kanskje et nytt produkt vi vil introdusere, tenker jeg alltid på meg selv når jeg prøver funksjonen. Hvordan ville jeg følt det med denne funksjonen?

Hvordan ville kollegaen min følt det med denne funksjonen? Hvordan ville vi brukt den? Hva måles vi på? Dette er noe som er veldig viktig, men som jeg føler ofte blir oversett. Når du lanserer en bestemt funksjon, må du alltid tenke på hvordan brukeren blir målt – altså ut fra hva – og om denne funksjonen eller dette produktet vil hjelpe brukeren med å forbedre resultatene sine eller hjelpe dem med målingene, og med hvordan ledelsen vurderer dem i det aktuelle bruksområdet.

Det påvirket selvfølgelig meg og vanen min med å tenke på brukerprofilen, men det hjalp meg også mye når det gjelder kjøperprofilen. Jeg føler nemlig at kjøperprofilen stadig blir utelatt i prosessen med å lansere nye funksjoner og produkter.

Når vi prøver å lansere et nytt produkt, tenker jeg alltid: Hvem er menneskene i kjøpsprosessen, og hvem er involvert? Hvem skal ta denne beslutningen? Jeg tenker for eksempel på meg selv. Som utvikler ville jeg gått til teamlederen min med en ny funksjon eller et nytt produkt og sagt: «Hei, dette er kult.»

Og teamlederne ville sagt: «Hvorfor vil dette hjelpe oss?» eller «Hvorfor skal vi betale dette bestemte selskapet?» Så jeg prøver alltid å tenke på disse profilene også. Dette er en veldig stor del av det å være produktsjef, men utviklerbakgrunnen min hjalp meg virkelig med det. Jeg tror også den påvirket meg mye når det gjelder prioritering.

For hver ny funksjon trenger jeg ikke alltid å gå og spørre teamlederen. Jeg føler at dette er en prosess som kan være litt krevende for teamlederne eller FoU-lederne når produktsjefen stadig spør dem hvor lang tid noe vil ta eller hvor stor innsats det krever. Jeg føler at dette er noe jeg i stor grad kan gjøre på egen hånd, til en viss grad.

Det hjalp meg og påvirket meg mye. Men jeg tror det viktigste jeg tok med meg fra å være utvikler, er forholdet til de andre utviklerne. Jeg vet hvordan jeg følte det overfor produktsjefen som utvikler, og jeg vet hvordan kollegene mine følte det overfor dem. Det er ikke alltid hyggelig og morsomt, og de er ikke alltid enige med dem.

Det jeg tok med meg fra dette, er at jeg ønsker at utviklerne jeg jobber med skal ha det bra med meg og ønske å hjelpe meg. Jeg vet hvor viktig relasjonen er, og jeg vet – eller tror i det minste at jeg vet – hvordan jeg kan vinne tilliten deres. Derfor vet jeg hvordan jeg skal velge hva det er verdt å kjempe for, hva som er viktigst og hva som er mindre viktig. Jeg tror det å innse at tillit er viktig, hjalp meg mye fordi jeg først var utvikler.

Hannah Clark: Jeg vil gjerne høre litt mer om det. Hvis en produktsjef som lytter, prøver å samarbeide best mulig med utviklingsteamet sitt, ikke ønsker bitterhet eller spenning – hva er noen av de beste praksisene produktsjefer bør ha i tankene for å jobbe effektivt med utviklingsteamet?

Noa Goldman: Ja, greit. Det oppstår selvfølgelig mange konflikter iblant, og det kan bli litt frustrerende for begge sider. Siden jeg har vært på begge sider, kjenner jeg dette veldig godt. Jeg tror noe av det viktigste er alltid å forklare hvorfor, og å forklare og knytte det til forretningssiden.

Vi produktsjefer, som befinner oss midt i alt, snakker hele tiden. Vi holder stadig kontakt med markedsføringsteamet, salgsteamet eller toppledelsen. Det gjør utviklere ikke like ofte. Når du presenterer noe du ønsker å utvikle for utviklerne og FoU-teamene, er det veldig tydelig for deg som produktsjef hva du ønsker, hvorfor du ønsker det, og hvordan det skal hjelpe selskapet.

Men utviklerne som hører det for første gang, vil ikke nødvendigvis se sammenhengen. Derfor er det veldig viktig å forklare hvorfor og knytte det til forretningssiden. Jeg vet spesifikt at hvis noen kommer og ber meg gjøre noe, er jeg ikke alltid enig fordi jeg ikke er sikker på hvorfor. Men hvis noen forklarer meg hvorfor, hva grunnen er og hvordan det vil hjelpe selskapet, er det langt mer sannsynlig at jeg støtter det – eller i det minste er åpen for en samtale. Jeg synes dette er veldig viktig. Og som produktsjefer er mye av arbeidet vårt avhengig av andre.

Vi gjør sjelden noe som innebærer å utvikle en funksjon eller drive markedsføring selv. Vi må alltid forklare andre hva vi ønsker å gjøre. Derfor er det veldig viktig å forklare hvorfor og knytte sammenhengene til forretningssiden. Jeg synes også det er veldig viktig å vise dataene. Hvis du forklarer hvorfor, forklarer forretningssiden og hvordan det vil hjelpe selskapet med å vokse, trenger du bevis. Du må underbygge det med de riktige dataene.

Jeg er sikker på at alle, eller de fleste produktsjefer, vil si at de er datadrevne. Men i disse konkrete situasjonene, når du viser det til utviklingsteamet, er det veldig viktig å være datadrevet. Du vil at de skal stole på deg, og du vil vinne tilliten deres og få dem med på laget. Dette er en annen veldig viktig ting, vil jeg si.

En annen ting jeg har lært med tiden, er – det høres kanskje rart ut – å bare gi ros. Som jeg sa tidligere, avhenger mye av jobben vår av andre. Når noen, for eksempel en utvikler, støtter deg og gjør det harde arbeidet med å utvikle en funksjon, er det veldig viktig å anerkjenne og verdsette det, og gi ros – si «godt jobbet» eller «bra gjort» i en en-til-en-samtale, men også i et større forum slik at alle vet det.

Personlig ønsker jeg å gjøre en god jobb når noen verdsetter arbeidet mitt. Jeg ønsker å fortsette og hjelpe til. Så jeg vil si at dette er det som hjelper meg mest når jeg samarbeider med utviklingsteamet.

Hannah Clark: Ja, jeg synes dette med ros er så viktig i omtrent alle roller. Det er en av de enkle tingene som folk ser ut til å overse, men som utgjør en stor forskjell i alle former for tverrfunksjonelt samarbeid.

Når vi snakker om samarbeid med tverrfunksjonelle team utover utviklingsteamet, hvilke gode praksiser har du funnet nyttige for å sikre at funksjonsutviklingen går smidig og at alle er på samme side, uavhengig av kompetanseområde?

Noa Goldman: Jeg husker én bestemt funksjon som virkelig hjalp meg med å lage min egen oppskrift på hvordan man håndterer langsiktige funksjoner som krever mye innsats og tid. Det var en konkret funksjon. Vi forbedret innføringen i et selskap jeg jobbet i som produktsjef, og vi klarte faktisk å øke konverteringsraten fra 15 % til 90 %.

Det var fantastisk, men det var en veldig lang reise. Jeg var en junior produktsjef, så det var virkelig krevende for meg å jobbe med tverrfunksjonelle team og samarbeide med markedsføring, salg og toppledelsen. Men det var der jeg laget min egen oppskrift på hvordan man gjør det. Det første steget, før du presenterer den nye funksjonen for teamet, er å sørge for at motivasjonen er riktig, og at dette faktisk er det riktige å gjøre internt akkurat nå.

Før jeg presenterer noe for andre, vil jeg selv være trygg og forsikre meg om at jeg gjør det riktige. Uavhengig av hvor ressurskrevende funksjonen er, prøver jeg alltid å sikre at jeg har forstått situasjonen riktig. Det innebærer å lytte til forretningssiden og forespørslene, føre en liste over forespurte funksjoner og se hvordan brukerne anvender produktet.

Jeg prøver alltid å sørge for at jeg har et bilde av hvordan ting er akkurat nå, hva som er viktig for selskapet, og hva som ikke er det. Når en stor funksjon kommer inn, er det første jeg gjør å forsikre meg selv om at dette er riktig. Jeg sammenligner det med bildet jeg har, og forsikrer meg om at dette er det som gir mest mening å gjøre nå, at jeg er komfortabel med det, og at det er dette vi skal gjøre.

Jeg sørger for at jeg er komfortabel med beslutningen. Etterpå dobbeltsjekker jeg meg selv mot dataene. Jeg sørger for at tallene gir mening, rydder dem opp på en god måte, går gjennom dem og kontrollerer at tallene gir mening, og at denne langsiktige funksjonen vil øke det tallet vi ønsker å forbedre.

Jeg sørger også på denne måten for at det ikke bare er jeg som har forelsket meg i en bestemt funksjon. Dataene overbeviser meg faktisk om at dette er det riktige å gjøre. Når jeg er helt overbevist om at dette er riktig, finner jeg en veldig tydelig måte å presentere det på. Det betyr at jeg prøver å lage én eller to setninger om problemet og hvorfor det er viktig å løse det med en gang.

Disse setningene skal forklare det både for den mest tekniske personen i rommet og den minst tekniske personen. Siden dette er en tverrfunksjonell teaminnsats, vil jeg at salg, markedsføring, toppledelsen og FoU-teamlederne alle skal forstå helt tydelig at dette er problemet, og at det å løse det vil bidra til å forbedre virksomheten.

Jeg sørger for å presentere det så tydelig at en fireåring kan forstå det, og deretter tar jeg dataene jeg allerede har ryddet opp i og presenterer dem på en veldig tydelig måte. Det høres kanskje rart ut, men du må alltid sørge for at dataene er godt definert og godt presentert. Grønt er for eksempel bra. Rødt er dårlig. Bruk riktig diagram.

Dette høres trivielt ut, men blir ofte ikke presentert riktig. Jeg sørger for at problemet og dataene som underbygger det, presenteres på en veldig god og tydelig måte, slik at alle i rommet forstår det. Dette er det andre steget. Det tredje steget høres rart ut, men i boken min kaller jeg det «Del og hersk». Det kan ha en litt negativ betydning, men det er ikke negativt i det hele tatt.

Det betyr i praksis at jeg, før jeg presenterer funksjonen for hele rommet og alle lederne i det tverrfunksjonelle teamet, prøver å ha en-til-en-samtaler med hver leder fra hvert av de tverrfunksjonelle teamene. Dette vil ta mye lengre tid, men det vil være verdt det. Jeg setter meg individuelt med markedsføringssjefen, salgssjefen, FoU-sjefen og alle andre som er involvert i prosessen, og som jeg trenger å overbevise om å støtte forslaget.

Ved å gjøre dette får jeg dem først og fremst til å føle seg hørt og lyttet til. Som jeg sa tidligere: Hvis du vil få noen med på laget, trenger de ikke å lytte til deg eller være enige. De har andre ting å tenke på. Hvis du vil få dem med, må du få dem til å føle at de teller og er viktige.

Så det er verdt det å sitte med dem én til én og ha en kort eller lang samtale, eller gjøre det du trenger, selv om det tar litt lengre tid. Det hjelper dem med å føle seg hørt, og når de føler seg hørt, ønsker de å hjelpe deg. Det andre dette gjør, er at det forbereder meg til det andre steget, som er møtet med alle i samme rom.

Jeg vet allerede hvordan alle føler det. Jeg er forberedt på svarene deres og på det de kommer til å si. Jeg vet også hvordan de kommer til å svare på det jeg sier om denne funksjonen. Til slutt vil disse en-til-en-samtalene hjelpe deg fordi andre ofte har veldig gode ideer, og du ønsker å integrere dem i funksjonen.

Det vil selvfølgelig få dem til å føle seg mer som en del av det fordi ideene deres teller, men de kan også ha gode ideer som du ønsker å høre. Ved å gjennomføre disse en-til-en-samtalene skaper du faktisk en bedre funksjon som de fleste i teamet vil støtte utviklingen av. Dette er altså et steg: å ha en en-til-en-samtale med hver eneste av dem.

Ut fra denne fremgangsmåten er de fleste involverte, i hvert fall etter min erfaring, allerede med på laget på dette tidspunktet fordi de føler seg som en del av prosessen og at de blir hørt. Steget etter det er teammøtet, der alle samles i samme rom. Det er litt krevende.

Det gjør deg litt nervøs, men du skal være godt forberedt nå fordi du har hatt alle disse en-til-en-samtalene. Du setter dem alle i samme rom og samler dem, og så presenterer du ganske enkelt det samme som du presenterte i en-til-en-samtalene. Hvis du husker de foregående stegene, har du de én eller to setningene som beskriver problemet på en veldig enkel måte, du har dataene, og du har allerede snakket med alle i rommet.

Så du gjør det bare igjen og presenterer det på nytt. På dette tidspunktet vil de fleste være med på laget, eller i det minste åpne for en samtale. I dette møtet ønsker du først og fremst å sørge for at alle blir hørt i samme forum, i et større forum, og få tilslutning fra de fleste.

Du kommer aldri, eller nesten aldri, til å få alle i rommet til å være enige. Men når de føler at de blir hørt, er de i det minste åpne for ideen. På dette steget bør de fleste være med. Dette er det siste steget for å få alle med på laget. Stegene etter dette kaller jeg «å ta scenen».

Når alle er positive til eller arbeider med å utvikle funksjonen, og prosessen allerede går fremover, må du sørge for å holde alle oppdatert. Ta scenen, enten ukentlig eller månedlig, eller bruk et eksisterende statusmøte og bruk noen minutter på å oppdatere alle. Jeg liker alltid å vise de visuelle endringene.

Jeg liker å dele en stor funksjon opp i mindre, raske gevinster. Da kan vi se endringene og fremgangen visuelt. Ved å oppdatere alle holder du engasjementet ved like. De vil høre om det, de ser at vi gjør fremskritt, og det hjelper virkelig. Det er også en god anledning til å vise dataene hvis funksjonen allerede er lansert, og vise fremgang og tilbakeslag.

Bare sørg for at du er veldig tydelig og ærlig om prosessen, så vil alle være med. Det er også en god anledning til igjen å høre tankene og ideene deres, og hva de synes om fremgangen vi allerede har gjort. Når du gjør dette gjennom hele utviklingen av funksjonen, er det i praksis dette som skal hjelpe alle de tverrfunksjonelle teamene med å være konstant med og ønske å hjelpe.

Hannah Clark: Det er en flott prosess. Jeg synes også den er veldig enkel å følge. Men jeg er nysgjerrig: Hva skjer, eller hvordan går du frem, når du har et mer splittet rom, når det ikke er full enighet, eller når det ikke er tilstrekkelig konsensus til at en funksjon kan gå videre?

Noa Goldman: Hvis jeg er sikker på at dette er riktig å gjøre, og at det gir mening for selskapet, prøver jeg alltid å tenke på at vi til syvende og sist er ett team, og at vi alle ønsker at selskapet skal lykkes. Jeg prøver igjen å dele og herske, forklare forretningen og hvorfor, og overbevise dem om at vi er på samme lag.

Til slutt fungerer det. Hvis det fortsatt ikke fungerer, prøver jeg å velge kampene mine. Hvis noen for eksempel ikke støtter forslaget, prøver jeg å finne ut hvordan jeg skal overbevise dem. Kanskje jeg lar dem få gjennomslag for andre funksjoner, eller hjelper dem med å fremme sin agenda på en bestemt måte.

For meg handler det igjen om relasjoner. Når du hjelper noen, vil de ofte ønske å hjelpe deg tilbake. Det handler derfor om å navigere i disse forhandlingene og sørge for at alle til slutt får det de ønsker.

Hannah Clark: Ja, det gir mening. La oss skifte spor litt og snakke om prioritering. Som jeg alltid sier, er funksjonsprioritering en stor del av det å lede og utvikle funksjoner. Hva er dine suksessoppskrifter eller noen av metodene du har brukt for å prioritere funksjoner?

Noa Goldman: Jeg har min egen ledestjerne, og den er virksomheten. Uansett hva selskapet trenger for å vokse, er dette ledestjernen min. Det er dette jeg sammenligner alt med. Når alt kommer til alt, er jobben min å hjelpe virksomheten og selskapet med å vokse.

Det handler ikke om hvilke funksjoner jeg liker, eller hva teamene mine ønsker å utvikle akkurat nå. Det handler om å hjelpe selskapet. Jeg beskrev bildet jeg alltid har. Jeg følger hele tiden med på hva brukerne ber om, hva virksomheten etterspør, hva markedsføringen ønsker, og hele markedet.

Jeg prøver å tenke på virksomheten. For hver funksjon spør jeg: Er dette det som vil hjelpe selskapet mest med å vokse akkurat nå? Hvis det gir mening, og svaret er ja, stiller jeg det neste spørsmålet: Er dette den enkleste måten å utvikle funksjonen på?

Når det gjelder prioritering, velger jeg alltid det som hjelper virksomheten mest, og som er enklest å utvikle og krever minst innsats. Det er de to spørsmålene jeg stiller meg selv. Hvis du kan svare på disse to spørsmålene, kan du prioritere alt.

Hannah Clark: Vi begynner å gå tom for tid, men jeg ville avslutte med noe litt morsommere. Jeg har begynt å spørre noen av gjestene våre om musikk, og det er litt på siden. Enten du hører på musikk på jobb eller utenom jobb: Er det en artist, et album eller en musikksjanger du virkelig liker akkurat nå?

Noa Goldman: Wow. Dette var et veldig morsomt spørsmål. Jeg er så glad for at du spurte. Jeg vet ikke engang hvorfor jeg er så glad. Jeg hører definitivt på musikk hele tiden. Jeg prøver å gjøre det mens jeg arbeider med ting som ikke krever så mye tenking, ellers blir jeg forvirret. Hovedartisten jeg hører på akkurat nå, er Paulo Nutini.

Jeg vet ikke om du har hørt om ham, men han er fantastisk. Han ga nettopp ut et nytt album som jeg elsker, og drømmen min er å se ham spille på en konsert. Det kommer sannsynligvis ikke til å skje, men jeg skal jobbe med saken, så får vi se.

Hannah Clark: Å, flott. Jeg har ikke hørt om ham, men jeg håper vi kan sette sammen en spilleliste med podkastmusikk for produktsjefer, basert på alle gjestene våre.

Noa Goldman: Det hadde jeg likt.

Hannah Clark: Ja. Jeg vil gjerne sjekke ham ut. Tusen takk for at du ville være med oss i dag, Noa. Jeg setter stor pris på tiden din, og jeg elsker at du ga oss en oppskrift i et så godt og lettfattelig format som gir oss konkret kunnskap. Jeg setter virkelig pris på tiden din her.

Noa Goldman: Takk. Jeg likte det veldig godt, virkelig. Tusen takk.

Hannah Clark: Takk for at du lyttet. For flere gode innsikter, veiledninger og verktøyanmeldelser kan du abonnere på nyhetsbrevet vårt på theproductmanager.com/subscribe. Du kan høre flere samtaler som denne ved å abonnere på Produktlederen, uansett hvor du får podkastene dine.