Slik tar du i bruk et gründerperspektiv i en etablert virksomhet (med Brendan Fortune)

Les transkripsjonen:

Vi prøver ut transkribering av podkastene våre ved hjelp av et program. Tilgi eventuelle skrivefeil, ettersom roboten ikke er korrekt 100 % av tiden.

Hannah Clark: Et ærlig spørsmål: Hvilken jobb tror du er vanskeligst – å være gründer i en oppstartsbedrift eller å være den første produktlederen i gründerens oppstartsbedrift? Jeg tror man kan argumentere for begge deler, avhengig av tidligere erfaring. Selv om spørsmålet kanskje er litt subjektivt, tror jeg vi kan være enige om at begge rollene er sterkt investert i et produkts suksess. Men her er utfordringen: En produktleders suksess er også knyttet til evnen til å opparbeide og beholde ledelsens tillit. Og hvis du vil at en gründer skal stole på deg, må du kanskje begynne å tenke som en gründer.

Dagens gjest er Brendan Fortune, stabssjef i Customer.io. Gjennom karrieren har Brendan sett på nært hold hvordan et gründerperspektiv kan være en stor fordel for produktledere, særlig i en null-til-én-kontekst. Om litt får du høre ham dele gode innsikter om å håndtere spenninger i stedet for å løse problemer, å feile raskt (samt noen av favorittfeilene hans) og det mest følelsesladde øyeblikket på null-til-én-reisen. La oss sette i gang.

Velkommen tilbake til podkasten The CPO Club.

Brendan, takk for at du er her med oss i dag. Hvordan har du det?

Brendan Fortune: Jeg har det kjempebra. Takk for at du inviterte meg, Hannah.

Hannah Clark: Kan du fortelle litt om bakgrunnen din og hvordan du endte opp der du er i Customer.io?

Brendan Fortune: Jeg synes alltid det er fascinerende å høre folks historier, fordi de vanligvis stopper ved overgangen til produkt. Så jeg skal prøve å fortelle hele min.

Jeg begynte med IT-support da jeg gikk på college i Los Angeles. Etter eksamen hadde jeg rett og slett flaks. Jeg ble headhuntet av en rekrutterer jeg aldri hadde møtt, for å slite meg ut i en oppstartsbedrift med 150 ansatte innen tale over IP. Veldig teknisk. Så jeg jobbet med teknisk brukerstøtte der. Om kvelden skrev jeg filmmusikk, fordi jeg fortsatt hadde den store Hollywood-drømmen.

Etter hvert innså jeg at filmmusikk var sunnere for meg som hobby enn som jobb. Så jeg sluttet med det. Jeg begynte på et MBA-program der man jobber ved siden av studiene, og for alle som ikke har hørt om slike, hadde ikke jeg heller det. Det er omtrent som deltidsstudier. Du har en fulltidsjobb og går samtidig på skole, og det tar tre år.

Det var der jeg lærte om produktledelse – denne kombinasjonen av tekniske ferdigheter, kreativitet og lederskap som var veldig spennende. Jeg brukte derfor MBA-en som et springbrett til å få en stilling som juniorproduktleder i selskapet der jeg allerede hadde jobbet i fire år med teknisk brukerstøtte, og så gikk jeg over til IT.

Det var krevende. Det var vanskelig. De ville ikke gi meg stillingen med det første. Sannsynligvis hadde de rett, men heldigvis gjorde jeg jobben likevel. Noen måneder senere fikk jeg stillingen. Derfra forlot jeg selskapet som produktdirektør. Jeg jobbet en periode hos GoDaddy i hostingavdelingen deres.

Deretter jobbet jeg i Drip, en SaaS-plattform for markedsføringsautomatisering. Nå er jeg i Customer.io. Jeg begynte innen produkt, og som stabssjef er jobben min nå å skape de organisatoriske systemene som hjelper lederne for utvikling, produkt og design med å gjøre sitt beste arbeid. Hva det enn måtte innebære. Det er så mange forskjellige ting, så.

Hannah Clark: I dag skal vi fokusere på gründerperspektivet og hvordan det ser ut innenfor rammene av en etablert virksomhet. Det er en helt annen situasjon enn i en oppstartsbedrift.

La oss først ramme inn temaet litt. Hvordan ville du definert et gründerperspektiv hvis du skulle oppsummere det, og hvordan ser det ut i praksis for deg?

Brendan Fortune: Dette synes jeg er et veldig morsomt spørsmål, fordi det for meg noen ganger kan være litt truende å høre uttrykket «gründerperspektiv». Jeg tenker: Jeg har aldri grunnlagt mitt eget selskap. Betyr det at jeg ikke kan ha et gründerperspektiv? Er det noe galt med meg?

Hvorfor har jeg ikke gjort det hvis jeg prøver å bygge produkter? Men etter at jeg har jobbet med fire gründere gjennom årene, har jeg begynt å se helt annerledes på det. For meg betyr et gründerperspektiv en tilbøyelighet til å skape noe selv, fremfor å følge andres oppskrift. Det kan være et nytt produkt du skaper, eller en ny filosofi.

