Tar mangel på klarhet stille livet av produktet ditt?

Les transkripsjonen:

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

Hannah Clark: Det er praktisk talt en klisjé, men det skjer hele tiden – du sier noe til tre personer, og de hører tre forskjellige ting. Og det er ikke så ille hvis det du sier er: «Jeg skal hente kaffe, er det noen som vil ha noe?» Men når du bygger en MVP med stadig kortere økonomisk handlingsrom, eller prøver å lansere noe innen en streng tidsfrist, kan denne mangelen på klarhet bli dødsstøtet for en oppstartsbedrift.

Dagens gjest er Bijan Shahrokhi – han er grunnleggeren av Product Management Exercises og Product Monkey AI. Bijan har brukt den siste delen av karrieren på å hjelpe produktledere med å bli mer produktive og flinkere til å lede team. Evnen til å skape klarhet og samkjøring i et produktteam er grunnleggende for disse ferdighetene. Om noen minutter vil Bijan dele en prosess som er enkel å gjenta, og som vil koste deg litt tid i starten, men som kan redde en oppstartsbedrift på randen av kollaps. La oss sette i gang.

Velkommen tilbake, lyttere. I dag har jeg med meg Bijan Shahrokhi. Han er grunnleggeren av ProductManagementExercises.com, og han har nylig lansert et produktivitetsverktøy spesielt for produktledere, kalt ProductMonkey.ai.

Bijan, tusen takk for at du blir med oss i dag.

Bijan Shahrokhi: Tusen takk for at jeg fikk komme.

Hannah Clark: Flott. Vi begynner alltid på samme måte. Jeg vil gjerne at du forteller litt om bakgrunnen din, og hvordan du endte opp der du er i dag.

Bijan Shahrokhi: Klart det. Jeg er produktleder innerst inne. Jeg har vært produktleder i over ti år, helt tilfeldig.

Jeg visste ikke engang hva produktledelse var før jeg hadde en oppstartsbedrift som ikke gikk særlig bra. Jeg spurte en venn hva han mente jeg burde gjøre videre, og han sa: «Du burde bli produktleder.» Jeg tenkte: Vent litt. Det høres veldig interessant ut, som produkt og å lede produktet. Det er det jeg vil gjøre.

Derfra ble jeg produktleder. Jeg har gjort flere forskjellige ting de siste ti årene. De første par årene jobbet jeg i større organisasjoner, blant annet i en bank som produktleder og deretter som produktstrateg. Etter det var jeg en del av to oppstartsbedrifter. I begge lanserte vi produktet da jeg begynte i selskapet, og den ene ble kjøpt opp etter halvannet år av en større aktør i økosystemet.

Den andre var faktisk et vellykket prosjekt. På det meste var det verdt flere milliarder dollar. Det pågår fortsatt og er fortsatt i kraftig vekst. Siden den gang har jeg hovedsakelig fokusert på Product Management Exercises de siste årene av karrieren min. Nylig lanserte vi også et nytt produkt for produktledelsesmiljøet, kalt ProductMonkey.ai.

Hannah Clark: Fantastisk. I dag skal vi snakke om klarhet i organisasjoner, noe du personlig er svært opptatt av. Med klarhet mener jeg ganske enkelt å sørge for at alle interessentene er samkjørte og deler den samme forståelsen av hva som skjer og hva som skal bygges.

Hvordan ser det ut for deg når en organisasjon mangler en følelse av klarhet?

Bijan Shahrokhi: Godt spørsmål. Jeg tror det største og mest åpenbare tegnet på at en organisasjon mangler klarhet, er når du går rundt i organisasjonen og spør ulike personer hva de mener er suksesskriteriene for det som skal leveres som den neste store milepælen, og du begynner å høre forskjellige historier.

La meg gi et eksempel. Si at du jobber med et svært teknisk produkt som skal håndtere mange ytelsesmålinger, som for eksempel forsinkelse, hastighet, antall transaksjoner per sekund eller mengden oppgaver som kan fullføres. Hvis dette ikke er tydelig definert av en teknisk person i organisasjonen, kan vedkommende prøve å bygge noe som tåler et ekstremt høyt antall transaksjoner.

