Dödar brist på tydlighet tyst din produkt?

Läs transkriberingen:

Vi testar att transkribera våra poddar med hjälp av ett program. Ursäkta eventuella stavfel eftersom boten inte är korrekt till 100 procent hela tiden.

Hannah Clark: Det är nästan en klyscha, men det händer hela tiden – du säger något till tre personer och de hör tre olika saker. Och det är inte så farligt om det du säger är: “Jag går och hämtar kaffe, vill någon ha något?” Men när du bygger en MVP med allt kortare tid kvar av startkapitalet, eller försöker lansera något enligt en strikt deadline, kan den bristen på tydlighet bli dödsstöten för ett startupbolag.

Dagens gäst är Bijan Shahrokhi – grundare av Product Management Exercises och Product Monkey AI. Bijan har ägnat den senare delen av sin karriär åt att hjälpa produktchefer att bli mer produktiva och bättre på att leda team. Förmågan att skapa tydlighet och samsyn i ett produktteam är grundläggande för dessa färdigheter. Om några minuter kommer Bijan att dela med sig av en lätt att kopiera process som kostar lite tid i början, men som kan rädda ett startupbolag på gränsen. Nu sätter vi igång.

Välkomna tillbaka, lyssnare. I dag har jag sällskap av Bijan Shahrokhi. Han är grundare av ProductManagementExercises.com, och har nyligen lanserat ett produktivitetsverktyg för produktchefer som heter ProductMonkey.ai.

Bijan, stort tack för att du är med oss i dag.

Bijan Shahrokhi: Tack så mycket för att ni ville ha med mig.

Hannah Clark: Bra. Vi börjar alltid på samma sätt. Jag skulle gärna vilja att du berättar lite om din bakgrund och hur du hamnade där du är i dag.

Bijan Shahrokhi: Absolut. Jag är produktchef i själ och hjärta. Jag har varit produktchef i över tio år, helt av en slump.

Jag visste inte ens vad produktledning var förrän jag hade ett startupbolag som inte gick särskilt bra. Jag frågade en vän vad han tyckte att jag borde göra härnäst och han sa: ”Du borde bli produktchef.” Jag tänkte: vänta lite. Det låter väldigt intressant, som produkt och att leda produkten. Det är det jag vill göra.

Så därefter blev jag produktchef. Jag har gjort några olika saker under de senaste tio åren. De första åren arbetade jag i större organisationer, bland annat på en bank som produktchef och sedan som produktstrateg. Efter det var jag del av två startupbolag. Båda lanserades när jag började på företagen, och ett av dem köptes upp inom ett och ett halvt år av en större aktör i ekosystemet.

Det andra var faktiskt ett framgångsrikt projekt. Det värderades till flera miljarder dollar när det stod på sin höjdpunkt. Det pågår fortfarande och fortsätter att växa kraftigt. Sedan dess har jag under de senaste åren främst fokuserat på Product Management Exercises. Nyligen har vi också lanserat en annan produkt för produktledningsgemenskapen som heter ProductMonkey.ai.

Hannah Clark: Fantastiskt. I dag ska vi prata om tydlighet i organisationer, vilket är något du personligen brinner för. Med tydlighet menar jag att säkerställa att alla intressenter är samordnade och delar samma bild av vad som händer och vad som ska byggas.

Hur ser det ut för dig när en organisation saknar tydlighet?

Bijan Shahrokhi: Bra fråga. Jag tror att det största och tydligaste tecknet på att en organisation saknar tydlighet är när du går runt i organisationen och frågar olika personer vad de anser vara framgångskriterierna för det som ska levereras som nästa stora milstolpe, och börjar höra olika berättelser.

Jag kan ge ett exempel. Anta att du arbetar med en mycket teknisk produkt som hanterar många prestandamått, exempelvis fördröjning, hastighet, antal transaktioner per sekund eller mängden uppgifter som kan slutföras. Om detta inte är tydligt definierat av en teknisk person i organisationen kan de försöka bygga något som klarar extremt stora transaktionsvolymer.