Det kan være en ny tilnærming til ledelse. Det kan egentlig være hva som helst. Men den definerende atferden er hva instinktet ditt er når du møter en utfordring: Er det å skape deg ut av den? Eller er det å lete etter svar utenfor deg selv? Jeg mener at gründerperspektivet handler om å skape seg ut av problemet. Det betyr ikke at du ignorerer alt andre har sagt og bare lager noe selv, men at du i utgangspunktet er skeptisk til andre materialer og ideer som finnes, med mindre du virkelig forstår dem grundig.

Det er det gründerperspektiv betyr for meg, og jeg kan komme på noen eksempler på hvordan det kan brukes. La meg tenke på et produktrelatert eksempel, siden dette er en podkast for produktledere. Da jeg ble ansatt i GoDaddy, sa ledergruppen til meg: «Vi trenger at du bygger et nettskyhostingsprodukt for oss.»

Dette var relativt tidlig i Amazon Web Services’ historie. Jeg tror Google nettopp hadde kommet inn i markedet. GoDaddy tenkte: «Hei, dette har vi kanskje en sjanse til å lykkes med.» Så de sa at det var dette jeg skulle gjøre. Tre måneder senere kom jeg tilbake og sa: «Nei, dette er ikke den riktige ideen for virksomheten.»

I stedet burde vi utvikle en virksomhet for administrerte tjenester oppå Amazon Web Services, noe som var en ganske kontroversiell plan på den tiden. Jeg husker at jeg snakket med noen kolleger og ledere der, og det var en følelse av: «Vent litt, det er jo ikke dette du skal gjøre. Hva er de politiske konsekvensene av dette?»

Jeg tror gründerperspektivet her handler om å si så tydelig som mulig hva du faktisk tror på, i stedet for hva du tror kan være riktig, eller hva noen andre mener er riktig, hvis du ikke forstår det fullt ut. Dette gjelder også på et par andre måter. En av favorittene mine, nettopp fordi den er så nerdete, er et eksempel fra driftsarbeidet da jeg var stabssjef. I Customer.io har vi en prosess der de kundevendte teamene våre, som teknisk brukerstøtte, kundesuksess eller salg, må stille spørsmål eller eskalere problemer til avdelingen for utvikling, produkt og design. Det kan være feil eller hva som helst.

I lang tid hadde vi en prosess der et menneske opprettet en sak, en utviklingsleder gikk gjennom sakene og bestemte hvilket team den skulle legges på. Det var en svært tidkrevende prosess. Noen ganger ble sakene liggende der i en time, andre ganger en dag, avhengig av hvor travelt folk hadde det.

Beslutningen ble fremstilt som et valg mellom at ett menneske gjør det – en utviklingsleder må sortere dette – eller at et annet menneske gjør det, for eksempel en medarbeider i teknisk brukerstøtte, som må bestemme hvilket team saken hører til. Det måtte gjennomgås manuelt. Jeg tror et annet eksempel på gründerperspektiv er å ta i bruk ny teknologi.

I dette tilfellet brukte vi en svært enkel Zapier-bot med en stor språkmodell og kunstig intelligens. Den tok innholdet i saken som allerede var opprettet, analyserte det, sammenlignet mønsteret med ett av flere funksjonsområder som tilhørte ulike team, og tildelte det automatisk. Nesten alle sakene våre blir prioritert umiddelbart på denne måten, mens det tidligere tok lang tid.

Det er enda et eksempel på at hvis du blir presentert for et falskt enten-eller, som at noe må fungere på denne eller den måten, finnes det sannsynligvis en annen måte det kan fungere på. Og det er noe av det jeg mener gründerperspektivet hjelper oss med å få frem.

Hannah Clark: Ja, jeg antar at det handler om å være ressurssterk og spørre hvordan man kan oppnå mer med mindre, eller være kreativ i løsningene. Jeg tror virkelig på ideen om at kreativitet næres av begrensninger. Så det ligner på den typen tankesett.

La oss zoome litt inn og snakke om gründerperspektivet slik det gjelder null-til-én-prosjekter innen produkt. Hva ser du som den største utfordringen en produktleder møter når han eller hun prøver å bygge et helt nytt produkt?

Brendan Fortune: Jeg elsker dette spørsmålet. Jeg skal snu litt på det. Jeg tror en av de største utfordringene en produktleder møter i dette tilfellet, faktisk er å overvinne gründerperspektivet. Det er kanskje kontraintuitivt, for når du skaper noe nytt, må du selvfølgelig tenke kreativt, slik gründerperspektivet innebærer.

Men jeg tror det finnes en fare i gründerperspektivet som kommer fra følelsen av: «Jeg skapte det, så jeg eier det virkelig.» Et spørsmål jeg ville stilt, er om du noen gang har hørt noen omtale et prosjekt som «babyen sin». Hvis du har det, er det en grunn til at folk gjør det, fordi eierskapet kan føles så nært – som om det er et barn. Noen sier det på spøk, men i min erfaring er det ikke egentlig morsomt i enkelte av disse tilfellene.