Men hvis du spør noen som er mer forretningsorientert og kundeorientert, vil de kanskje si at vi bare trenger å få noe ut døren slik at vi kan begynne å få tilbakemeldinger fra kundene våre. Du vet at det mangler klarhet når du begynner å snakke med personer på tvers av organisasjonen og hører forskjellige tall, eller de sier: «Å, det har vi aldri tenkt på» eller «Det har vi aldri diskutert». Det er vanligvis et ganske tydelig varsel for deg som produktleder om at du må innse: Vent litt, det virker som om det mangler klarhet her.

Hannah Clark: Det høres ut som du har noen førstehåndserfaringer med dette. Uten å nevne navn, kan du komme på en anekdote?

Bijan Shahrokhi: Ja, absolutt. Det siste prosjektet jeg fortalte om, som ble verdt flere milliarder dollar, var et selskap som bare var noen måneder unna å gå tom for penger, og de hadde ennå ikke lansert et prosjekt.

De trodde at de bare var noen måneder unna å lansere produktet. Da jeg begynte, fikk jeg først beskjed om at det bare var tre måneder igjen. Etter at jeg begynte, innså jeg at det grunnleggerne, eller noen av grunnleggerne, hadde i hodet, kanskje lå fem til ti år unna virkeligheten.

Det noen av ingeniørene mente de leverte, lå også noen måneder frem i tid. Det var altså et enormt gap mellom de to. På grunn av dette havnet de i en utviklingssyklus som varte i over tre år, fordi ingeniørteamet stadig presenterte noe som var nesten klart. Noen av grunnleggerne eller forretningsfolkene så på det og sa: «Vent litt, dere er ikke klare.»

Dette samsvarer ikke med det vi ser for oss. De definerte på nytt hva som måtte bygges. Så gikk teamet tilbake til byggingen, skuffet og med en følelse av at de ikke skapte særlig mye verdi for organisasjonen. Det vi gjorde på det tidspunktet, var at jeg brukte de tre første månedene som produktsjef på å møte mange interessenter og virkelig forstå hvilke egenskaper som hadde svært ulike perspektiver på tvers av organisasjonen.

Jeg innså for eksempel at én bestemt egenskap, ifølge selskapet eller noen få personer i organisasjonen, måtte være en del av den første lanseringen. Den andre halvparten mente det motsatte. Vi begynte derfor å ha mange samtaler om disse konkrete punktene og fikk klarhet i om de skulle bygges eller ikke. Det var en ja-eller-nei-beslutning. Eller vi kunne beslutte at vi skulle lage en svært enkel versjon av funksjonen.

Og her er nøyaktig hva vi skal gjøre som en del av den. Først etter dette tok det oss omtrent ett år å faktisk bygge en enkel versjon av det som opprinnelig ble antatt å være det vi skulle lansere innen tre måneder. Helt ærlig brukte vi flere måneder bare på å få klarhet i hva som skulle bygges i løpet av ett år.

Forhåpentligvis er dette et eksempel på en situasjon der du faktisk kan få noe ut døren ved å skape mye klarhet. Når du først har lansert, kan du bruke tilbakemeldingene fra brukerne, fellesskapet og hele økosystemet til å finne ut hvilke av tingene i utviklingsplanen som bør prioriteres videre.

Hannah Clark: Ja, og det er også en enorm prestasjon å lukke et slikt gap. Det virker nesten umulig. Det er ganske kraftfullt å ta den tilnærmingen. Hvis vi zoomer litt ut, hvilke bredere konsekvenser mener du oppstår når en organisasjon ikke har bygget inn prosesser for klarhet i kulturen sin som helhet, og ikke bare i produktteamet?

Bijan Shahrokhi: Den største konsekvensen er at de vanligvis ender opp med ikke å lansere noe, og det er et stort problem. Mange gode prosjekter kommer aldri ut i verden fordi selskapene går tom for penger før de rekker å begynne å skape inntekter. Dessverre er dette en enda hardere realitet for forsknings- og utviklingsbaserte prosjekter. Slike prosjekter er ofte svært vitenskapsbaserte og prøver å levere et gjennombrudd, og de drives gjerne av grunnleggere med sterk akademisk bakgrunn.

