Slik korrigerer du kursen når veikartet stadig sporer av

Les transkripsjonen:

 

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

 

Hannah Clark: Produktveikart, akkurat som virkelige veikart, vil før eller siden møte forsinkelser. Noen kan du forutse og planlegge rundt, mens andre tilsynelatende oppstår helt plutselig, men som oftest kan du finne en omvei og komme tilbake på rett spor. Men hva om du legger merke til et bekymringsfullt mønster; målene blir ikke nådd, tidslinjene blir stadig trukket ut, og det virker som om hele veikartet hele tiden sporer av?

I dagens episode får du høre fra Michael Pierce, direktør for produktledelse i Public Consulting Group, som hevder at et veikart som stadig ligger etter, kan være et symptom på manglende samsvar mellom virksomhetsstrukturen og strukturen til produktteamet. Så hvis du sliter med å finne ut hvorfor målene og initiativene dine aldri ser ut til å utvikle seg slik du hadde planlagt, kan dette være kurskorrigeringen du trenger. La oss sette i gang.

Hei, lyttere. Velkommen tilbake til podkasten Produktleder. Jeg er her sammen med Michael Pierce. Han er direktør for produktledelse i Public Consulting Group. Michael, tusen takk for at du blir med oss i dag.

Michael Pierce: Ja. Takk, Hannah. Jeg ser frem til å være her.

Hannah Clark: Michael, kan du begynne med å fortelle litt om bakgrunnen din og hvordan du endte opp der du er nå?

Michael Pierce: Ja, absolutt. Jeg begynte med en grad i økonomi, slik mange produktfolk gjør, ikke sant? Vi har mange ulike bakgrunner. Jeg jobbet i et forsikringsmeglerfirma, og på den tiden ga en venn meg en kopi av The Lean Startup. Jeg begynte å lese den og tenke på de ulike prosessene på jobben som var ineffektive, litt ut fra et kanskje veldig umodent produktperspektiv.

Jeg endte faktisk opp med å lage et ganske avansert VBA-program, lærte meg litt Visual Basic-kode på egen hånd og begynte å automatisere ting. Det var på en måte starten på interessen min for produktledelse. På den tiden var det ikke på langt nær så utbredt som i dag, men det handlet om å snakke med brukerne, finne ut hva de trengte, forsøke å bygge en løsning og følge opp underveis i prosessen.

Kort tid etter dette startet jeg faktisk min første oppstartsbedrift. Den var innenfor vannaktiviteter. Vi jobbet med mange svømmebassenger, og byen Denver, her jeg kommer fra i Denver i Colorado, var en av kundene våre. Det var utrolig spennende for oss, men det var virkelig starten på produktreisen min.

Vi snakket med brukerne og laget et slags veikart, nesten i en nå, neste, senere-stil. Jeg var fortsatt veldig tidlig i produktreisen min, men det var en flott inngang til området. Flere år senere hadde jeg en såkalt acquihire-situasjon og begynte å jobbe i Enterprise i Boston. Det var en fantastisk erfaring. Kort tid etter endte jeg opp i mitt nåværende selskap, Public Consulting Group, som direktør for produktledelse.

Hannah Clark: Imponerende. I løpet av karrieren har du jobbet med flere team, noen ganger som en del av teamet, men ofte som leder for dem. Hvilke utfordringer har du funnet som på en måte er iboende i produktteam generelt?

Michael Pierce: Jeg tror en veldig stor utfordring som mange produktfolk ikke alltid kjenner igjen, er at du må se på selskapet du jobber i og forsøke å definere to hovedkategorier. Det ene er: Er selskapet salgsdrevet? Er det økonomidrevet eller markedsføringsdrevet? Vi har alle sett gode eksempler på dette.