Jeg tenker omtrent slik: Hvis du går inn i et null-til-én-prosjekt og prøver å finne ut hvordan du kan bruke gründerperspektivet samtidig som du faktisk bygger et produkt med et team – som er den eneste måten jeg vet hvordan man gjør det på – vil du gjøre alt du kan for å dele foreldreansvaret. Jeg vet ikke om analogien kan strekkes så langt, men vi vil være medforeldre, eller hva man nå skal kalle det. Det handler virkelig om å lene seg inn i det. Det krever en hel landsby. Og derfor tror jeg dette er en av hovedutfordringene. Det er veldig lett å bli sugd inn i tanken om at «jeg må ha ideene, jeg må eie dette, jeg må ta alle beslutningene».

Det fører til slutt til flere feil, tror jeg, enn om man går inn i det sammen med et team. Den sentrale utfordringen er altså å gå alene. Men når du legger ut på denne farlige null-til-én-reisen, må du få de riktige personene med på laget fra begynnelsen.

Det er en formulering jeg låner fra boken Good to Great av James Collins, som jeg fortsatt liker godt. Den begynner å bli gammel nå, men den inneholder mye klokskap. Poenget er at du ikke trenger å vite nøyaktig hvor du skal, eller nøyaktig hva du bygger, før du kan vite hvem du trenger med deg på reisen. Det er nok en av disse kontraintuitive tingene, eller det var det i alle fall for meg.

Trenger du ikke å kunne si: «Hei, bli med på dette. Jeg trenger at du gjør dette arbeidet»? Er ikke det det ansvarlige å gjøre? Men i denne boken, og i ideen om å få de riktige personene med på laget, handler det om å kjenne styrkene og svakhetene dine og finne personer hvis styrker i størst mulig grad kompenserer for svakhetene dine.

Det handler om at brikkene i puslespillet passer godt sammen. Og jeg tror det er slik man kan overvinne noe av gründerperspektivet eller eierskapsbiasen – følelsen av at «dette er babyen min».

Hannah Clark: Hvis vi skal videreføre foreldreanalogien litt: Du vil finne en partner. Hvis du er forelder, vil du finne en partner som deler noen av de samme verdiene, men som også motvirker noen av svakhetene dine og utfyller styrkene dine godt. Så ja, jeg synes faktisk det er en veldig god analogi.

Jeg vil gjerne gå litt dypere inn i ideen om å få de riktige personene med på laget. Det er lett å lage en abstrakt idé om hvordan vi kan bruke dette i praksis. Men i din erfaring, hvordan vurderer du hvem som bør være med? Hvordan vurderer du styrkene og svakhetene deres?

Brendan Fortune: Kanskje vi kan begynne med noen enkle eksempler. La oss si at dette er et ganske vanlig mønster: Du er et teknisk geni eller en teknisk produktleder, men når det gjelder historiefortelling og karismaen som virkelig hjelper deg med å lede et team, har du ikke det. Det er et svært vanlig mønster.

Da er det sannsynligvis noe du bør finne. Dette gjelder særlig når du bygger et nytt produkt i en etablert virksomhet. Evangeliseringsarbeidet gjelder ikke bare kundene du prøver å overbevise om å kjøpe produktet. Du må også evangelisere overfor alle menneskene, særlig ledelsen, i selve selskapet, fordi du bruker mennesker, energi og penger på dette arbeidet. Du må virkelig ha den evnen. Hvis du vet at det ikke er en ferdighet du har, er det et eksempel på noe du må lete etter og prøve å få med på laget.

Et par andre eksempler: Dette har skjedd med meg. Hvis du bygger et produkt eller får i oppgave å bygge et produkt du ikke kan så mye om, fordi du ikke forstår området, markedet eller kundene ennå, bør du finne noen som gjør det. Eller du bør spørre deg selv om dette er et godt produkt for deg å lede og skape fra null til én. En av de største risikoene er å ha noen i en lederposisjon som ikke egentlig forstår området, som ikke har levd og åndet det. Det tar lang tid å leve og ånde et område. Jeg har tidligere gjort feilen å tro at jeg kunne lære det raskt, og mislyktes.

Hannah Clark: Ja, og jeg kan bare forestille meg hvor avhengig man må være av brukernes innspill og tilbakemeldinger, og all læringen man må gjøre for å komme opp på et grunnleggende forståelsesnivå før man kan begynne å forstå produktet. Jeg ser for meg at dette kan være en svært stor utfordring for mange som er i den situasjonen.

Jeg vil snakke litt om å feile raskt. Dette er noe jeg synes nesten har blitt et slagord – ideen om å feile raskt. Mange teamkulturer omfavner ideen i teorien, men vi formulerer sjelden tydelig hva det faktisk betyr. Hvor mye tid og innsats ønsker vi for eksempel egentlig å gi en idé før vi kan si at dette er en fiasko?