Når personer med sterk akademisk bakgrunn leder en organisasjon, ser de etter perfeksjon. Fordi de ser etter perfeksjon, fortsetter de å bygge, bygge, bygge og legge til mer. De bekymrer seg hele tiden for ekstreme scenarioer som, for å være ærlig, ikke ville vært verdens undergang om de oppsto i inkubasjons- eller tidlige faser av et prosjekt.

Resultatet er at de aldri lanserer, og verden får aldri se visjonen de hadde for denne nye teknologien.

Hannah Clark: Ja, hele dette med «ferdig kontra perfekt» er noe vi alltid kjemper med. Det er perfeksjonisten mot dem som bare vil lansere, ikke sant? Et område der jeg mener klarhet er utrolig viktig, er nettopp utvikling av en MVP. Det er et område som er svært utsatt for feilgrep og misforståelser som kan bli ganske katastrofale til slutt.

Hvilke vanlige fallgruver bør team som bygger MVP-er være oppmerksomme på, og hvilke tiltak kan de bruke for å unngå dem?

Bijan Shahrokhi: Jeg tror den største feilen jeg har sett oppstartsbedrifter gjøre med begrepet MVP, er at de blander det sammen med å levere et ødelagt produkt som ikke engang kan brukes.

Jeg har sett dette mange ganger. Uten å nevne navn kan jeg gi et eksempel. Jeg er for eksempel investor i et bestemt bedriftsprodukt. Jeg er svært engasjert i og begeistret for det. Fra første dag var grunnen til at jeg ble begeistret, at jeg kunne se for meg selv bruke det.

Jeg kunne også se for meg at organisasjonen min, Product Management Exercises, ville bruke det daglig. Den største hindringen for å ta det i bruk har vært at det er så fullt av feil at vi ikke engang kan bruke det. Derfor er det svært viktig at vi som produktledere følger med på dette og sørger for at en MVP ikke er et feilfylt produkt som ikke klarer å formidle produktets verdiforslag.

Du må fortsatt sørge for at den sentrale brukeropplevelsen, eller den sentrale produktverdien du prøver å levere til brukeren, fungerer godt og smidig fra ende til annen. Du kan redusere omfanget av mange unødvendige ting, men du må sørge for at du kan levere den sentrale produktopplevelsen.

Jeg tror dette er en av de største feilene selskaper gjør: De misforstår hva MVP betyr og tror at det betyr at de kan lansere noe som er ødelagt.

Hannah Clark: Ja. Det finnes nesten en gruppe som ikke vil vente med å lansere til alt er perfekt, og så finnes det den andre ytterligheten. Det gir mening.

Du har en ganske omfattende prosess for å søke klarhet i organisasjoner, som du var inne på tidligere. Hvis lytterne ville kopiere og lime denne tilnærmingen inn i sin egen arbeidsflyt, hvilke trinn ville du anbefale for å sørge for at alle i teamet blir samkjørte?

Bijan Shahrokhi: Takk for at du spør. Det er interessant at du spør, fordi mange hos PM Exercises synes denne prosessen er svært nyttig. For å være ærlig er den ganske enkel, og den handler virkelig om å gjøre det krevende arbeidet tidlig, før du faktisk starter et prosjekt. Den er ganske trinnvis, så jeg skal raskt gå gjennom den.

I utgangspunktet bruker du mye tid i starten på å skape samkjøring på tvers av organisasjonen gjennom en trinnvis prosess. Først når du mener at alle er samkjørte, begynner du. Det interessante er at denne tilnærmingen faktisk er tatt i bruk i mange større organisasjoner, for eksempel finansinstitusjoner.

Da vi gikk fra fossefallsmetodikk til smidig og Scrum-metodikk, trodde vi imidlertid at det betydde at vi ikke trengte klarhet om hvor vi skulle, og at alt vi trengte å vite var hva vi skulle gjøre de neste to ukene. Det var ikke hensikten med smidig. Hensikten var å levere noe meningsfullt annenhver uke, samtidig som man visste tydelig hvor man prøvde å komme i løpet av noen måneder.

Hvordan gjør du det? Når jeg leder et prosjekt eller et produkt der jeg oppdager at det mangler mye klarhet, setter jeg opp individuelle møter med interessentene for produktet mitt. Det må være én til én, ikke i en gruppe. I et gruppemiljø kan én person dele en mening om et sensitivt tema, og noen andre hopper inn. Da klarer du, som produktets orakel, ikke å fordøye all konteksten på riktig måte.

