Så korrigerar du kursen när färdplanen ständigt spårar ur

Läs transkriptet:

 

Vi testar att transkribera våra poddar med hjälp av ett program. Ursäkta eventuella stavfel, eftersom boten inte har rätt 100 % av gångerna.

 

Hannah Clark: Produktfärdplaner, precis som riktiga färdplaner, kommer ofrånkomligen att stöta på förseningar. Vissa kan du förutse och planera för, medan andra liksom dyker upp från ingenstans, men för det mesta kan du hitta en omväg och komma tillbaka på rätt spår. Men vad händer om du ser ett oroande mönster; mål missas, tidsplaner drar ut kroniskt på tiden och det känns helt enkelt som att hela färdplanen ständigt spårar ur?

I dagens avsnitt hör du Michael Pierce, produktledningschef på Public Consulting Group, som hävdar att en kroniskt försenad färdplan kan vara ett symptom på bristande samordning mellan företagets struktur och produktteamets struktur. Så om du har svårt att förstå varför dina mål och initiativ aldrig verkar falla ut på det sätt du prognostiserade, kan detta vara den kurskorrigering du behöver. Nu sätter vi igång.

Hej, alla lyssnare. Välkomna tillbaka till podden Product Manager. Jag är här med Michael Pierce. Han är produktledningschef på Public Consulting Group. Michael, stort tack för att du är med oss idag.

Michael Pierce: Ja, tack Hannah. Jag ser fram emot att vara här.

Hannah Clark: Michael, kan du börja med att berätta lite om din bakgrund och hur du hamnade där du är idag?

Michael Pierce: Ja, absolut. Jag började med en examen i ekonomi, som många inom produktområdet, eller hur? Vi har många olika bakgrunder. Jag arbetade på en försäkringsmäklarbyrå och vid den tiden hade en kompis gett mig en kopia av Lean Startup-metoden. Jag började läsa den och tänka på de olika processerna på jobbet som var ineffektiva, lite utifrån ett kanske väldigt omoget produkttänk.

Och jag slutade faktiskt med att skapa ett slags avancerat VBA-program. Jag lärde mig Visual Basic-kod på egen hand och började automatisera saker. Det var ungefär början på mitt intresse för det som då inte var lika etablerat som idag, men som jag skulle kalla produktledning, eller hur?

Att prata med användare, ta reda på vad de behöver, försöka bygga en lösning och följa upp med dem genom hela processen. Kort därefter skapade jag faktiskt mitt första startupföretag. Det var inom vattenverksamhet. Vi arbetade med många olika typer av pooler. Denver stad, där jag kommer från, i Denver, Colorado, var en av våra kunder, vilket var väldigt spännande för oss. Det var verkligen början på min produktresa, eller hur?

För vi pratade med användare och byggde en slags färdplan. Nästan enligt modellen nu, nästa, senare, eller hur? Jag var fortfarande mycket tidigt i min produktresa, men det var en fantastisk introduktion till området. Några år senare hade jag en så kallad acquihire-situation och började arbeta på Enterprise i Boston. Det var en fantastisk erfarenhet. Kort därefter hamnade jag på mitt nuvarande företag, Public Consulting Group, som produktledningschef.

Hannah Clark: Fantastiskt. Under din karriär har du arbetat med flera team, ibland som en del av teamet men ofta som deras ledare. Vilka är några av de utmaningar som du har upplevt som mer eller mindre typiska för produktteam i allmänhet?

Michael Pierce: Jag tror att en stor utmaning som många inom produktområdet inte alltid känner igen är att man behöver titta på företaget man arbetar på och försöka definiera, skulle jag säga, två stora kategorier. Den ena är: är företaget försäljningsstyrt? Är det ekonomi- eller marknadsstyrt? Vi har alla sett bra exempel på detta.

Om du tittar på HubSpot ser du att de definitivt är ett marknadsstyrt företag. Om du tittar på ett företag som Zoom eller Slack är de klassiska exempel på mycket stark produktstyrd tillväxt och produktstyrt ledarskap. Därför är det verkligen viktigt att produktteam tittar på sitt företag och frågar sig: träffar vd:n ofta försäljningsavdelningen och har de en mycket nära relation?

Eller har någon i företagsledningen vuxit fram genom verksamheten, försäljningen eller någon annan funktion? Det kan ofta vara en ledtråd till hur företaget fungerar. Jag skulle säga att en annan viktig sak som produktteam bör göra för att verkligen förstå företagets kultur är att tänka på hur stora beslut fattas.