Hvordan definerer vi i det hele tatt fiasko? Og hva gir vi individuelle bidragsytere tillatelse til å si? Har de psykologisk trygghet til å si at de ikke tror noe fungerer? Hvilke måter foreslår du for å ta i bruk en kultur der man feiler raskt, og hvordan kan man håndtere dette praktisk i et team?

Brendan Fortune: Jeg elsker dette spørsmålet, og jeg kjenner meg igjen når du rammer det inn slik: Folk sier dette, men samsvarer det faktisk med det de praktiserer eller virkelig tror på? Jeg tror det finnes verdi i konseptet om å feile raskt, men innrammingen har vanligvis vært misvisende, i alle fall i min erfaring.

Det er lett å tro at «feil raskt» betyr at jeg kan feile så mye jeg vil. Eller kanskje det motsatte: Feil raskt, men det finnes ingen reell forventning om at det er greit. I det øyeblikket du feiler, skjer det umiddelbart en endring. Jeg tenker på et av Amazons lederprinsipper: ledere har ofte rett. Broren min jobbet i Amazon en periode, og jeg husker at jeg snakket med ham om dette. Han sa: «Det lederprinsippet er bare tull. Du skal jo myndiggjøre teamet ditt. Ledere skal ikke ta beslutningene.»

Det er en litt annen samtale, men jeg tror ideen om å feile raskt ofte egentlig betyr at du har rett ofte. Du feiler noen ganger, men i realiteten lykkes du raskt gjennom feilene for å komme dit. Det bringer oss til et annet tema du nevnte: Hvordan definerer du suksess, og hvordan definerer du fiasko? Det er et klassisk spørsmål fra smarte mennesker å stille midt i et møte der noen presenterer et prosjekt: «Ja, dette høres flott ut. Men hva er suksessmålene deres?»

Det er et godt spørsmål. Det er et spørsmål som får deg til å tenke. Det bør finnes noen suksessmål i tankene. Men noen ganger ligger det en antakelse om at du må kunne definere suksessmålene før du tar noen steg, og at målene skal forbli uendret. Det blir et binært valg: Dette er enten en suksess eller en fiasko.

Kanskje det har fungert et sted, men for alle produktene jeg har bygget fra null til én, har det aldri fungert slik. Jeg har et interessant eksempel friskt i minnet fra Customer.io, der jeg jobber nå. Det nyeste produktet vi har jobbet med, heter Customer.io Data Pipelines.

Det er en plattform for kundedata. For de som ikke har hørt om det, er det et sentralt integrasjonspunkt for alle dataene i et selskap. Du sender inn alle kundedataene dine – hva heter kunden, hvilken atferd har kunden i produktet – og samler alt på ett sted. Deretter er det enkelt å sende dataene til alle stedene du måtte ønske, for eksempel et CRM-system som Close eller Salesforce, eller et system for markedsføringsautomatisering som Customer.io eller Drip.

Da vi begynte å jobbe med prosjektet for omtrent halvannet år siden, var suksessmålene våre at vi skulle vinne kunder fra konkurrenter innen kundedataplattformer ved å tilby et billigere produkt. Vi satset altså på at kundedataplattformer skulle bli mer standardiserte og begynne et kappløp mot lavere priser.

Vi ønsket også å generere tosifrede månedlige, tilbakevendende inntekter fra nye kunder som bare brukte dette produktet. Vi hadde våre etablerte produkter for markedsføringsautomatisering, og nå la vi til et nytt produkt. Vi tenkte at vi skulle gjøre det så bra at kundene bare betalte oss for det nye produktet uten å bruke det andre.

Vi sa også til økonomidirektøren at vi skulle tjene nok penger til å betale for teamet vi hadde bedt om for å bygge produktet. For å sette teamet på spill: Seks måneder etter lanseringen, hvor mange av disse suksessmålene tror du vi hadde nådd?

Hannah Clark: Jeg ville enten gjettet null eller ett.

Brendan Fortune: Ja. Null. Kanskje jeg ledet deg litt i den retningen, men null er helt riktig. Vi legger likevel ikke ned prosjektet. Så spørsmålet er: Hvorfor ikke? Er det en form for tapsaversjon? Har vi investert så mye at vi bare fortsetter? Kanskje vi bare trenger mer tid? Nei, det er ikke grunnen. Det er fordi vi ikke oppnådde suksess etter disse målene, men fant suksess etter andre mål på uventede områder.

Vi fant ut at kundene som aldri hadde brukt en kundedataplattform før, var de som lyktes best med å ta produktet i bruk. Vi så også begynnelsen på et nytt økonomisk svinghjul. Vi hadde priset produktet på samme måte som de fleste kundedataplattformer, basert på API-kall. Det er en variabel prismodell.

Jo mer data du sender inn, desto mer verdi får du ideelt sett ut av produktet. Og dermed tar vi mer betalt. Vi har sett at kundene som tar produktet i bruk, øker bruken måned for måned. Det er igjen viktig for Customer.ios økonomiske svinghjul. Vi vant altså ikke kunder fra konkurrentene ved å ha lavere pris.