Hvis du ser på HubSpot, er de definitivt et markedsføringsdrevet selskap. Ser du på et selskap som Zoom eller Slack, er de klassiske eksempler på svært sterk produktdrevet vekst og produktdrevet ledelse. Derfor er det svært viktig at produktteam ser på selskapet sitt og spør: «Møter denne topplederen ofte salgsavdelingen, og har de et svært tett forhold?»

Eller: Har noen av selskapets ledere bakgrunn fra drift, salg eller en annen funksjon? Det kan ofte gi en pekepinn på hvordan selskapet drives. Den andre viktige tingen produktteam bør gjøre for å se på eller forstå virksomhetskulturen, er å tenke på hvordan store beslutninger blir tatt.

Er det fullstendig ovenfra og ned? Er det kanskje toppledelsen som diskuterer saken med andre ledere og direktører? Er det svært demokratisk? Det er viktig å forstå strukturen for hvordan selskaper tar store beslutninger. Hvis du kjenner disse to tingene – om selskapet er salgs- eller økonomidrevet, og hvordan beslutningstakingen er strukturert – kan det virkelig hjelpe en produktavdeling med å forstå hvordan den passer inn i helheten, og hvordan dynamikken er satt opp slik at teamet kan navigere.

Hvis du ignorerer all denne informasjonen og bare går videre med hverdagen som produktavdeling, kan du fort finne deg selv omgitt av mange hindringer og utfordringer fordi du ikke posisjonerer deg på riktig måte for å påvirke andre i organisasjonen.

Hannah Clark: La oss kanskje ramme dette inn med en konkret historie. Hvilke eksempler finnes på at manglende samsvar mellom hvordan produktteamet ser seg selv og hvordan virksomheten faktisk fungerer, kan skape problemer senere?

Michael Pierce: Absolutt. Hvis jeg forstår spørsmålet riktig, vil ett eksempel være at det for tiden er mye energi rundt produktdrevet vekst. Jeg liker personlig produktdrevet vekst veldig godt, så jeg er litt forutinntatt, men hvis produktavdelingen arbeider på en måte som er svært tungt orientert mot produktdrevet vekst, mens selskapet i realiteten for eksempel er svært salgsdrevet, vil det føre til stor mangel på samsvar når det gjelder hvilke initiativer som får finansiering, og når det gjelder å få støtte på tvers av ulike avdelinger.

Det er derfor svært viktig å forstå hvilken plass du har som avdeling og funksjon i forhold til alle de andre funksjonene, slik at dere kan beregne bevegelsene deres som team.

Hannah Clark: La oss snakke litt om prioritering og utfordringene som følger med. Jeg tror dette er noe alle produktteam sliter med til en viss grad, uavhengig av hvilken vekstmodell dere har. Hvilke utfordringer har du sett når det gjelder prioritering i selskapene du har jobbet for?

Michael Pierce: Jeg kommer på to ting. En av de store tingene er at det ofte finnes et gap mellom idealtilstanden, eller ønskeliste-tenkningen rundt hva vi bygger, og virkeligheten.

En utfordring med prioritering er at når du forholder deg til styrer, børsnoterte selskaper og investorer, eller selskaper som er eid av oppkjøpsfond, kan det være stort press for å ha dette enorme veikartet fylt med alt det morsomme og spennende.

Utfordringen er å få alle tilbake til virkeligheten, men på en måte som gjør at de føler seg bra med det. Når du snakker om prioritering, handler det derfor om å etablere et felles utgangspunkt for de overordnede delene. Prioritering kommer først når du vet: «Dette er visjonen vår, og dette er nordstjernen vår.»

Du må ha disse overordnede elementene på plass for å kunne prioritere effektivt. Det er kanskje den andre fallgruven. Når du har samlet interessenter og ledere rundt «Dette er visjonen vår, dette er hvordan vi skal måle suksess, og dette er nordstjernen vår, KPI-ene våre og OKR-ene våre», blir det mye enklere å ha en sunn prioriteringsprosess og bevege seg bort fra den oppblåste ønskelisten mot noe som er langt tydeligere.