Du må få hver enkelt person inn og sørge for at du virkelig forstår perspektivet deres. Si at du står overfor en avveining: Skal vi bygge X eller ikke bygge X? Det er en binær beslutning, men modellen fungerer også for mange andre ting.

Du møter dem, får perspektivet deres på hvorfor det bør eller ikke bør gjøres, og spør også hvilke ting du må være oppmerksom på når du tar beslutningen. De vil sannsynligvis gi deg fire eller fem ulike ting som er svært viktige for dem i deres verden.

Dette blir enda viktigere innen forskning og utvikling. Jo mer teknisk produktet ditt er, eller jo flere tekniske avhengigheter det har til andre verktøy i organisasjonen, desto viktigere blir det, fordi det finnes fageksperter. Du går til neste person, så neste person, og møter alle én til én.

Etter hvert som tiden går, vil enten din egen mening om hva avveiningen bør være, bli sterkere, eller du vil utvikle nye meninger. Avveiningene dine kan også endre seg, og du innser at enkelte ting du trodde var vanskeligere enn de egentlig er, eller enklere enn du trodde. Da justerer du dem.

Underveis går du tilbake til noen av personene etter hvert som du samler mer informasjon i individuelle samtaler. Du sier: «Da jeg først møtte deg, sa du at dette var de største bekymringene dine. Etter samtalene mine med andre mener jeg at de ikke bør være en bekymring. Her er argumentet. Fortell meg hvorfor jeg tar feil, eller si om jeg har rett.»

Når du går gjennom denne frem-og-tilbake-prosessen, som tar tid, innser du ofte at mange av utfordringene teamet sto overfor egentlig skyldtes manglende kommunikasjon. Ingen brukte tid på å tydelig formulere alle disse ulike avveiningene for de forskjellige interessentene i organisasjonen, og dermed ble mange ting løst.

Etter hvert får du mer og mer klarhet i alle avveiningene du må ta hensyn til. Denne tilnærmingen kan også brukes på produktprioriteringer. Vi kan gjerne snakke litt om det senere. På et tidspunkt innser du kanskje at noen få punkter fortsatt skaper ulike meninger. Halvparten av teamet mener for eksempel at en bestemt egenskap er svært viktig, la oss si sikkerhet. Den andre halvparten mener at sikkerhet ikke er en særlig viktig egenskap.

De har sine egne grunner. Det er da du organiserer et gruppemøte. Da sier du: «For at vi skal kunne ta denne beslutningen, er dette en egenskap som er svært relevant for oss. Det finnes to ulike perspektiver, og jeg ønsker at vi skal ha en samtale.» Gjennom den direkte samtalen klarer dere vanligvis å komme frem til en beslutning.

Noen ganger finnes det et par oppfølgingspunkter, som at dere må undersøke noe nærmere. Da kan du organisere neste møte og komme tilbake med: «Dette var det opprinnelige målet vårt. Vi gjorde undersøkelsen. Her er det nye funnet. Hva gjør vi?» Men dere kommer frem til en beslutning. Når du har full klarhet i alle avveiningene, blir det mye enklere for teamet å beslutte om dere skal gå i en bestemt retning, eller om det handler om produktprioriteringer.

Da kan dere si: «Nå har vi bestemt at dette er prioriteten vår, og vi skal fokusere på den.» På et overordnet nivå tenker jeg slik: Trinn én er å begynne med individuelle møter der du tydelig forstår hver persons perspektiv. Trinn to er å gå frem og tilbake mellom dem ved behov, slik at alle punkter der de har ulike meninger, blir håndtert. Hvis ikke, markerer du dem for gruppediskusjoner.

Trinn tre er gruppediskusjonene. Til slutt vil dette føre til enten en samlet produktstrategi, en produktspesifikasjon eller produktprioriteringer. For hvert av disse scenarioene kan det finnes et ekstra trinn. Når det gjelder produktprioriteringer, må du for eksempel tenke mer på hva målet er.