Vi oppdaget at de fleste som allerede brukte konkurrenter, sa: «Ja, det er greit, men jeg kan få rabatt.» Det var ikke så viktig. Vi hadde i praksis null fremdrift der. Vi vokste mye saktere. Vi jaktet på inntekter, men burde egentlig ha jaktet på dette økonomiske vekstsvinghjulet, som til slutt vil bli til inntekter.

Vi kan se utviklingen, men det bygges sakte. Det skjer ikke raskt. Det er derfor produktet har fortsatt. Hvis du jobber med noe fra null til én, bør du tenke nøye gjennom suksessmålene dine, men forvente at de utvikler seg, og at du noen ganger finner suksess andre steder. Så lenge du finner suksess et eller annet sted, bør prosjektet fortsette. Hvis du virkelig ikke finner suksess noe sted, har du nådd punktet der det har mislyktes.

Hannah Clark: Det var veldig innsiktsfullt. Jeg tror mange av oss kan kjenne oss igjen i det på flere områder i livet. Forventningene våre blir ikke nødvendigvis virkelighet slik vi så for oss, men det betyr ikke at det ikke finnes annen verdi, eller andre milepæler som kan føre til ytterligere fordeler senere. Veldig interessant.

Siden vi snakker om fiaskoer, vil jeg sette deg litt på prøve. Hvis vi zoomer ut fra Customer.io, hva er favorittfiaskoen din i karrieren – den du mener har ført til størst verdi i livet ditt?

Brendan Fortune: Det er et veldig interessant spørsmål. Jeg får nesten lyst til å si at jeg har så mange, men så tenker jeg: Vent, jeg sa nettopp at ledere ofte har rett. Det bør jeg kanskje ikke si. Men det stemmer. Jeg har mange favorittfeil eller favorittfiaskoer.

Den første jeg kommer på, var hos GoDaddy. Det var et nytt produkt vi prøvde å bygge, som het Enterprise WordPress. Det var et hostingprodukt som skulle hjelpe byråer – virkelig store byråer, den typen som bygger nettsidene til ABC.com og lignende.

Vi prøvde å lage et produkt som kunne håndtere mengden trafikk de ønsket, samtidig som det beholdt fleksibiliteten til WordPress, som var mer tilgjengelig for mindre tekniske personer. Det fantes noen eksisterende produkter i markedet som hadde lykkes, og vi tenkte at vi hadde forstått det.

Vi hadde gode relasjoner til kundene. Vi hadde pilotkunder hos noen av disse byråene. Alle relasjonene var på plass. Så jobbet vi med det i omtrent ni måneder til ett år, med et team på fem eller seks personer, hovedsakelig utviklere. Vi la ned prosjektet omtrent én eller to måneder etter lanseringen.

Grunnen var at vi hadde bygget noe som bokstavelig talt var dødt ved ankomst. Du kunne ikke på en ryddig måte flytte fra et testmiljø til produksjon. Vi trodde vi var veldig smarte: Vi skulle gjøre løsningen supersikker ved å sørge for at du ikke kunne endre noe i produksjon, men måtte gjennom en bestemt prosess. Vi trodde vi var teknisk geniale. Og det var vi kanskje. Men kundene hadde egentlig ingen interesse av dette, og vi hadde ikke validert ideen annet enn ved å fortelle dem hva vi tenkte og få noen nikk som sa «ja, ja, det går vel bra». Det var akkurat som mammatesten.

Vi gikk rett i mammatest-fellen. Det jeg lærte, var at hvis du tror du er smart, må du sørge for at du faktisk er smart. Og hvis ingen i teamet har mye domenekompetanse, selv om du har noen kunder som samarbeider med deg, må du være på vakt. Vi hadde ingen på teamet, heller ikke jeg, som visste særlig mye om Enterprise WordPress før vi begynte å jobbe med det.

Hannah Clark: For de som ikke kjenner mammatesten, kan du gi en kort oppsummering av hvordan den fungerer? Det er nesten blitt en morsom klisjé.

Brendan Fortune: Jeg ville oppsummert den slik: Hvis du spør noen «Hei, synes du dette er bra?» og personen bryr seg om deg eller ønsker at du skal lykkes, som en typisk mor eller forelder, får du sannsynligvis svaret du ønsker. Du får ikke den ærlige eller kritiske tilbakemeldingen du trenger for å vite om det du bygger faktisk er noe de vil betale for.

Det er stor forskjell på «ja, kult, jeg støtter dette» og «jeg vil betale penger for det». Det er mammatesten.

Hannah Clark: Jeg synes det er så morsomt. Man ser dette hele tiden, særlig fordi det også er kulturelt. I noen kulturer skjer det mindre, men i Nord-Amerika er mange sosialisert til å si «ja, ja, det høres bra ut», og så bygger du noe for dem som de egentlig ikke bryr seg om.