Det kan være mange punkter, men de er svært godt definert. Som organisasjon vet vi at disse fire store epikkene eller initiativene er tett knyttet til disse to OKR-ene, som vi vet at topplederen og organisasjonen virkelig bryr seg om. Det er i hvert fall slik jeg tenker på prioriteringsproblemet.

Hannah Clark: I en tidligere samtale fortalte du meg en historie om en analyse av et selskap. Vi skal ikke si hvilket selskap det var, men det var problemer med mål som ikke ble nådd, og du ble bedt om å finne årsaken. Kan du fortelle litt om dette og oppsummere historien?

Michael Pierce: Absolutt. Dette var et tilfelle der selskapet ikke nådde en stor del av punktene på veikartet, og de ville vite hvorfor. Det er et helt uskyldig og godt spørsmål. Som produktperson ser jeg på veikartet som et resultat av mange andre prosesser. Arbeidet som faktisk blir utført, er ofte resultatet av mange andre prosesser.

Det er resultatet av en stor boks med komplekse interaksjoner og innspill som går inn i boksen. Noe av det første jeg gjorde, var å skrelle bort lagene for å forstå: «Hvis vi ikke når 50 % av punktene på veikartet, hva er de grunnleggende årsakene?»

En av tingene jeg først undersøkte, var om vi rett og slett hadde for mange punkter på veikartet. Hvis du har et veikart som krever 2 000 timer, men bare har kapasitet til 1 000 utviklertimer, kommer du åpenbart til å gå glipp av halvparten av punktene. Men så langt jeg kunne se, var det nok ingeniører, kvalitetssikringsmedarbeidere og annet støttepersonell til å gjennomføre veikartet.

Derfor gikk jeg dypere for å forstå hvorfor selskapet fortsatt ikke nådde mange av disse punktene. I analysen oppdaget jeg et par ting. Det ene var at utviklingsteamene var organisert slik at de ble delt mellom flere produkter. Som produktperson er utfordringen med å lage et godt veikart at du må være trygg på at «Vi har disse fem faste ressursene. Disse fem ingeniørene arbeider med dette produktet, og de arbeider for eksempel 40 timer i uken. Kanskje har de 30 effektive timer i uken fordi det finnes distraksjoner – Slack-meldinger, e-poster og så videre.»

Da kan du se på denne tiden, projisere eller beregne fremover og finne ut hvor sannsynlig det er – 80 eller 90 % – at dere kommer til å nå dette veikartet.

Den store utfordringen med delt utvikling er at hvis det oppstår en krise i et annet produkt, eller hvis dere inngår en stor kontrakt for ett av produktene i porteføljen, kan det spore av både veikartet for hele selskapet og veikartet for det aktuelle produktet. En av de grunnleggende årsakene jeg fant, var altså delt utvikling.

Den andre store grunnleggende årsaken var et høyt omfang av uplanlagt arbeid og feil. Veikartet var opprettet med høy grad av tillit til at det kunne gjennomføres, men etter hvert som teamene støtte på problemer, kunne for eksempel en viktig avhengighet måtte oppgraderes. Kanskje ble en stor kontrakt inngått, slik at dere måtte flytte ressurser, eller så kom kode i produksjon og en feil ble oppdaget.

Alle disse tingene kan hindre at et veikart blir fullført. Som produktfolk vet vi at det finnes så mange variabler der ute, så du forsøker alltid å finne ut hvilke variabler som er faste og hvilke som er dynamiske, før du beregner produksjonen.

Men når du øker antallet ulike variabler, reduserer du sannsynligheten for å fullføre kvartalet eller regnskapsåret på en vellykket måte.

Hannah Clark: Og det handler bare om det som står på veikartet. Vi snakker ikke engang om problemene dette kan skape for innovasjon eller for alt som kommer senere.

Michael Pierce: Det stemmer.