Är det helt toppstyrt? Är det kanske den högsta ledningen som förankrar besluten hos andra chefer och ledare? Är det mycket demokratiskt? Att förstå strukturen för hur företag fattar viktiga beslut är alltså ytterligare något som är mycket viktigt. Om du känner till de två sakerna, alltså om företaget är försäljnings- eller ekonomistyrt och vilken typ av beslutsstruktur det har, kan det verkligen hjälpa en produktavdelning att förstå hur den passar in i helheten och hur dynamiken är uppbyggd så att teamet kan navigera.

Om du helt bortser från all den informationen och bara går till jobbet som produktavdelning kan du hamna i en situation med många hinder och utmaningar, eftersom du kanske inte positionerar dig på rätt sätt för att påverka andra i organisationen.

Hannah Clark: Låt oss kanske rama in det här med en anekdot. På vilka sätt kan bristande samordning, där produktteamet ser på sig självt på ett visst sätt jämfört med hur verksamheten faktiskt fungerar, orsaka problem längre fram?

Michael Pierce: Absolut. Om jag förstår frågan rätt tror jag att ett exempel är att det just nu finns mycket energi kring produktstyrd tillväxt, eller hur?

Och personligen älskar jag produktstyrd tillväxt. Jag är lite partisk, men om produktavdelningen arbetar på ett sätt som är mycket inriktat på produktstyrd tillväxt, medan företaget i själva verket har en mycket försäljningsstyrd tillväxt, kommer det att skapa en stor brist på samordning när det gäller vilka initiativ som finansieras och hur man får stöd från olika avdelningar.

Det är alltså återigen mycket viktigt att förstå sin plats som avdelning och funktion i förhållande till alla andra funktioner, så att man kan planera sina steg som team.

Hannah Clark: Låt oss prata lite om prioritering och de utmaningar som följer med den. Jag tror att det här är något som alla produktteam kämpar med i någon utsträckning, oavsett vilken tillväxtmodell man har. Vilka är några av de utmaningar du har sett när det gäller prioritering i de företag du har arbetat på?

Michael Pierce: Två saker kommer att tänka på. En av de stora sakerna är att det ofta finns ett gap mellan det ideala läget, eller önskelistan över vad vi vill bygga, och verkligheten.

En utmaning med prioritering är därför att man, när man arbetar med styrelser, börsnoterade företag och investerare, eller med företag som ägs av riskkapitalbolag, kan utsättas för stort tryck att ha en enorm färdplan full av spännande och attraktiva saker.

Utmaningen är då verkligen att föra alla tillbaka till verkligheten, men på ett sätt som får dem att känna sig bra inför det. När man talar om prioritering handlar det alltså om att skapa en gemensam förståelse för de mer övergripande delarna. Prioritering kommer först när man vet: det här är vår vision och det här är vår ledstjärna.

Man måste ha de övergripande delarna på plats för att kunna prioritera effektivt, vilket kanske är den andra fallgropen. När man har samordnat intressenter och ledning kring att detta är vår vision och så här kommer vi att mäta framgång, med vår ledstjärna, våra nyckeltal, våra OKR:er och så vidare, blir det mycket enklare att ha en sund prioriteringsprocess och gå från en uppblåst önskelista till något mycket tydligare.

Det kan fortfarande finnas många punkter, men de är mycket väl definierade. Vi vet som organisation att de här fyra stora epikerna eller initiativen är starkt kopplade till de två OKR:er som vi vet att vd:n och organisationen verkligen bryr sig om. Det är åtminstone så jag tänker kring prioriteringsproblemet.

Hannah Clark: I ett tidigare samtal berättade du en anekdot om att analysera ett företag. Vi nämner inte vilket företag, men det fanns problem med missade mål och du ombads identifiera orsaken till dem. Kan du berätta lite om det och återge vad anekdoten handlade om?

Michael Pierce: Absolut. Det här var ett fall där företaget missade en stor del av punkterna i färdplanen och ville veta varför, vilket är en helt rimlig och bra fråga. Som produktperson ser jag färdplanen som något som ofta är ett resultat av många andra processer. Det är resultatet av en stor låda med komplexa interaktioner och indata som går in i lådan.

En av de första sakerna jag gjorde var att börja skala bort lagren för att förstå: om vi missar 50 % av punkterna i färdplanen, vilka är grundorsakerna? En av dem, innan jag kom längre i min undersökning, var: har vi helt enkelt för många punkter i färdplanen?