Brendan Fortune: Ja, nettopp. Dette blir kanskje en litt stor avsporing, men det får meg til å tenke på samtalen om radikal åpenhet. Det er et annet rammeverk fra Kim Scott, med ødeleggende empati på den ene siden og støtende aggressivitet på den andre. Det er et interessant tema i seg selv. Når du snakker om kulturen, særlig i Nord-Amerika, der man gjerne vil være støttende og ikke gi direkte kritikk, er det det jeg tenker på. Vi må få til radikal åpenhet, og det er helt motkulturelt.

Hannah Clark: Jeg synes faktisk den avsporingen er helt grei, for jeg tror radikal åpenhet er noe vi er sterkt kulturelt opplært til å unngå. Men særlig i et produktteam kan jeg bare forestille meg hvor mange tusen, sannsynligvis millioner, som har blitt kastet bort fordi folk ikke har praktisert radikal åpenhet.

Brendan Fortune: Å ja. Milliarder. Jeg tror det er sånn i alle selskapene jeg har jobbet i. Jeg kan ikke si at jeg noen gang har jobbet i et selskap som virkelig fikk dette til. En del av grunnen er at kultur først og fremst er noe som må håndteres, ikke et problem som skal løses. Det forsvinner aldri. Du kommer aldri til et punkt der du sier: «Ja, nå har vi fått radikal åpenhet, og nå kommer alt til å fungere.»

Det er rotete, og det er ikke profesjonelt. Det finnes en spenning mellom rot og dybde. Når jeg prøver å bygge tillit til noen og går inn i den første tilbakemeldingssamtalen med en kollega eller en ny leder, forteller jeg ofte noe om mine egne karriereambisjoner. Det er sårbart å snakke om. Jeg kan si at jeg er interessert i en bestemt jobb, men ikke vet om jeg ser en vei dit.

Å åpne seg om noe er risikabelt og kan noen ganger fremstå som politisk kalkulert, som er det motsatte av det du ønsker når du prøver å etablere tillit. Du trenger tillit for å kunne være radikalt åpen, i stedet for bare å si hva du mener og anta at du har rett og at den andre må høre på deg. Det er også giftig, bare på en annen måte. Jeg synes derfor dette er veldig rotete. Jeg har jobbet for personer som ønsker å dempe slike ting.

De ser at noen snakker om noe og tenker: «Jeg er ikke sikker på om dette er risikabelt, eller om de bør dele det.» Eller, enda vanligere: «De krangler.» De vet kanskje at de er ideologisk uenige om noe. «Feil raskt» kan være ett eksempel. Én person mener at vi må iterere og feile raskt, mens en annen mener at vi må skalere, drive virksomheten og ha en fast rytme.

Når du ser mennesker gå løs på hverandre på den måten, er det lett å si som leder: «Stopp konflikten, demp dette.» Men da har du drept det. Den radikale åpenheten er borte. Du tror du hjelper, men radikal åpenhet innebærer konflikt. Vi tenker på å løse konflikter, ikke på å oppmuntre til sunn konflikt. Konflikt innebærer risiko, men også belønning.

Hannah Clark: Ja. Konflikt er egentlig en mulighet. Vi har faktisk en hel artikkel om det, så dere kan sjekke den ut.

Men la oss gå videre. Jeg vil gjerne vende tilbake til noe du nevnte, nemlig spenninger som må håndteres. Dette er et annet rammeverk: spenninger som skal håndteres, i motsetning til problemer som skal løses. Jeg vil gjerne snakke litt om det, fordi jeg synes det er en interessant idé. Det kalles ikke alltid det samme i en ledelseskontekst, men det er et viktig konsept å forstå fordi det gjelder så mange områder innen personalledelse.

Kan du forklare dette konseptet?

Brendan Fortune: Jeg kan kanskje se på det gjennom en produktlederlinse og bruke mine egne erfaringer. Da jeg begynte innen produktledelse, ble jeg belønnet for å lansere ting. Dette er problemer du løser for kundene ved å lansere ting. Når du lanserer, oppstår det en følelse av at noe er ferdig.

Det finnes selvfølgelig fortsatt skalering og drift, men du når dette lanseringsøyeblikket. Vi jobber med saker, brukerhistorier og lignende. Brukerhistorier blir løst. Du ser en sekvens av fremdrift. Når du går inn i en bredere rolle, som personalleder, er det lett å ta med seg samme tankesett: «Jeg skal identifisere problemene, lansere løsninger på dem, og så forsvinner de.»

Løsningen kan for eksempel være hvordan jeg gjennomfører et møte med produktlederteamet mitt. Jeg lager en agenda, ber om bestemte ting, og da er problemet løst.

Virkeligheten er at mennesker hele tiden endrer seg. Selv om teamet ditt består av de samme personene, endrer spenningen seg kontinuerlig. Problemene endrer seg. Det skjer alltid en form for forskyvning. I tillegg skal du utvikle menneskene dine. Du vil at de skal endre seg, og når de gjør det, må du lede dem annerledes.