Men om du frågar någon som är mer affärsorienterad och kundnära kanske de säger att vi bara behöver få ut något så att vi kan börja få feedback från kunden. Du vet att det saknas tydlighet när du börjar prata med personer i hela organisationen och hör olika siffror, eller när de säger: ”Det har vi aldrig tänkt på eller diskuterat.” Det är vanligtvis en tydlig varningssignal för dig som produktchef att inse att något inte stämmer – det verkar saknas tydlighet här.

Hannah Clark: Det låter som att du har några egna erfarenheter av det där. Kan du, utan att nämna namn, komma på en anekdot?

Bijan Shahrokhi: Absolut. Det senaste projektet jag berättade om, som blev värt flera miljarder dollar, var ett företag som bara hade några månader kvar innan pengarna tog slut och som ännu inte hade lanserat något projekt.

De trodde att de bara var några månader från att lansera produkten. När jag började fick jag först höra att det bara var tre månader kvar. När jag väl började insåg jag att det som vissa av grundarna hade i åtanke kanske låg fem till tio år från verkligheten.

Och det som vissa av ingenjörerna trodde att de levererade låg också några månader bort. Det fanns alltså ett enormt gap mellan de två perspektiven. Därför fastnade de i en utvecklingscykel i över tre år, eftersom ingenjörsteamet fortsatte att presentera något som nästan var färdigt. Vissa grundare eller affärspersoner tittade då och sa: ”Vänta lite, ni är inte redo. Det här motsvarar inte riktigt det vi har i åtanke.” De definierade om vad som behövde byggas, och ingenjörerna gick tillbaka till arbetet besvikna och med känslan av att de inte skapade särskilt mycket värde för organisationen.

Det vi gjorde då var att jag under mina tre första månader som produktchef träffade många intressenter för att verkligen förstå vilka egenskaper som hade mycket olika perspektiv inom organisationen.

Jag insåg till exempel att en viss egenskap, enligt vissa personer i organisationen, behövde ingå i den första lanseringen. Den andra hälften höll inte med. Vi började därför ha många samtal om dessa specifika delar och skapade tydlighet kring huruvida de skulle byggas eller inte. Det var ett ja- eller nej-beslut. Alternativt kunde beslutet vara att vi skulle göra en mycket enkel version av funktionen.

Då definierade vi exakt vad vi skulle göra som en del av den. Först därefter tog det ungefär ett år att faktiskt bygga en enkel version av det som ursprungligen hade beskrivits som något vi skulle lansera inom tre månader. Ärligt talat tog det bara flera månader att skapa tydlighet kring vad som skulle byggas under ett år.

Förhoppningsvis visar det hur du genom att skapa mycket tydlighet faktiskt kan få ut något på marknaden. När det väl är lanserat kan du använda feedback från användarna, gemenskapen och hela ekosystemet för att avgöra vilka av de saker som finns i planeringen som bör prioriteras ytterligare.

Hannah Clark: Ja, och det är en enorm prestation att minska ett sådant gap. Det verkar nästan omöjligt. Det är ganska kraftfullt att använda den metoden. Om vi tar ett steg tillbaka, vilka bredare konsekvenser ser du när en organisation inte har byggt in processer för tydlighet i sin övergripande kultur, inte bara i produktteamet?

Bijan Shahrokhi: Den största effekten är att de vanligtvis aldrig lanserar något, och det är ett stort problem. Många fantastiska projekt når aldrig ut på marknaden eftersom pengarna tar slut innan de hinner börja generera intäkter till företaget. Det är tyvärr en ännu hårdare verklighet för forsknings- och utvecklingsbaserade projekt. Sådana projekt är ofta mycket vetenskapligt inriktade och försöker skapa något banbrytande. De drivs vanligtvis av grundare med stark akademisk bakgrund.

