Menneskedrevet produktutvikling (med Sam Higham fra Glean)

Michael Luchen

Som praktiserende eller aspirerende produktledere blir vi stadig bombardert med sertifiseringer og spesialisert opplæring som vi får høre er avgjørende for faget vårt. Å følge en tilpasset prosess for å utvikle produkter er nøkkelen til suksess, eller det er i alle fall det vi får høre. Fortsett å lytte, for i dag skal vi gå i dybden på dette området. Er sertifiseringene og de tilpassede prosessene så nødvendige som de ser ut til å være? Eller finnes det noe bedre?

Dette er podkasten The CPO Club, stemmene til et fellesskap som skriver læreboken for produktledelse, utvikling og strategi. Vi får støtte fra Crema, et byrå for digitale produkter som hjelper enkeltpersoner og selskaper med å lykkes gjennom kreativitet, teknologi og kultur. Finn ut mer på crema.us. Fortsett å lytte for å få praktiske og autentiske innsikter som kan hjelpe deg med å lykkes i produktledelsens verden.

Dagens tema ligger mitt hjerte og produktledelse nært. Jeg er privilegert som får ønske Sam Higham velkommen til programmet for å snakke om det. Sam er en brukerfokusert produktleder med en karriere som har vist at han kan forbedre produkter, prosesser og mennesker. Han trives både med detaljene og de strategiske sidene ved å få produkter til å fungere, fra deres funksjonelle grunnlag til de kommersielle forventningene de innfrir.

Sam har en grenseløs interesse for hvordan teknologi og psykologi samspiller i forbrukernes reiser, og støtter team i å finne måter å slå sammen og finjustere disse to områdene på for å levere best mulige resultater. Sam er produktsjef i Glean, en løsning for notater, læring og produktivitet.

Gleans løsning for notater tar opp lydnotater som du kan fange opp og lære av informasjon mer effektivt gjennom. Sam arbeider også deltid som produktveileder og kursholder innen produktledelse for Mind the Product, der han hjelper enkeltpersoner med å finne veien gjennom den karrieren innen produktledelse de ønsker seg.

Hei, Sam! Velkommen til programmet.

Sam Higham

Hei, takk for at jeg fikk komme.

Michael Luchen

Hyggelig å ha deg her. For å begynne: Kan du fortelle hvordan du kom dit du er i dag?

Sam Higham

Ja, selvfølgelig. Kort sagt: mye prøving og feiling. Jeg tror jeg, som mange andre som arbeider med produkter, mer eller mindre ramlet inn i produktledelse i løpet av de siste ti årene eller så.

Jeg tror jeg har hatt nesten alle roller man kan ha innen produktutvikling, bortsett fra programmering. Selv der har jeg riktignok prøvd meg på noen ganske dårlige API-er tidligere. Jeg begynte formelt å arbeide med produktledelse for omtrent åtte år siden, selv om det ikke var stillingstittelen min.

I løpet av denne perioden har jeg hele tiden forsøkt å finjustere hva det vil si å arbeide med produkter, og hvordan man blir bedre fra dag til dag. Mye av dette har handlet om å finne ut hva produktledelse egentlig er. Og det er et spørsmål jeg fortsatt stiller meg hver eneste dag, for å være ærlig.

Michael Luchen

Ja, hva er det? Det er et ganske stort spørsmål.

Sam Higham

For meg handler det om å finne den beste måten å skape verdi på, gitt konteksten du befinner deg i, begrensningene du har og menneskene du arbeider sammen med. Den idealiserte tilnærmingen til produktledelse er fantastisk, men den tar ikke nødvendigvis hensyn til situasjonen i de 95 prosent eller mer av organisasjonene som ikke har alt som trengs for å gjøre ting etter boken.

Det er der noe av utfordringen oppstår. Det finnes mye god og ambisiøs informasjon der ute som sier: Slik kan du arbeide med produkter i et perfekt laboratoriemiljø. Men ingen av oss arbeider egentlig under slike forhold. Og svært få av oss har finansieringen som kreves for å anvende alle disse ende-til-ende-prosessene på den perfekte måten.

Mye handler derfor om iterativ utvikling. Ikke bare iterativ utvikling i programvareforstand, men også når det gjelder prosesser og samarbeid. Alt dette handler om å arbeide frem og tilbake hele tiden.

Michael Luchen

Interessant. Det du sier, er altså at mye av dokumentasjonen og opplæringen innen produktledelse handler om å være iterativ i produktutviklingen. Men du sier også at man må være iterativ når det gjelder prosessen og menneskene, basert på miljøet man arbeider i.