Om du har en färdplan som kräver, säg, 2 000 timmar, men bara har kapacitet för 1 000 utvecklingstimmar, kommer du uppenbarligen att missa hälften av punkterna. Men såvitt jag kunde se fanns det tillräckligt många ingenjörer, kvalitetssäkringsmedarbetare och all annan stödpersonal för att genomföra färdplanen.

Då gick jag djupare för att verkligen förstå varför vi som företag fortfarande missade så många av punkterna. När jag gjorde min analys upptäckte jag ett par saker. Den ena var att utvecklingsteamen var organiserade på ett sätt där de delades mellan flera produkter. För en produktperson är utmaningen med att skapa en bra färdplan att man måste kunna lita på att man har dessa fem fasta resurser.

De här fem ingenjörerna arbetar med den här produkten och arbetar, säg, 40 timmar i veckan. De kanske har 30 effektiva timmar per vecka eftersom det finns störningar, som Slack-meddelanden, e-post och annat. Man kan alltså titta på den tiden och projicera eller prognostisera framåt och räkna ut sannolikheten, exempelvis 80 eller 90 %, för att färdplanen kommer att uppnås.

Men den stora utmaningen med delad utveckling är att om det uppstår en brand i en annan produkt, eller om du får ett stort avtal för en av produkterna i portföljen, kan det få hela företagets färdplan och den specifika produktens färdplan att spåra ur rejält. Det var alltså en grundorsak jag hittade: delad utveckling. Den andra stora grundorsaken var att det fanns en stor mängd oplanerat arbete och fel. Färdplanen hade skapats med hög tilltro till att den skulle kunna genomföras.

Men när teamen stöter på problem, till exempel att ett stort beroende behöver uppgraderas, att ett stort avtal vinns och resurser måste omfördelas, eller att kod sätts i produktion och ett fel upptäcks, kan alla dessa saker göra att en färdplan inte slutförs. Som produktpersoner vet vi att det finns så många variabler, så man försöker alltid göra sitt bästa för att avgöra vilka variabler som är fasta och vilka som är dynamiska och sedan arbeta bakåt till en plan.

Men när du ökar antalet olika variabler minskar du sannolikheten för att framgångsrikt slutföra kvartalet eller räkenskapsåret.

Hannah Clark: Och då pratar vi bara om det som finns på färdplanen. Vi har inte ens kommit in på problemen som det kan orsaka för innovation eller något som kommer härnäst.

Michael Pierce: Precis.

Hannah Clark: Ja. Vilka sätt tror du att det finns för att skydda färdplanen? Nu har vi räknat med all tid som behövs för att genomföra färdplanen, men det finns också tid som vi vet att vi kommer att behöva i framtiden för att innovera, skapa nya funktioner och svara på funktioner som försäljningsteamet vill ha utvecklade för en viss kund. Hur kan vi skydda färdplanen och tiden på det sättet?

Michael Pierce: Det är en bra fråga. Det första steget jag skulle föreslå för en produktperson är att titta på tidigare kvartal och skapa en bra utgångspunkt i huvudet kring det klassiska uttrycket ”gårdagens väder”. Om det förra kvartalet var 20 % fel, 20 % önskemål om nya funktioner från försäljningen och 10 % innovativa satsningar, kan du använda summan av det för att prognostisera framtida färdplaner.

Ett bra sätt att skapa samsyn kring färdplanen som organisation är att förankra tanken att en färdplan bör vara som en välbalanserad kost. Du har exempelvis 40 % nya funktioner baserat på historiska data, 10 eller 15 % tid för fel och kanske 20 % utrymme för en större försäljningsförfrågan som kan dyka upp.

På så sätt kan du arbeta fram en bra fördelning av vilka ärenden som ska hanteras och i vilka proportioner, precis som med en kost. Ett mycket bra första steg för produktpersoner är alltså att säkerställa rätt fördelning och kommunicera den till intressenterna.

Då blir de inte tagna på sängen om 10 % av ingenjörernas tid går till någon intressant satsning eller en mer visionär funktion, eftersom det redan har förankrats. Det ger teamen större möjlighet att respektfullt säga nej: vi skulle gärna göra den där extra justeringen av funktionen, men vi har avsatt 10 % av vår kapacitet det här kvartalet för att utforska en ny funktion som verkligen kan hjälpa försäljningen nästa år. Allt går alltså tillbaka till förväntningar, både för team och produktpersoner i relation till ledningen och andra intressenter.

Hannah Clark: På tal om team, hur hänger sättet som teamen utformas ihop med vad som prioriteras och levereras?