Hannah Clark: Hva tror du er noen av måtene vi kan beskytte veikartet på? Nå har vi tatt høyde for all tiden vi trenger for å gjennomføre veikartet, men det finnes også tid vi vet at vi kommer til å trenge fremover for å innovere, skape nye funksjoner og svare på funksjoner som salgsteamet ønsker for en bestemt kunde. Hvordan kan vi beskytte veikartet og tiden på denne måten?

Michael Pierce: Det er et godt spørsmål. Det første jeg vil foreslå for en produktperson, er å se på tidligere kvartaler og etablere et godt utgangspunkt basert på det klassiske uttrykket «gårsdagens vær». Hvis det forrige kvartalet besto av 20 % feil, 20 % forespørsler om nye salgsfunksjoner og 10 % innovative satsinger, kan du bruke summen av dette til å lage prognoser for fremtidige veikart.

En god måte å skape enighet om veikartet i organisasjonen på, er å gjøre ideen om at et veikart bør være et balansert kosthold, kjent. Du kan for eksempel ha 40 % nye funksjoner basert på de historiske dataene, 10 eller 15 % tid til feil og kanskje 20 % fleksibilitet rundt en stor salgsforespørsel som kan komme inn.

Da kan du beregne et godt forhold mellom hvilke oppgaver som skal arbeides med, og i hvilke proporsjoner, akkurat som med et kosthold. Et godt første steg for produktfolk er derfor å sørge for at forholdet er riktig, og kommunisere dette til interessentene.

Da blir de ikke tatt på sengen hvis 10 % av ingeniørenes tid brukes på en interessant satsing eller en mer visjonær funksjon, fordi det allerede er kommunisert på forhånd. Det gjør det også mulig for teamene å si nei på en respektfull måte: «Vi skulle gjerne gjort den ekstra justeringen av denne funksjonen, men vi har satt av 10 % av kapasiteten vår dette kvartalet til å utforske en ny funksjon som kan hjelpe salgsavdelingen neste år.»

Alt går altså tilbake til forventninger. Dette gjelder både team og produktfolk i forhold til toppledelsen og andre interessenter.

Hannah Clark: Når vi snakker om team, hvilken sammenheng er det mellom hvordan teamene er utformet og hva som blir prioritert og levert?

Michael Pierce: Det går tilbake til det vi opprinnelig snakket om med produktdrevet eller salgsdrevet vekst. Du kan ofte se på hvordan teamene er utformet ut fra organisasjonens kultur.

Hvis organisasjonen har en svært offensiv salgskultur – offensiv på en positiv måte, altså at den forsøker å vinne mye ny virksomhet og det er mye energi rundt dette – vil det til en viss grad påvirke hvordan teamene er utformet. Kanskje får dere mye mer arbeid med utvikling av funksjoner, og kanskje må dere ha dedikerte team som bare arbeider med tilpasninger for kunder.

Mye av teamstrukturen vil derfor komme naturlig fra det organisasjonen eller selskapet verdsetter, enten det er salg, økonomi eller produkt som står først. Det handler også om hvilke tanker og verdier de har rundt helt nytt arbeid eller ny funksjonalitet.

Alt dette kan påvirke hvordan et team er utformet. Et annet godt tema her er hvilken struktur dere har for å gjennomføre arbeidet. Vi hører alltid om smidig utvikling, ikke sant? Tidligere hadde vi flere selskaper som arbeidet fossefallsbasert, og det finnes mange andre måter virksomheter organiserer seg på.

Det er derfor en annen viktig del av teamutformingen å forstå dette landskapet. Har vi en kultur som først og fremst er smidig? Er vi delvis fossefallsbaserte? Alt dette påvirker teamets sammensetning.

Når du forstår dette, kan du som produktperson være en pådriver for å synliggjøre mangler. Du kan si: «Jeg forstår at vi tidligere har vært sterkt fossefallsbaserte. Vi skal lansere et nytt produkt. La oss prøve en smidig prosess her», eller «La oss gå over fra et delt utviklingsteam til et dedikert utviklingsteam.»