Sam Higham

Ja, akkurat. Jeg tror mye av dette glemmer at vi mennesker er ganske rotete skapninger.

Vi er ikke perfekte individer som kan følge alt til punkt og prikke. Vi har heller ikke den samme kunnskapen. Når du som produktperson kommer inn uten å undersøke først, slik jeg selv har gjort, kan du komme inn i en rolle og si: «Greit, nå skal vi praktisere produktledelse, og dette er rammeverket vi skal bruke. Alt kommer til å fungere perfekt.»

Men du har kanskje ikke engang vurdert om kollegene dine forstår hva dere forsøker å oppnå. Forstår de hva eller hvorfor denne tilnærmingen kan være verdifull? Hvor langt unna er dere fra å snakke det samme språket? Hvis du ikke begynner med å spørre hva som er den beste måten for dere å gjøre dette på sammen, går du glipp av noe viktig.

Ha den åpne samtalen først. Deretter kan du ta med deg egne erfaringer og teknikker som har fungert tidligere, og prøve å anvende dem. Men ikke forvent at de automatisk vil fungere. Noen ganger kan man bli blendet av at «det fungerer hos Google» eller «det fungerer hos Amazon», uten å spørre om det fungerer hos dere.

Michael Luchen

Ja. Det som er fascinerende, er at jo mer jeg lærer om hvordan Google eller Amazon faktisk fungerer internt, desto tydeligere blir det at mange av historiene vi forteller oss selv, stammer fra de tidlige dagene da de var oppstartsselskaper og forbilde for hvordan man skulle arbeide.

Nå er de enorme virksomheter med mange forskjellige team og mange ulike arbeidsmåter, også internt.

Sam Higham

Ja, absolutt. Mange snakker om de beste erfaringene de hadde på oppstartsnivå. Jeg tror det er fordi alle befinner seg i et miljø der de forstår hva de forsøker å gjøre, og der alle prøver å finne ut av det sammen. Dere har et felles språk og kan raskt ha åpne samtaler om hva dere kan gjøre.

Jeg mener ikke bare produktutviklerne, designerne og ingeniørene. Jeg snakker også om salg, markedsføring, drift og alle andre. Alle befinner seg i det samme rommet, og organisasjonen får en tett tilbakemeldingssløyfe.

Utfordringen, og grunnen til at prosesser og rammeverk kommer inn, er at man mister dette når organisasjonen blir større. Man får interne måter å snakke om ting på som faktisk gjør det vanskeligere for andre funksjoner å samarbeide effektivt, fordi ens egen tilnærming ligger så langt foran det andre funksjoner forstår.

Hvis man ikke hele tiden forklarer hva man forsøker å gjøre og hvorfor man har valgt denne tilnærmingen, mister man noe. Plutselig samarbeider ikke salgsavdelingen ordentlig med produktfolkene, produktfolkene samarbeider ikke ordentlig med ingeniørene, og alle snakker om hvor fantastisk deres egen funksjon er – men ikke om hvor fantastisk organisasjonen kunne vært sammen.

Michael Luchen

Det høres ut som mye arbeid.

Sam Higham

Det er det. Og det er nettopp poenget.

Michael Luchen

Jeg tenker på lytterne våre, hvorav mange kanskje arbeider i noen av disse større organisasjonene som ikke helt er oppstartsselskaper. Hvordan veileder du mennesker i et miljø der de virkelig må være forkjempere for prosessen, men kanskje ikke føler at det finnes rom for det?

Sam Higham

Begynn i det små, slik man bør gjøre med alt. Mange av de gode grunnprinsippene fra Det smidige manifestet er fortsatt gyldige. Begynn i det små og tenk på hvilket minst mulig eksperiment dere kan gjennomføre som gruppe, innenfor det dere faktisk kontrollerer. Det handler også om å være komfortabel med hva som er innenfor din kontroll.

Noen ganger blir man frustrert når man prøver å endre for mye for raskt. Da kommer man aldri til å vinne den kampen. I stedet kan du arbeide med én utviklingsgruppe, forhåpentligvis en tverrfunksjonell gruppe, med designere, ingeniører og produktfolk, og spørre hvilke eksperimenter dere kan gjennomføre sammen for å bli mer effektive.

Deretter kan dere ta med enda en funksjon inn i samarbeidet. Vis hvordan tilnærmingen fungerer, men forstå også at den kanskje ikke fungerer. Dere må forstå hvorfor den ikke fungerte, og så begynne å ha disse samtalene.