Michael Pierce: Jag tror att det går tillbaka till det vi ursprungligen pratade om kring produktstyrt eller försäljningsstyrt. Ofta kan man se hur teamen utformas utifrån organisationens kultur.

Om organisationen har en mycket aggressiv försäljningskultur, och med aggressiv menar jag på ett positivt sätt, som att man försöker vinna massor av nya affärer och det finns mycket energi kring det, kommer det till viss del att påverka hur teamen utformas, eftersom man kanske får betydligt mer arbete med utveckling av funktioner.

Man kan behöva ha särskilda team som bara arbetar med kundanpassningar. Mycket av teamstrukturen kommer därför naturligt från vad organisationen eller företaget värdesätter, oavsett om det är försäljning, ekonomi eller produkt, och från deras syn på och värderingar kring helt nytt arbete eller ny funktionalitet från grunden.

Allt detta kan påverka hur ett team utformas. Det kan också vara relevant att tala om vilken struktur man har för att genomföra arbetet. Vi hör hela tiden om agilt arbete. Tidigare hade vi fler företag som arbetade enligt vattenfallsmodellen, och det finns många andra sätt för företag att organisera sig.

En annan viktig del av teamutformningen är därför att förstå landskapet: har vi en kultur som i första hand är agil, eller arbetar vi till viss del enligt vattenfallsmodellen? Allt detta påverkar teamets sammansättning. När du väl förstår det kan du som produktperson vara en förespråkare för de luckor du ser och säga: jag förstår att vi tidigare i hög grad arbetade enligt vattenfallsmodellen.

Nu ska vi lansera en ny produkt. Låt oss experimentera med en agil process här, eller gå över från ett delat ingenjörsteam till ett dedikerat ingenjörsteam. Att ha den kontextuella informationen är mycket stärkande för produktteam.

Hannah Clark: Har du varit med om något sådant, där du behövt experimentera med att omstrukturera ett team för att anpassa det till hur företaget behövde fungera?

Michael Pierce: Ja, absolut. Det senaste företaget jag arbetade på var ett riskkapitalägt företag i Boston. De rekryterade mig för att bygga upp en produktavdelning från grunden.

En del av det arbetet var att undersöka och analysera hur alla team arbetade och hur de var organiserade. Vi hade ett par olika produkter på företaget och i praktiken var arbetssättet lite vattenfallsbaserat och lite rörigt. När vi analyserade allt och jag pratade med ägarna och vd:n sade jag att det verkade finnas en möjlighet att omstrukturera hur teamen arbetade och vilka mindre grupper som fungerade mot värdet i den övergripande produktportföljen.

Det var en fantastisk erfarenhet eftersom vi fick möjlighet att införa agilt arbete i alla team. Vi kunde samla olika grupper när det gällde plattformsteam och team som arbetade direkt med produkterna. Vi kunde också ge vissa personer mer av en teknisk produktchefsroll i stället för en klassisk produktchefsroll inom ett standardiserat SaaS-erbjudande.

Det var en fantastisk möjlighet att som produktperson se holistiskt på hur saker var strukturerade och föreslå det bästa sättet att organisera teamen. Att mäta före och efter var också väldigt givande. Jag såg den förbättrade effektiviteten av dagliga avstämningar, sprintdemonstrationer och allt annat som hade en mycket positiv och meningsfull inverkan på organisationen. Det är åtminstone det bästa vi kan hoppas på som produktpersoner: att kunna skapa en påverkan och mäta den.

Hannah Clark: Absolut. Efter den erfarenheten, kan du rekommendera några varningssignaler som produktpersoner, särskilt ledare, bör vara uppmärksamma på och som kan tyda på att det vore bra att börja omstrukturera eller fundera på att omstrukturera teamet?

Michael Pierce: Ja, absolut. En av varningssignalerna är att man måste samla in data kring sådana här saker. En signal kan vara att titta på den totala tiden från idé till produktion. Om den är kraftigt försenad jämfört med det normala är det relevant, även om det inte nödvändigtvis finns många publicerade normer för sådant här. Säg att det handlar om utveckling av en ny, mindre funktion och att det tar två veckor att få den i produktion.

Det är ganska bra. En genomsnittlig sprintcykel är ungefär två eller tre veckor. Som produktperson skulle jag inte nödvändigtvis se det som en varningssignal. Men om du tittar på en liten funktion och den borde ta 40 utvecklingstimmar, men det i praktiken tar fem, sex, sju eller åtta veckor att få den i produktion, skulle det för mig vara en varningssignal. Då kanske det finns en flaskhals i kvalitetssäkringen, eller en flaskhals när det gäller att få rätt intressenter att bidra till epiken eller funktionskravsdokumentet.