Människor med stark akademisk bakgrund – och jag säger inget illa om dem, eftersom jag själv också har en stark teknisk och akademisk bakgrund och ser det som något positivt – söker ofta perfektion. När en organisation leds av dem fortsätter de att bygga, förbättra och lägga till eftersom de strävar efter perfektion. De oroar sig ständigt för extrema scenarier som, ärligt talat, inte ens skulle vara världens undergång om de inträffade under projektets inkubations- eller tidiga fas.

Resultatet blir att de aldrig lanserar något, och världen får aldrig se visionen de hade för den nya tekniken.

Hannah Clark: Ja, det där med ”färdigt kontra perfekt” är något vi alltid brottas med – perfektionisterna kontra dem som bara vill lansera, eller hur? Ett område där tydlighet verkligen är oerhört viktigt är, som du sa, utvecklingen av en MVP. Det är ett område som lätt leder till många felsteg och missförstånd som kan bli förödande i slutändan.

Vilka är de vanligaste fallgroparna som team som bygger MVP:er bör vara uppmärksamma på, och vilka lösningar finns för att undvika dem?

Bijan Shahrokhi: Jag tror att det största misstaget jag har sett startupbolag göra med begreppet MVP är att blanda ihop det med att leverera en trasig produkt som inte ens går att använda.

Jag har sett det många gånger. Utan att nämna namn kan jag ge ett exempel. Jag är investerare i en viss företagslösning. Jag brinner verkligen för den och är entusiastisk över den, eftersom jag redan från början kunde se mig själv vilja använda den.

Jag kunde även se att min organisation på Product Management Exercises skulle vilja använda den dagligen. Det största hindret för att faktiskt börja använda den har varit att den är så full av fel att vi inte ens kan använda den. Det är mycket viktigt att vi som produktledare uppmärksammar detta och ser till att en MVP inte är en buggig produkt som inte kan förmedla produktens värdeerbjudande.

Du måste fortfarande se till att den centrala användarupplevelsen, eller det centrala produktvärdet du försöker leverera till användaren, fungerar smidigt från början till slut. Du kan ta bort mycket som är onödigt, men du måste säkerställa att du kan leverera den centrala produktupplevelsen.

Jag tror att detta är ett av de största misstagen företag gör: de missförstår vad MVP betyder och tror att det innebär att man kan lansera något som är trasigt.

Hannah Clark: Ja. Det finns nästan ett läger som inte vill vänta med lanseringen tills allt är perfekt, och sedan finns den andra sidan av skalan. Det låter rimligt.

Du har en ganska omfattande process för att skapa tydlighet i organisationer, som du var inne på tidigare. Om lyssnarna ville kopiera den metoden till sitt eget arbetsflöde, vilka steg skulle du rekommendera för att säkerställa att alla i teamet är samordnade?

Bijan Shahrokhi: Tack för frågan. Det är intressant att du frågar, eftersom många på PM Exercises tycker att den här processen är mycket hjälpsam. Ärligt talat är den ganska enkel och fokuserar på att göra det svåra arbetet tidigt, innan du faktiskt startar ett projekt. Den är stegvis, så jag går snabbt igenom den.

I grunden lägger du först mycket tid på att skapa samsyn i hela organisationen genom en steg-för-steg-process. Först när du tycker att alla är samordnade börjar du. Intressant nog har detta arbetssätt anammats av många större organisationer, exempelvis finansiella institutioner.

När vi gick från vattenfallsmodellen till agil och Scrum-metodik trodde vi att det innebar att man inte behövde vara tydlig med vart man var på väg, utan bara behövde tänka på vad man skulle göra under de kommande två veckorna. Men det var inte avsikten med agilt arbetssätt. Avsikten var att leverera något meningsfullt varannan vecka samtidigt som man tydligt vet vart man försöker nå inom några månader.