Det å ha denne kontekstuelle informasjonen er svært styrkende for produktteam.

Hannah Clark: Har du hatt en slik erfaring, der du måtte eksperimentere med å omstrukturere et team for å tilpasse det til måten selskapet måtte fungere på?

Michael Pierce: Ja, absolutt. Det forrige selskapet jeg jobbet i, var et oppkjøpsfond i Boston. De rekrutterte meg for å bygge en produktavdeling fra grunnen av.

Som en del av dette så jeg på og analyserte hvordan alle teamene arbeidet, og hvordan de var organisert. Vi hadde et par ulike produkter i selskapet, og i praksis var det litt fossefallsbasert og litt rotete. Da vi analyserte alt grundig og jeg snakket med eierne og topplederen, sa jeg: «Det virker som om det finnes en mulighet til å omstrukturere hvordan teamene arbeider, og i hvilke mindre grupper de fungerer mot verdien av den samlede produktporteføljen.»

Det var en flott erfaring, fordi vi fikk muligheten til å innføre smidig utvikling på tvers av alle teamene. Vi fikk muligheten til å samle ulike grupper i plattformteam og team som arbeidet direkte med produktene. Vi ga også enkelte personer mulighet til å bli mer tekniske produktledere i stedet for klassiske produktledere for et standardisert programvare-som-en-tjeneste-tilbud.

Det var en fantastisk mulighet til å se helhetlig på hvordan ting var strukturert, og som produktperson kunne foreslå og anbefale den beste måten å strukturere teamene på. Det var også svært interessant å måle situasjonen før og etter. Jeg så økt effektivitet som følge av daglige morgenmøter, sprintdemonstrasjoner og alle disse tingene, som hadde en svært positiv og meningsfull innvirkning på organisasjonen.

Det er i hvert fall det beste vi kan håpe på som produktfolk: å kunne skape en innvirkning og måle den innvirkningen.

Hannah Clark: Absolutt. Etter å ha hatt denne erfaringen, kan du anbefale noen varselsignaler som produktfolk, særlig ledere, bør se etter, og som kan tyde på at det er lurt å begynne å omstrukturere eller tenke på å omstrukturere teamet?

Michael Pierce: Ja, absolutt. Et av varselsignalene er at du må hente inn data om disse tingene. Ett signal kan være å se på den samlede tiden det tar å gå fra idé til produksjon. Hvis denne tiden er betydelig lengre enn normalen, kan det være et problem. Det er riktignok vanskelig, fordi det ikke nødvendigvis finnes mange offentlig tilgjengelige normer for dette.

La oss si at det gjelder utvikling av en ny, relativt liten funksjon, og at det tar to uker å få den i produksjon. Det er ganske bra, ikke sant? En vanlig sprintsyklus er omtrent to eller tre uker. Som produktperson ville jeg ikke nødvendigvis sett på det som et varselsignal.

Men hvis du ser på en liten funksjon og det igjen er snakk om 40 utviklertimer, mens det faktisk tar fem, seks, sju eller åtte uker å få den i produksjon, ville jeg sett på det som et varselsignal. Da kan det være en flaskehals i kvalitetssikringen, eller kanskje en flaskehals når det gjelder å få de riktige interessentene til å bidra til epikken eller funksjonskravsdokumentet.

For meg ville dette være indikatorer. Hvis du igjen tenker på hele systemet som en boks med innspill og resultater, vil det være tegn på at resultatene ikke samsvarer med det du ville forventet ut fra et normalt utgangspunkt.

Hannah Clark: Hvordan ville du målt om omstruktureringen av teamene var vellykket?