Det krever mye innsats, og jo lenger unna dere er den beste måten å gjøre ting på, desto mer tid tar det å komme dit. Men det betyr ikke at dere ikke bør begynne. Det beste tidspunktet å begynne på er i dag.

Michael Luchen

Jeg liker fokuset på å begynne i det små. Noe jeg også har sett fungere, særlig når jeg arbeider med kunder som utvikler egne produkter, er å snevre det inn til et to ukers eksperiment.

Da selger man ikke en arbeidsmåte for det neste året, men planter frøene til noe større. Man selger selve to ukers eksperimentet: Stol på oss, la oss prøve, se hvordan det fungerer. Da kan man bevise verdien og deretter introdusere andre ting.

Jeg er også nysgjerrig på noe vi ofte snakker om som produktfolk: det å ta på seg en veiledende rolle. Finnes det et veiledningsansvar som påvirker suksessen i det daglige arbeidet?

Sam Higham

Ja, absolutt. For meg handler veiledning om å stille flere spørsmål enn man gir svar. På et overordnet nivå handler det mer om hvordan vi finner svar sammen, og det gjør vi vanligvis ved å stille bedre spørsmål.

Enten jeg arbeider med enkeltpersoner i et team eller i en konkret veiledningssamtale, handler det om å spørre: «Hva har du vurdert her? Hvorfor vurderer du disse tingene? Har du vurdert andre alternativer? Hvorfor har du i så fall valgt dette? Har du tenkt på hvordan du kan involvere andre i prosessen?»

Målet er å hjelpe dem med å utvikle vanen med å stille spørsmålene selv og stille dem til andre. Fra et veiledningsperspektiv må du også bli komfortabel med å være mer suksessens skygge enn å stå i rampelyset. Du må være glad på andres vegne når de lykkes fordi du har hjulpet dem fra sidelinjen, uten å fremheve at du var en del av prosessen.

Hvis man sier at «Sam stod i bakgrunnen og veiledet denne personen eller dette teamet», tar man noe fra deres egen utvikling. Det bør heller være slik at teamet selv har overvunnet problemet og oppnådd forbedringen. Om nødvendig bør man tone ned sin egen involvering fullstendig.

Michael Luchen

Det var godt sagt. Det går også den andre veien: Man må la folk mislykkes gjennom veiledningen, slik at de kan lære på egen hånd og bli selvstendige neste gang.

Sam Higham

Ja, absolutt. Noen ganger er vi redde for å mislykkes. I organisasjoner kan det finnes en usynlig kultur der feil blir ropt ut altfor tydelig.

Tenk på en liten feil i et program. Plutselig går det e-poster rundt, og en mektig leder spør når det skal bli fikset og sier at det er en katastrofe. Det man ikke innser, er at konsekvensen blir at folk blir redde for alle feil og alle mindre endringer.

De blir mindre villige til å ta risiko og prøve noe nytt. Det samme gjelder for eksempel designgjennomganger. Det finnes gode metoder for å vise frem design tidlig og åpent, slik at folk kan samarbeide. Men hvis kritikken blir overdrevet eller rettet mot designernes evner, kommer de til å vise frem arbeidet sjeldnere eller senere. Da mister man læringen som oppstår gjennom å prøve, feile og utvikle riktig tankesett.

Som leder må du være svært bevisst på dette og hjelpe andre med å unngå slike mønstre. Disse usynlige signalene kan være skadelige for å skape det positive tankesettet der folk våger å prøve og ser på erfaringene som læringsmuligheter, ikke bare som feil.

Michael Luchen

Det er lederne som skaper strukturene som gjør det trygt for folk å feile og lære av feilene, i stedet for å skape frykt for å feile. Det er kanskje noe av det vanskeligste, for som leder tenker man jo: «Jeg vil ikke at organisasjonen min skal mislykkes.»

Hva er verdien for organisasjonens resultater ved å la produktfolk finne veien til resultatene gjennom prøving og feiling?

Sam Higham

Forhåpentligvis vil resultatene bli synlige. Du kan se team som er komfortable, trygge og myndiggjorte, og som er proaktive når de sier: «Dette eksperimentet ga ikke et klart eller riktig svar, men nå vet vi at vi kan gjøre dette andre.»

Det handler også om tempo. Når folk snakker om tempo, mener de ofte poeng. Det er ikke det jeg mener. Jeg mener menneskers evne til å arbeide komfortabelt, trygt og raskt fordi de ikke er redde for å måtte innhente et ekstra godkjenningsnivå eller dobbeltsjekke at alle har signert før de gjennomfører et lite eksperiment.