Kanskje du må bruke litt tid i begynnelsen på å si: «Målet vårt er å få noe raskt ut døren og lære.» Deretter vil du se om noen er uenige med deg. Hvis alle er enige, kan du gå videre i prosessen.

Hannah Clark: Jeg vil gjerne snakke litt mer om produktprioriteringer generelt. Selv når vi er relativt nær enighet, eller føler at vi har blitt enige om målene og hva suksess innebærer, kan det fortsatt være vanskelig å håndtere konkurrerende prioriteringer.

Det finnes selvfølgelig hundre forskjellige rammeverk for prioritering av produktfunksjoner, men hvilke metoder har du brukt og funnet mest vellykkede og bredt anvendelige når du arbeider med konkurrerende prioriteringer i slike sammenhenger?

Bijan Shahrokhi: Én av tilnærmingene er å gi dem poeng og vurdere dem fra et par forskjellige perspektiver.

Det ene er hvilken innvirkning jeg tror den aktuelle funksjonen eller produktet vil ha på målgruppen eller målbrukerne mine. Det andre er sannsynligheten for at vi faktisk klarer å realisere denne innvirkningen. I mange tilfeller er du ikke engang sikker på om det nye produktet faktisk vil treffe målgruppen.

I så fall er sannsynligheten lavere. Det tredje er hvor enkelt det er å gjennomføre. Formelen jeg har i hodet, er «innvirkning multiplisert med sannsynligheten for innvirkningen, pluss hvor enkelt det er å gjennomføre». For innvirkning bruker jeg en skala fra én til fem, der fem er størst innvirkning og én er minst.

For hvor enkelt det er å gjennomføre, betyr fem at det er enkelt å gjennomføre, mens én betyr at det krever mye arbeid. Deretter får du en poengsum. Det jeg liker med denne tilnærmingen, er at den er objektiv, og du kan ha lignende samtaler gjennom prosessen jeg nettopp beskrev.

Du kan gå tilbake til et teammedlem og si: «Etter samtalene mine med alle har jeg laget denne tabellen over de viktigste prosjektene i organisasjonen. Her er mitt syn på hvordan de scorer når det gjelder innvirkning og gjennomføringsarbeid. Basert på poengsettingen min er dette resultatet for hvilke prosjekter som bør prioriteres.»

Da kan de komme tilbake og si: «For det første mangler du disse tre prosjektene som vi også arbeider med.» Eller: «Dette ene prosjektet du har tatt med, bør deles opp i tre, fordi det er mye større enn du tror.» De kan også si at de er uenige i vurderingen din av innvirkning eller arbeidsmengde. Men nå har dere objektive samtaler som handler om konkrete punkter.

Det interessante med et slikt poengsystem er at du ikke prøver å anslå nøyaktig hvor lang tid alt vil ta. Du vurderer det relativt sammenlignet med andre prosjekter. Derfor er det mye enklere å raskt komme frem til en form for enighet om hvor mye verdi noe vil levere eller hvor mye arbeid det vil kreve.

Resultatet blir et sett med tydelig definerte prioriteringer, og du kan si: «Disse fem skal vi fokusere på i neste kvartal.» Hver gang et nytt punkt kommer inn, eller et nytt teammedlem eller noen andre i organisasjonen sier: «Dette bør vi gjøre», ser du på prioriteringstabellen og sier: «La oss se på det. Vi diskuterte det og bestemte at det ikke er en prioritet akkurat nå av denne grunnen. Når vi har fullført disse to eller tre, skal vi prioritere det.»

Noen ganger innser du at det finnes ytterligere ting som må legges til. Vi kan også snakke om hvordan du kan tenke gjennom slike scenarioer. Men jeg mener denne tilnærmingen er mer objektiv og gjør det enklere å komme frem til prioriteringer.

Hannah Clark: Jeg setter pris på det. Vi har tidligere snakket på Product Manager om å avpersonifisere tilbakemeldinger og slike prioriteringssamtaler, slik at folk ikke føler at det finnes en personlig grunn til at favorittprosjektet eller agendaen deres er blitt nedprioritert eller plassert i en annen rekkefølge enn de mener er riktig.

Det er en svært konkret metode, og jeg setter virkelig pris på den. Beklager, hva var det du sa at du ville komme tilbake til? Du sa at vi skulle snakke om det om litt, for bare et øyeblikk siden.