Michael Pierce: Det finnes flere måter å gjøre dette på. Den klassiske måten er å se på teamets resultat. Leverer de flere verdiøkende trinn til sluttkundene på kortere tid? En annen klassisk måling er om vi reduserer tiden fra idé til produksjon.

Blir vi raskere og mer smidige – for å bruke ordspillet – når vi flytter arbeidet fra punkt A til punkt B? En annen måte som ofte overses, er å kombinere én-til-én-samtaler, oppfølging av medarbeidere og rapportering av funnene til ledelsen, med en klassisk spørreundersøkelse som måler situasjonen før og etter omstruktureringen.

Hvordan følte teammedlemmene seg? Følte de at de i mindre grad ble trukket i ulike retninger, altså at de måtte bytte fokus hele tiden? Følte de seg mer bemyndiget til å ta beslutninger sammen med de riktige personene for å få arbeidet levert?

Alt dette er gode indikatorer på om omstruktureringen fungerte, og om den ga positive resultater.

Hannah Clark: Hvis vi skal oppsummere dette, hva ble resultatene av erfaringen din med å omstrukturere teamet?

Michael Pierce: Det er et godt spørsmål. En ting som ble tydelig fra starten, da jeg snakket med folk, var at gapet i den felles forståelsen av spørsmål og uklarhet i arbeidet teamet utførte, ble kraftig redusert. Før jeg begynte i selskapet, hadde de møte én gang i uken.

Da vi omstrukturerte, hadde vi daglige morgenmøter. Teamet kunne derfor få svar på spørsmålene sine hver morgen fra de riktige personene. Det økte arbeidsmengden som ble levert, men reduserte også, vil jeg si, utviklernes uro, fordi de ikke måtte sitte med spørsmålene sine i en hel uke.

Hvis de var usikre på noe, kunne de forhåpentligvis få svar allerede neste dag. Ikke i alle tilfeller, men i de fleste. Jeg tror det gjorde at teamet følte seg langt bedre støttet av organisasjonen som helhet.

Hannah Clark: Til slutt kan vi snakke litt om å få støtte fra ledere og andre viktige interessenter. Hvordan har du lykkes med å dokumentere eller gi en indikasjon på at omstrukturering vil være verdt den innledende investeringen?

Michael Pierce: En viktig del av omstrukturering er å tenke på det som skjer fra punkt A til punkt B. Jeg vet at jeg ikke liker å kalle det en svart boks, men når du tenker på all kompleksiteten som oppstår når du skal gå fra punkt A til punkt B i programvareutvikling, er det fordi programvareutvikling er rotete.

Det er komplekst, og det finnes alle slags svinger og omveier. Når du vurderer omstrukturering, er det derfor viktig å snakke med ledere og andre høytstående interessenter om hva det faktiske resultatet skal være. Hvilke OKR-er har dere? Hvilke nøkkelresultater forsøker dere å skape for organisasjonen?

Deretter kan du bruke dette som et referansepunkt eller et utgangspunkt for å måle hvor effektivt arbeidet er organisert. Det samme gjelder for måling av arbeid generelt: Det handler om å vite hvor utgangspunktene er, og måle mot noe, slik at du kan se hvor nært du kom målet.

Hannah Clark: Flott. Michael, tusen takk for at du ble med oss. Jeg vet at du bidrar hos The CPO Club. Folk kan lese arbeidene dine på TheProductManager.com, men hvordan kan folk ellers finne deg på nettet?

Michael Pierce: Det stemmer. Jeg vil si at den beste måten å finne meg på nettet er via LinkedIn. Jeg er en digital minimalist, så jeg har bare LinkedIn. Men hvis du sender meg en melding der, tar jeg gjerne en virtuell prat med alle som lytter til podkasten.

Hannah Clark: Flott. Tusen takk for tiden din, og jeg setter virkelig pris på innsikten din.

Michael Pierce: Absolutt. Takk, Hannah.

Hannah Clark: Takk for at du lyttet. Hvis du vil ha mer god innsikt, 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.