Det motsatte er å ha en samtale med teamene om hvilket handlingsrom de skal ha, når dere bør snakke sammen før dere går videre, og hvilke beslutninger du fortsatt må ta ansvar for. Det handler om risiko.

Hvis noen vil gjøre en omfattende endring i hele databasen og det er stor risiko for at det går galt, bør kanskje ikke produktteamet ta avgjørelsen uten deg. Men hvis de vil gjennomføre et A/B-eksperiment på en knapp for ti prosent av brukerbasen, og det verste som kan skje er at konverteringen faller med 0,01 prosent, bør teamet sannsynligvis bare gjøre det. Den iterative forbedringen veier langt tyngre enn den potensielle negative effekten.

Michael Luchen

Så det er nesten en arbeidsavtale mellom produktteamet og lederne.

Sam Higham

Ja. Det finnes også rom for veiledningssamtaler dersom handlingsrommet var for stort eller for lite. Da kan man snakke om hva som bør gjøres neste gang. Det trenger ikke være mer komplisert enn det.

Michael Luchen

Når vi snakker om alt dette, blir det tydelig hvor komplisert, rotete og tvetydig produktarbeid er. Det finnes ikke én prosess eller ett rammeverk som passer for alle.

For en produktleder som begynner med dette, kan spørsmålet bli: Hvor begynner jeg? Skal jeg starte med prosessen, teamet eller lederne? Hva er kompasset mitt?

Sam Higham

Jeg kan dele min egen reise. Det fungerer kanskje for andre, kanskje ikke. Personlig lærer jeg ting i siste ansvarlige øyeblikk. Da jeg begynte å arbeide med produkter, lærte jeg bokstavelig talt det jeg måtte gjøre, akkurat da jeg måtte gjøre det.

Første gang jeg skulle holde en presentasjon, lærte jeg hvordan jeg kunne gjøre det. Første gang jeg skulle lage et veikart, undersøkte jeg hvilke muligheter som fantes og hvorfor én kunne være bedre enn en annen. Neste gang spurte jeg hva jeg hadde lært fra første gang. Slik lærte jeg å prioritere en produktkø.

Grunnen til at jeg lærte på denne måten, er at jeg lett blir overveldet av å ta inn informasjon og deretter glemme alt. Det er fristende å lese 20 bøker om produktledelse og anta at man kommer til å huske all informasjonen akkurat når man trenger den.

Hvis du klarer det, er det flott. Men det klarer ikke jeg. Jeg må øve på noe, lære om det og finne ut om det fungerer for meg. Slik arbeider jeg fortsatt. Hvis jeg skal prøve noe nytt, lærer jeg om det på det tidspunktet jeg skal bruke det.

Det betyr ikke at det er noe galt med kurs. Det kan være nyttig å ha grunnleggende kunnskap. Men man må ikke tro at kurset gir den nøyaktige oppskriften på hvordan alt kommer til å utspille seg. Komplekse mennesker, komplekse problemer og alle de ytre og indre faktorene gjør at selv enkelt arbeid kan bli vanskelig.

Michael Luchen

Det er flott. Jeg kjenner igjen dette fra min egen reise og har sett andre produktledere lykkes ved å hoppe inn og lære gjennom å gjøre. Det finnes så mye i faget vårt. Når man skal lage et veikart, kan det være best å søke etter informasjon og prøve seg frem med verktøyene man har, for å se hva som fungerer for teamet.

Sam Higham

Ja. Det finnes ingen riktig måte å lage et veikart på. Noen måter kan være litt bedre, men de passer kanskje ikke for konteksten din. Det er lett å si at man bør lage et veikart med «nå», «neste» og «senere», uten datoer eller funksjoner, bare resultater. Men jeg vil ikke være ansvarlig for at du blir kjeftet på av en leder fordi de aldri har sett et slikt veikart før.

Du må gjøre endringer gradvis mellom det ideelle du ønsker å oppnå og det som fungerer for deg akkurat nå. Deretter må du finne ut hvordan du bygger bro mellom de to.

Michael Luchen

Mye av det vi snakker om, handler om å holde blikket på det lange løpet. Ikke bare det lange løpet for resultatene eller måltallene, men også utviklingen av teamet vi samarbeider med. Hvordan bør en produktleder ha dette i tankene hver dag?

Sam Higham