Løsningene du tidligere har satt sammen og sett lovende resultater av, fungerer ikke lenger. Det har vært nyttig for meg å se på dette som spenninger som skal håndteres, og å anta at det øyeblikket jeg har løst noe, er det uløst igjen. Jeg prøver å holde meg i et skapende tankesett så mye som mulig. Det kan være utmattende, men vi kan knytte det tilbake til gründerperspektivet.

Hvis du liker å skape, er dette perfekt. Å håndtere spenninger passer rett inn i gründerperspektivet. Det er slik jeg tenker på å bygge samstemthet og på personalledelse. Vær klar til å tilpasse deg og prøve å skape. Det finnes ingen oppskrift du kan bruke som fritar deg fra å håndtere spenninger.

Hannah Clark: Jeg liker virkelig den ideen, fordi den også forbereder deg som personalleder på å ikke forvente en løsning. Det er et tankesett som gjør det lettere å håndtere energien din når du skal håndtere disse spenningene.

På samme tema håpet jeg at vi kunne gå litt dypere inn i ideen om samstemthet. Du nevnte det tidligere. Alle har på en måte en forskjellig idé om hva samstemthet betyr i et team, men det er avgjørende. Som vi har snakket om, er det svært viktig å få samstemthet riktig. Hvilke råd har du for å få et team samstemt rundt en viktig leveranse, som et helt nytt produkt?

Brendan Fortune: Jeg har tenkt mye på dette det siste året i forbindelse med Data Pipelines. Det er et par ting jeg har funnet ut at fungerer veldig godt, men som jeg begynte med for sent. Det første er individuell tilbakemelding. Jeg mener ikke nødvendigvis kritisk tilbakemelding til én bestemt person. La meg gi et eksempel.

Si at jeg setter sammen et veikart. Dette er hvordan vi skal håndtere året fra null til én. Jeg har kanskje et visjonskart, noen skisser eller noe lignende. Det er fristende å prøve å være effektiv og samle mange mennesker i et rom. Jeg presenterer visjonen, gjennomfører en spørsmålsrunde, og får mange spørsmål. Folk virker engasjerte og interesserte. Flott, da har vi samstemthet.

Men denne typen samstemthet i grupper fungerer ikke. Selv med fem eller seks personer, altså en liten gruppe, har jeg opplevd at det ikke fungerer. En måned eller to senere oppdager du kanskje at én person i møtet ikke hadde noen anelse om hva du snakket om, ikke brydde seg, ikke fikk mulighet til å delta og ikke følte seg hørt.

Hvis du ikke føler deg hørt, kan du ikke være uenig og forplikte deg, fordi du ikke har blitt hørt. Du har ikke engang fått uttrykke uenighet. Derfor bør du først presentere ideen individuelt når du har en presentasjon som normalt skulle deles i gruppe. Hent inn tilbakemeldinger fra de riktige interessentene én og én, og sørg for at du kan gjenta tilbake til dem: «Dette er det jeg hører deg si om dette. Dette er det som er uklart.»

Gå gjennom det. Noen ganger bruker jeg et digitalt tavleverktøy siden vi jobber eksternt. Jeg legger ut lapper med det folk sier, slik at de visuelt kan se at du fanger opp det de sier og lytter til dem.

Ikke invester for lite i dette, særlig ikke med kjerneteamet ditt. Det er vanskeligere med ledergruppen, men når det gjelder menneskene som bygger produktet, må du sette av tid én til én. Du må gjøre det flere ganger. Ett møte på 30 minutter er ikke nok. Du trenger mer enn det.

Det andre handler om samstemthet i ledelsen. Det finnes et konsept jeg skulle ønske jeg husket hvor jeg fant. Det var ikke mitt; jeg leste det et sted. Det er ideen om et læringsveikart. Ledere er etter min erfaring ofte interessert i fremdrift. De vil se hva du lanserer, hvor verdien er, hvor pengene går og hvilken avkastning de får.

Når du jobber fra null til én, finnes det en lang periode der du ikke har penger å vise til for det du bygger. Ledere vet det konseptuelt, men hvis de aldri har bygget et produkt selv, og egentlig selv om de har gjort det, kan de være motivert til å presse på: Går dette raskt nok? Kommer dette til å fungere? Kommer jeg til å fremstå dum? Kommer jeg til å bli flau over det dere lager? Den grunnleggende følelsen er svært problematisk og ødeleggende for samstemthet.

Et læringsveikart er et verktøy som lar deg vise fremdrift uten å vise penger ennå. I stedet for bare å si at vi skal lansere denne funksjonen innen en bestemt dato, sier du også: «Dette er spørsmålene vi skal besvare denne uken.»

For eksempel: Bør dette være et frittstående produkt, eller bør det integreres med det eksisterende produktet vårt? Det kan være et spørsmål på læringsveikartet. Du har kanskje kundesamtaler, markedsanalyser og mange andre signaler. Så skriver du ned svaret: «Dette er svaret på spørsmålet. Her er dokumentasjonen.» Det er dette du leverer. Du leverer svaret og læringen, og kan gå videre.