För mig skulle det vara indikatorer på att man, om man ser hela systemet som en låda med indata och utdata, får utdata som inte motsvarar vad man skulle förvänta sig utifrån en normal utgångspunkt.

Hannah Clark: Hur skulle du mäta framgången med att omstrukturera team?

Michael Pierce: Det finns flera sätt att göra det. De klassiska är att titta på teamets resultat. Skapar de fler värdeökningar för slutkunderna under en kortare tidsperiod? En annan klassisk fråga är om vi minskar tiden från idé till produktion.

Blir vi snabbare och mer agila, om man så vill, på att få arbetet från punkt A till punkt B? Ett annat sätt som ofta förbises är att kombinera individuella samtal, följa upp med medarbetarna och rapportera resultaten till ledningen med en klassisk enkät som mäter före och efter omstruktureringen. Hur upplevde teammedlemmarna situationen?

Känner de att de dras åt färre olika håll, alltså att de behöver växla mindre mellan uppgifter? Känner de sig mer bemyndigade att fatta beslut tillsammans med rätt personer och få ut arbetet genom dörren? Det här är alla bra indikatorer på om omstruktureringen fungerade och om den gav positiva resultat.

Hannah Clark: Om vi knyter ihop det här, vilka blev resultaten av din erfarenhet av att behöva omstrukturera teamet?

Michael Pierce: Det är en bra fråga. En sak som blev tydlig direkt när jag pratade med medarbetarna var att bristen på en gemensam förståelse kring frågor och tvetydigheter i teamets arbete minskade kraftigt, eftersom de hade möten en gång i veckan innan jag kom till företaget.

När vi omstrukturerade arbetssättet hade vi dagliga avstämningar. Teamet kunde då få sina frågor besvarade varje morgon av rätt personer. Det ökade verkligen arbetsresultatet, men minskade också den oro som utvecklarna kände eftersom de inte behövde sitta med frågor i en hel vecka.

Om de var osäkra på något kunde de förhoppningsvis få svar redan nästa dag. Inte i alla fall, men i de flesta. Jag tror att det fick teamet att känna sig betydligt mer stöttat i organisationen som helhet.

Hannah Clark: Avslutningsvis kan vi prata lite om hur man får stöd från personer högre upp i organisationen. Vilka sätt har fungerat för dig när det gäller att visa eller ge någon form av bevis på att en omstrukturering kommer att vara värd den initiala investeringen?

Michael Pierce: En stor del av en omstrukturering handlar om det som jag vet att jag egentligen inte gillar att kalla en svart låda. När man tänker på all komplexitet som krävs för att ta sig från punkt A till punkt B vid programvaruutveckling, eftersom programvara är rörig, finns det alla möjliga vändningar och omvägar.

När man funderar på omstrukturering är det därför viktigt att prata med ledningen och intressenter högre upp om vilket det faktiska resultatet ska vara. Vilka är OKR:erna? Vilka nyckelresultat försöker ni skapa för organisationen?

Sedan kan du använda det som ett riktmärke eller en utgångspunkt för hur effektiv organiseringen av arbetet är. Detsamma gäller när man mäter arbete i allmänhet: det handlar om att veta var utgångspunkterna finns och mäta mot något, så att man kan se hur nära man kom att uppnå målet.

Hannah Clark: Fantastiskt. Michael, stort tack för att du var med oss. Jag vet att du bidrar till The CPO Club. Man kan läsa dina texter på TheProductManager.com, men på vilka andra sätt kan man hitta dig på nätet?

Michael Pierce: Precis. Jag skulle säga att det bästa sättet att hitta mig på nätet är via LinkedIn. Jag är en digital minimalist, så jag använder bara LinkedIn. Men om du skickar ett meddelande där skulle jag gärna ha ett virtuellt samtal med alla som lyssnar på podden.

Hannah Clark: Fantastiskt. Tack så mycket för din tid och för dina insikter.

Michael Pierce: Absolut. Tack, Hannah.

Hannah Clark: Tack för att du lyssnade. För fler bra insikter, praktiska guider och verktygsrecensioner kan du prenumerera på vårt nyhetsbrev på theproductmanager.com/subscribe. Du kan höra fler samtal som detta genom att prenumerera på The CPO Club, oavsett var du brukar lyssna på poddar.