En måte er gjennom tilbakeblikk. Det er sunnere for teamet å vurdere seg selv enn å forholde seg til tilfeldige tall fra et system for oppgavehåndtering eller vurderinger fra andre.

Jeg har også gjennomført tilbakeblikk eller verksteder for teamhelse, der teamet blir enige om ti ting det vil fokusere på. Hvert kvartal kan man vurdere om man har blitt bedre eller dårligere på et område, og hva man skal gjøre for å endre det.

Et vanlig tilbakeblikk handler mer om her og nå: Hva forsøker vi å oppnå med dette arbeidet? Teamhelse er bredere, nesten som et stort tilbakeblikk over mer generelle temaer. Teamet kan selv bli enige om hva som skal inngå i vurderingen.

Det handler også om myke ferdigheter. Som produktperson må du legge merke til endringer i hvordan teamet oppfører seg. Kanskje du plutselig får langt mindre respons når dere diskuterer hvordan dere kan oppnå den kortsiktige produktvisjonen eller løse et problem. Da må du spørre hva som har endret seg, og snakke med menneskene det gjelder.

Ikke sitt på avstand og analyser. Gå og ha samtalene. Kanskje noen har fått hard tilbakemelding, eller noe har gått galt. Vi er mennesker, og vi er avhengige av kommunikasjon, samarbeid og fellesskap. Jeg ser på et produktteam som et lite fellesskap som vokser på tvers av organisasjonen.

Michael Luchen

Et produktteam er et lite fellesskap. Det er virkelig fint sagt. Hele denne samtalen har vært så fokusert på mennesker. Hva gjør man hvis man foreslår øvelser for teamhelse og tilbakeblikk, men ledelsen spør hva verdien er og mener at det er bortkastet tid?

Sam Higham

Igjen handler det om å gjøre dette åpent. Forklar hvorfor dere prøver å gjøre det, og hvilke tegn som vil vise om eksperimentet er vellykket.

Når det gjelder teamhelse, kan det være nyttig å snakke om hvorvidt folk blir værende, eller la dem vurdere egen trivsel. Det finnes mange verktøy som gjør dette ukentlig. Man kan også se på hvordan teamet fungerer og hvor utfordringene ligger.

Hvis arbeidet stadig stopper opp fordi dere ikke får kontakt med riktig avdeling i tide, kan hypotesen være at dere skal samarbeide mer aktivt med den avdelingen tidlig. Inviter dem inn i planleggingen og til ukentlige demonstrasjoner. Da håper dere å unngå overraskelser i siste liten fordi avdelingen ikke ble involvert.

Åpen kommunikasjon er sunt. Du kan også spørre ledergruppen hva de ønsker å se, og hvordan de ønsker at dere skal måle dette. Det kan gå galt dersom de bare vil se at tempoet og antallet poeng øker hele tiden, men forhåpentligvis kan dere ha en tillitsfull samtale.

Det ligner på å veilede oppover. Still spørsmål for å forstå hva de ønsker, eller hva de frykter skal skje hvis dere gjør dette. Da kan dere redusere bekymringen for at dere skal sløse bort tid.

Michael Luchen

Det er interessant. Ved å spørre «hvorfor?» kan man oppdage en grunnleggende misforståelse av hva verdien av å følge med på poeng faktisk er. Man får muligheten til å ha en dialog. Hvis de fortsatt vil at tallene skal øke etter at de har forstått dette, er det på tide å løpe for livet.

Produktledere har ofte bred og generell kunnskap om mange prosesser og verktøy, men vi kan ikke anta at interessentene våre har den samme kunnskapen.

Sam Higham

Ja. Forståelse og språk er ofte en stor del av problemet. Det gjelder også uttrykk som «produktledet». Hvis folk ikke forstår at det betyr at alle arbeider sammen for å utvikle et fantastisk produkt som i større grad selger seg selv, kan de tro at produktfunksjonen skal bli den mektigste og avgjøre alt.

Da begynner folk å forskanse seg, bli redde og kjempe om alt. Språk er svært mektig. Når folk misforstår begreper og du ikke forklarer hva de betyr, trekker de egne konklusjoner.

Jeg prøver derfor å være mer bevisst på terminologien jeg bruker. Forstår alle den? Hvis ikke, hvordan kan jeg forenkle eller forklare det som faktisk er viktig? Folk er ofte motvillige til å si fra når de ikke forstår. Bare de mest selvsikre spør kanskje hva «produktledet» betyr. Resten sitter stille og antar at de forstår.

Michael Luchen