Bijan Shahrokhi: Jeg sa at vi også kunne snakke om hvordan folk noen ganger kommer inn og sier at noe må være en prioritet, og at du faktisk innser at det av en eller annen grunn må prioriteres.

Hvordan håndterer du det? Jeg sa at du noen ganger kan tenke gjennom hvordan du skal gjøre det. Det kan ikke bare legges til på prioriteringslisten. Du må enten tenke: «Hvis vi vil gjøre dette, må vi gjøre det på en måte som ikke påvirker leveringshastigheten til punktene som allerede har høy prioritet.»

Du har et par andre muligheter. Den ene er at du må fjerne noe fra listen. Det må nedprioriteres. Deretter erstattes det av det nye punktet gjennom poengsystemet. En annen mulighet er at du har ekstra ressurser som kan arbeide med det nye prioriterte punktet.

Prinsippet du følger, er at tingene på prioriteringslisten ikke skal bli forsinket bare fordi du legger til et nytt punkt. Etter min mening er dette produktlederens jobb. I noen organisasjoner er det ikke slik, og det er da du begynner å få problemer med at ting ikke blir levert.

En god produktleder følger nøye med på dette og sørger for at når ny informasjon dukker opp og noe annet må prioriteres, tenker vedkommende gjennom hvordan det skal håndteres. Enten fjerner jeg noe fra listen, eller så sørger jeg for å få ekstra ressurser som kan arbeide med det uten å påvirke leveringshastigheten for det andre punktet.

Hannah Clark: Fascinerende. Jeg ville skifte tema litt siden vi begynner å gå tom for tid. Jeg ville snakke litt om produktivitet, som er noe annet jeg vet at du er svært opptatt av, og sannsynligvis en viktig grunn til at du bestemte deg for å grunnlegge ProductMonkey.ai.

Jeg lurte på om du hadde noen generelle produktivitetsråd for publikum vårt, samt litt informasjon om Product Monkey AI som folk kanskje kunne ha nytte av. Det er et veldig interessant verktøy.

Bijan Shahrokhi: Det jeg gjør med Product Monkey AI, er å automatisere den ene oppgaven jeg mener er svært nødvendig for oss som produktledere, men som jeg ikke liker å gjøre. Det er å bruke mye tid på å skrive detaljerte krav og akseptansekriterier, av grunnene jeg nevnte tidligere.

Product Monkey AI prøver å hente inn så mye informasjon som mulig om prosjektet du arbeider med, organisasjonen din og den konkrete brukerflyten du jobber med.

Med riktig veiledning fra deg ved hjelp av kunstig intelligens kan vi gi deg detaljerte produktkrav, akseptansekriterier, testscenarioer og til og med hendelser og målinger du bør følge med på når du bygger produktet.

Da kan du ta det og begynne å arbeide med det, og få et raskt utkast som utgjør omtrent 80 % av arbeidet med oppgaver for ingeniørteamet og produktkravdokumenter, før de legges inn i hjem- og dokumentasjonssystemene. Deretter bruker du tiden på de siste 20 % for å ferdigstille dem.

Jeg tror en av fordelene vi kan levere som produktledere, som jeg nevnte, er å skape klarhet. Product Monkey AI kan faktisk gjøre dette ved å redusere tiden produktledere trenger for å skape klarhet for ingeniørteamene.

Hannah Clark: Det er fantastisk. Jeg er sikker på at mange av lytterne vil finne stor verdi i dette verktøyet. Bijan, tusen takk for at du ble med oss i dag. Hvor kan folk følge med på deg på nettet hvis de vil se hva du ellers holder på med?

Bijan Shahrokhi: De kan finne meg på Twitter, eller X som vi kaller det nå. X-brukernavnet mitt er bijan_sha. Du finner meg der. Du kan også besøke PM Exercises eller Product Management Exercises. Søk etter et av navnene, så finner du nettstedet vårt og kan komme i kontakt med meg der også.

Hannah Clark: Fantastisk. Tusen takk for tiden din.

Bijan Shahrokhi: Tusen takk for at jeg fikk komme.

Hannah Clark: Takk for at du lyttet. For flere gode perspektiver, 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 der du vanligvis hører på podkaster.