Hur gör man då? När jag leder ett projekt eller en produkt där jag märker att det saknas mycket tydlighet börjar jag med att boka enskilda möten med intressenterna för produkten. De måste vara individuella möten, inte gruppmöten, eftersom någon kanske delar en åsikt om känsliga ämnen och någon annan hoppar in. Då kan du, som produktens vägledare, inte ta in all nödvändig kontext på rätt sätt.

Du behöver få fram varje persons perspektiv och verkligen förstå det. Anta att du står inför en avvägning: ska vi bygga X eller inte? Det är ett binärt beslut, men modellen fungerar även för mycket annat.

Du träffar personerna, tar reda på varför de tycker att något bör eller inte bör göras och frågar också vilka saker du måste vara uppmärksam på när du fattar beslutet. De kommer förmodligen att nämna fyra eller fem saker som är mycket viktiga för dem i deras del av verksamheten.

Det blir ännu viktigare inom forskning och utveckling. Ju mer teknisk produkten är, eller ju fler tekniska beroenden den har till andra verktyg i organisationen, desto viktigare blir det eftersom det finns ämnesexperter. Du går vidare till nästa person och nästa, och träffar alla individuellt.

Med tiden händer något av följande: din egen uppfattning om vilken avvägning som bör göras blir starkare, du utvecklar nya uppfattningar eller så förändras dina avvägningar. Du inser kanske att vissa saker är svårare eller enklare än du först trodde och justerar dem.

Under tiden samlar du in mer information individuellt och går tillbaka till vissa personer. Du kan säga: ”När jag först träffade dig sa du att detta var dina största bekymmer. Efter mina samtal med andra tror jag inte att de borde vara ett problem. Här är argumentet. Berätta varför jag har fel, eller säg om jag har rätt.”

När du går igenom denna tidskrävande dialog fram och tillbaka inser du ofta att många av utmaningarna teamet hade egentligen berodde på bristande kommunikation. Ingen hade lagt tid på att tydligt beskriva alla olika avvägningar för de olika intressenterna i organisationen, och många saker blir lösta.

Med tiden får du allt större tydlighet kring alla avvägningar du behöver ta hänsyn till. Metoden kan även fungera för produktprioriteringar. Efter ett tag inser du kanske att några punkter fortfarande har olika åsikter kopplade till sig. Hälften av teamet kanske tycker att en viss egenskap är mycket viktig, exempelvis säkerhet, medan den andra hälften inte tycker att säkerhet är särskilt viktigt som egenskap.

De har sina egna skäl. Då organiserar du ett gruppmöte. Du säger: ”För att vi ska kunna fatta det här beslutet är detta en egenskap som är relevant för oss. Det finns två olika perspektiv och jag vill att vi diskuterar dem.” Genom det direkta samtalet kan ni vanligtvis komma fram till ett beslut.

Ibland finns det några åtgärdspunkter, som att undersöka saken ytterligare. Då kan du organisera nästa möte och återkomma med: ”Detta var vårt ursprungliga mål. Vi gjorde undersökningen och här är det nya resultatet. Vad gör vi?” Men ni fattar ett beslut. När du har tydliggjort alla avvägningar blir det mycket lättare för teamet att besluta om ni ska välja en viss väg eller vilka produktprioriteringarna ska vara.

Då kan ni säga: ”Nu har vi beslutat att detta är vår prioritet och vi kommer att fokusera på den.”

På en mycket övergripande nivå tänker jag så här: steg ett är att börja med individuella möten där du tydligt förstår varje persons perspektiv. Steg två är att gå fram och tillbaka mellan personerna vid behov för att säkerställa att alla punkter där de har olika åsikter har hanterats. Om inte, markerar du dem för gruppdiskussioner.

Steg tre är gruppdiskussionerna. Slutligen leder processen till en sammanhängande produktstrategi, produktspecifikation eller uppsättning produktprioriteringar. För varje scenario kan det finnas ett extra steg. När det gäller produktprioriteringar behöver du exempelvis tänka mer på målet.