Vi må nesten innta rollen som en tålmodig veileder for alle.

Sam Higham

Ja.

Michael Luchen

Jeg har ett siste spørsmål før vi avslutter. Du har en prestisjefylt rolle, en flott karriere og veileder og kurser folk ved siden av. Du har derfor inngående kjennskap til bransjen vår. Hvor ser du produktledelse gå for at man skal lykkes? Hvordan vil produktledelse se ut de neste tre årene?

Sam Higham

Jeg tror produktledelse kommer til å deles mer opp i spesialiseringer. Faget begynte svært bredt og betyr forskjellige ting for forskjellige mennesker. Etter hvert vil det trolig oppstå mer spesifikke typer produktledere.

Det kan ligne på programvareutvikling, med spesialiseringer og underkategorier. Det kan være vekst, B2B eller B2C. Mange av begrepene brukes allerede, men vi har ikke helt knyttet dem til hva som fungerer best for en produktleder innen vekst, B2B, B2C, markedsplasser eller andre produkttyper.

Mye av opplæringen og innholdet som kommer nå, går i denne retningen. Jeg forventer at spesialiseringene etter hvert blir formelle disipliner. Produktmiljøet er blitt så stort at dette kommer til å skje naturlig.

Michael Luchen

Fantastisk. Før vi avslutter, vil jeg stille noen personlige spørsmål i hurtigrunden, hvis det er greit.

Sam Higham

Ja.

Michael Luchen

Hvilken personlig vane har bidratt mest til suksessen din?

Sam Higham

Jeg vil si motstandskraft. Mye av det vi har snakket om i dag, handler om feil. Ikke alle aksepterer feil like lett, og man kan få det vanskelig hvis ting går galt og miljøet ikke er trygt. Tilpasningsevne er nok en annen. Slik lærer jeg: ved å tilpasse meg informasjonen jeg har. Og ydmykhet. Jeg sier åpent at jeg ikke vet halvparten av det jeg trenger å vite. Jeg er avhengig av mange andre som er langt dyktigere enn meg på sine områder. Jeg prøver aldri å late som om jeg er eksperten som vet alt, for det gjør jeg ikke.

Michael Luchen

Jeg liker alle disse egenskapene og kjenner igjen verdien av dem. Hva er favorittverktøyet du bruker regelmessig?

Sam Higham

Miro – eller Myra? Jeg vet ikke hvordan det uttales. Det er det mest fleksible verktøyet, og jeg ville vært fortapt uten det.

Jeg bruker det hele dagen, hver dag, til alt. I det forrige selskapet jeg arbeidet i, brukte vi det til å lansere en virksomhet verdt én milliard dollar på seks måneder. Det er et imponerende verktøy, og jeg bruker det også til alt innholdet mitt.

Michael Luchen

Jeg er helt enig. Teamet mitt og jeg tok det i bruk da det fortsatt het RealTime Board, og det ble raskt det mest brukte verktøyet i selskapets historie.

Til slutt: Hvilket råd har du gitt til noen som begynner på sin produktreise?

Sam Higham

Be om hjelp. Det finnes en antakelse om at produktfolk bør vite alt fordi de ofte befinner seg i skjæringspunktet mellom alt. Derfor kan man vegre seg for å be om hjelp når man ikke vet noe, enten det gjelder andre produktfolk, en dyktig ingeniør, en designer eller noen andre i organisasjonen.

Noen av de beste produktlederne jeg kjenner, er de som alltid aktivt ber om hjelp, fordi de vet at det gjør dem bedre. Det finnes også et voksende fellesskap på Twitter for produktfolk. De fleste er der fordi de ønsker å hjelpe andre med å lære.

Så mitt viktigste råd er: Be om hjelp. Egentlig gjelder det ikke bare produktfolk, men alle.

Michael Luchen

Det er et fantastisk råd, og jeg er helt enig. Selv om du tror du vet, bør du be om hjelp. En annen vurdering kan i seg selv være verdifull.

Sam, tusen takk for at du ble med i programmet i dag.

Sam Higham

Takk for invitasjonen.

Michael Luchen

Du kan finne mer informasjon om Sams arbeid på Twitter eller LinkedIn. Takk igjen, Sam, for at du ble med. Takk til alle som lyttet, og husk å legge igjen en anmeldelse av podkasten. Følg oss også gjerne og bli med i fellesskapet vårt på theproductmanager.com hvis du ikke allerede er medlem.

Takk igjen til alle som lyttet, så høres vi i neste episode. Ta vare på dere selv!