Prising er for eksempel et morsomt tema når man har flere produkter. Bør vi bruke en variabel prismodell eller en fast modell? Det vet jeg ikke, men det er en læring du kan jobbe deg gjennom, en beslutning du må ta.

Hvor mange kunder vil signere en kontrakt og betale for det vi bygger? Det går tilbake til mammatesten. Det motsatte av mammatesten er: Kan jeg få deg til å signere et dokument som forplikter deg til å betale for dette? Selv om jeg ikke har bygget det ennå, kan jeg selge deg visjonen? Det kan være et annet spørsmål.

Hvis du tenker på antakelsene du utfordrer og spørsmålene du må stille for å bygge fra null til én, og legger dem inn i et læringsveikart, kan du vise fremdrift i læringen i tillegg til funksjonene. Det er en god måte å skape samstemthet på ledernivå. Lederne kan følge med, se at noe beveger seg og komme med innspill. Det er en annen måte å skape samstemthet på.

Du vil engasjere dem og trekke dem inn i den felles løsningen.

Hannah Clark: Et utmerket råd for å håndtere den spenningen du nevnte.

Før vi avslutter, vil jeg bruke litt tid på noe du nevnte: Null til én ligner mye på at dette er babyen din, men alle babyer må vokse opp. Hvordan ser det ut?

Hvis vi tar et skritt tilbake fra et produkt du har tatt fra null til én, hvorfor er det så vanskelig å gjennomføre overgangen? Og for å ta det enda litt lenger: Hvordan kan man håndtere endringen når man føler et så sterkt eierskap eller foreldreskap over prosjektet?

Brendan Fortune: Det første er noe vi allerede har snakket om. Den beste måten å gjøre dette på er å ikke la produktet bli babyen din i utgangspunktet. Det er vanskelig, men hvis du klarer det, er det ideelt. Hvis du ikke klarer det, noe som er veldig lett, særlig fordi du må tro mer på null-til-én-produktet enn noen andre, blir det krevende.

Du er evangelisten. Du heller noe av sjelen din inn i det. Når du gjør det, blir det en del av identiteten din. Det er vanskelig å unngå. Men jeg tror jeg ville anbefalt å definere et sluttpunkt og ta kontroll over overleveringen, slik at det ikke føles som noe som skjer med deg.

Det er noe du selv får til å skje. Du kan finne riktig tidspunkt. For produktet jeg sist lanserte, Data Pipelines, var det noen måneder etter generell tilgjengelighet, da virksomheten fikk et annet behov for en stabssjef som jeg gikk inn i. Vi tenkte at dette var et godt tidspunkt til å ansette noen andre.

Jeg hadde en idé om hvem vi trengte til rollen. Jeg kunne ansette personen, få vedkommende om bord og så videre. Hvis du kan velge tidspunktet selv, tror jeg det følelsesmessig kan bli litt enklere.

Det finnes også et sitat fra Yoda. Jeg vet ikke hvem som faktisk skrev det. Det var i en av de nyere Star Wars-filmene. Jeg skal ikke gjøre Yoda-stemme, for jeg er forferdelig dårlig til det. Men det går omtrent slik: Gi videre det du har lært – styrke og mestring, ja, alt det gode – men også svakhet og fiasko. Så sier han at vi er det de vokser forbi. Det er den sanne byrden til alle mestere.

Det er kanskje rart å tenke på seg selv som en mester for produktet, men konseptet er det samme: Jeg utviklet dette, jeg eier dette, men virkelig suksess oppstår når noen andre kan gjøre jobben bedre enn deg.

Jeg tror dette også gjelder personalledelse, men i et null-til-én-prosjekt tror jeg det blir lettere å glede seg over overleveringen hvis du klarer å tro på det.

Hannah Clark: Det var veldig vakkert. Jeg må tilgi deg for at du ikke gjorde Yoda-stemmen.

Dette har vært en utrolig interessant samtale, Brendan. Jeg setter stor pris på at du kom, og på alle de fantastiske innsiktene.

Hvor kan folk følge deg eller ta kontakt på nettet?

Brendan Fortune: Jeg tar gjerne kontakt på LinkedIn. Hvis noen har spørsmål, eller særlig hvis noen har prøvd disse tingene uten at de har fungert, vil jeg gjerne høre om det. Jeg finnes også på Twitter. Jeg er @mnproductmgr, eller product MGR – det er kanskje litt forvirrende. Jeg bor i Minnesota, så det er der MN kommer fra.

Hannah Clark: En undervurdert delstat. Det har vi snakket om.

Greit, tusen takk, Brendan. Håper vi snakkes igjen snart.

Brendan Fortune: Greit. Takk, Hannah.

Hannah Clark: Takk for at du lyttet. Hvis du vil ha 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å The CPO Club, uansett hvor du hører på podkaster.