Du kanske behöver börja med att säga: ”Vårt mål är att snabbt få ut något på marknaden och lära oss.” Sedan vill du se om någon inte håller med. Om alla håller med kan du gå vidare i processen.

Hannah Clark: Jag skulle vilja prata lite mer om produktprioriteringar i allmänhet. Även när vi har relativt nära till konsensus, eller känner att vi är överens om målen och vad framgång innebär, kan det vara svårt att balansera konkurrerande prioriteringar.

Det finns förstås hundratals ramverk för prioritering av produktfunktioner. Vilka metoder har du använt och funnit mest framgångsrika och brett tillämpbara när du arbetar med konkurrerande prioriteringar i sådana här sammanhang?

Bijan Shahrokhi: Ett sätt jag använder är att poängsätta dem och betrakta dem ur några olika perspektiv.

Det första är vilken påverkan jag tror att den aktuella funktionen eller produkten kommer att ha på målgruppen eller mål användarna. Det andra är sannolikheten att vi faktiskt kan realisera den påverkan. I många fall vet du inte ens om den nya produkten kommer att tilltala målgruppen.

I så fall är sannolikheten lägre. Det tredje är hur lätt den är att genomföra. Formeln jag har i huvudet är: ”påverkan multiplicerat med sannolikheten för påverkan, plus enkelheten i genomförandet.”

Påverkan graderas från ett till fem, där fem är störst påverkan och ett är minst. När det gäller enkelheten i genomförandet innebär fem att det är lätt att genomföra och ett att det kräver mycket arbete. Därefter får du en poäng.

Det jag gillar med metoden är att den är objektiv. Genom processen jag nyss beskrev kan du ha liknande samtal och säga till en teammedlem: ”Utifrån mina samtal med alla har jag sammanställt den här tabellen över de viktigaste projekten i organisationen. Så här ser jag på deras poäng utifrån påverkan och genomförandeinsats. Baserat på poängen är detta resultaten för vilka projekt som bör prioriteras högst.”

Då kan personen svara: ”För det första saknar du tre projekt som vi också arbetar med.” Eller: ”Det här projektet borde delas upp i tre delar eftersom det är mycket större än du tror.” De kan också säga att de inte håller med om bedömningen av påverkan eller arbetsinsatsen. Men nu har ni objektiva samtal som handlar om sakfrågor.

Det intressanta med ett sådant poängsystem är att du inte försöker uppskatta exakt hur lång tid allt kommer att ta. Du jämför i stället projekten relativt med varandra. Därför blir det mycket lättare att snabbt nå någon form av samsyn kring hur mycket värde ett projekt kommer att skapa eller hur mycket arbete det kräver.

Det leder till en uppsättning tydligt definierade prioriteringar. Du kan säga: ”Det här är de fem saker vi ska fokusera på under nästa kvartal.” När en ny punkt tillkommer, eller någon i organisationen säger ”vi borde göra detta”, tittar du på prioriteringstabellen och säger: ”Låt oss titta på det. Vi diskuterade det och beslutade att det inte är en prioritet just nu av den här anledningen. När vi har slutfört de här två eller tre sakerna kommer vi att prioritera det.”

Ibland inser du att ytterligare saker måste läggas till. Vi kan även prata om hur du hanterar sådana situationer. Men jag tycker att den här metoden är mer objektiv och gör det enklare att ta fram prioriteringar.

Hannah Clark: Jag uppskattar det. Vi har tidigare pratat på The Product Manager om att avpersonifiera feedback och vissa av dessa prioriteringssamtal, så att människor inte känner att det finns ett personligt skäl till att deras hjärteprojekt eller agenda har nedprioriterats eller placerats i en annan ordning än de tycker är rätt.

Det är en mycket konkret metod. Jag uppskattar den verkligen. Vad var det du sa att du ville återkomma till? Du sa att vi skulle prata om det för en liten stund sedan.

Bijan Shahrokhi: Jag sa att vi också kan prata om hur människor ibland kommer in och säger att något måste vara en prioritet, och att du sedan inser att det faktiskt måste prioriteras av någon anledning.

Hur hanterar man det? Ibland kan man fundera på hur man ska göra. Det kan inte bara läggas till på prioriteringslistan. Antingen måste du se till att det inte påverkar leveranstakten för de redan högt prioriterade punkterna, eller så måste du göra något annat.

Ett alternativ är att ta bort något från listan och nedprioritera det. Då ersätts det av den nya punkten genom poängsystemet. Ett annat alternativ är att tillföra ytterligare resurser som arbetar med den nya prioriteringen. Principen är att sakerna på prioriteringslistan inte ska gå långsammare bara för att du lägger till ännu en punkt.

Detta är enligt min mening produktchefens arbete. Så fungerar det inte i alla organisationer, och då börjar man få problem med att saker inte blir levererade.

En bra produktchef följer däremot detta noggrant och ser till att ny information som kommer fram hanteras. Om något behöver prioriteras måste man fundera på hur det ska göras. Antingen tar man bort något från listan eller ser till att få ytterligare resurser som kan arbeta med det utan att påverka leveranstakten för de andra punkterna.

Hannah Clark: Fascinerande. Jag ville byta ämne lite eftersom vi börjar få slut på tid. Jag ville prata lite om produktivitet, som också är något du brinner för och sannolikt en viktig anledning till att du grundade productmonkey.ai.

Har du några allmänna tips om produktivitet för vår publik, och kan du berätta lite om Product Monkey AI som människor kan tycka är intressant? Det är ett väldigt häftigt verktyg.

Bijan Shahrokhi: Absolut. Med Product Monkey AI automatiserar jag den uppgift som jag tycker är mycket viktig för oss produktchefer men som jag inte tycker om att göra: att lägga mycket tid på att skriva detaljerade krav och acceptanskriterier.

Product Monkey AI försöker samla in så mycket information som möjligt om projektet du arbetar med, din organisation och det specifika användarflöde du hanterar.

Med rätt vägledning från dig och hjälp av AI kan vi ge dig detaljerade produktkrav, acceptanskriterier, testscenarier och även händelser och mätvärden att uppmärksamma när du bygger produkten. Du kan ta det och börja arbeta med det direkt. Du får ett snabbt utkast som motsvarar ungefär 80 procent av arbetet för ärenden till ingenjörsteamet och produktkravsdokument, innan du lägger till det sista i dina dokument.

Sedan kan du ägna din tid åt de sista 20 procenten och färdigställa dem. En av de fördelar vi kan skapa för produktchefer är, som jag nämnde, att bidra med tydlighet. Product Monkey AI kan göra det genom att minska den tid det tar för produktchefer att skapa tydlighet för ingenjörsteamen.

Hannah Clark: Fantastiskt. Jag är säker på att många som lyssnar kommer att ha stor nytta av det verktyget. Bijan, stort tack för att du var med oss i dag. Var kan människor följa dig på nätet om de vill se vad mer du gör?

Bijan Shahrokhi: De kan hitta mig på Twitter, eller X som vi kallar det nu. Mitt X-användarnamn är bijan_sha. Ni hittar mig där. Ni kan också besöka PM Exercises eller Product Management Exercises. Sök efter någon av dem så kommer ni till vår webbplats, där ni också kan komma i kontakt med mig.

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

Bijan Shahrokhi: Tack så mycket för att ni ville ha med mig.

Hannah Clark: Tack för att ni lyssnade. För fler bra insikter, praktiska guider och verktygsrecensioner kan ni prenumerera på vårt nyhetsbrev på theproductmanager.com/subscribe. Ni kan höra fler samtal som detta genom att prenumerera på The CPO Club där ni brukar hitta era poddar.