“Nu förstår jag verkligen varför din roll som produktägare är så viktig!”
Så löd en av mina närmaste vänners kommentarer i helgen. När jag befinner mig i sociala sammanhang med vänner och bekanta får jag allt som oftast en frågande blick när jag berättar om min roll som produktägare. Jag har gång på gång funderat på hur jag på bästa sätt ska förklara min roll och dess värde för företag som genom digitalisering vill förbättra sina produkter, tjänster och/eller processer genom en hisspitch.
Det som blivit tydligt för mig är att något alltför ofta måste gå väldigt fel i företags digitala utvecklingsprojekt innan man hinner lyfta blicken för att se vad som faktiskt påverkar. Det är inget fel med detta då jag som jobbar i branschen har stenkoll, och de som påbörjar digitala projekt utan spetskunskap inte har erfarenhet eller lagt rätt resurser på just sitt utvecklingsprojekt först ser problemet när det dyker upp.
Det är här rollen produktägare blir viktig, då jag som produktägare skapar transparens och förståelse i projektet. En av de största uppgifterna är att kunna svara på frågor om “varför”. Som PO är jag inte utvecklare och meningen är inte heller att jag ska ha svar på “hur” en produkt ska byggas,. Det jag ska svara på är vad vi vill uppnå, det vill säga målet med produkten eller funktionen. Om vi inte vet varför vi bygger en funktion är det stor risk att resultatet blir något utan värde.
Nedan hittar du fem viktiga punkter som jag som produktägare på NetConsult arbetar med och som jag hoppas klargör vad rollen innebär i praktiken.
Affärsförståelse
Som produktägare är jag bryggan mellan kundens affärsbehov och den service vi som byrå levererar. Det första steget är att förstå kunden, deras verksamhet och ambitioner. Detta innebär att ha kunskap om verksamhetens skala, antal anställda, marknader, omsättning och företagets unika försäljningsargument (USP). Frågor som jag som produktägare bör kunna svara på inkluderar:
Vad gör att kunderna väljer företaget idag?
Hur ser framtidsplanerna ut?
Vad är företagets långsiktiga vision och operativa plan inom den närmaste framtiden?
Vilka är de önskade målen inom X månader eller år?
Vilka stakeholders och funktioner kan påverkas och behöver inkluderas i dialogen?
Hur är den interna strukturen för affärs- och IT-utveckling uppbyggd idag?
Hur kan vi som byrå bäst interagera med denna struktur?
Identifiera utmaningar och möjligheter
När de nuvarande förutsättningarna och det önskade framtida läget är kartlagt, är nästa steg att identifiera faktorer som påverkar möjligheten att nå målen. För att nå det långsiktiga målet X måste vi först ha Y på plats, och för att Y ska vara möjligt måste vi ha löst Z. Vi behöver identifiera vilka trösklar som i störst utsträckning hindrar oss från att nå målen och vad som krävs för att eliminera dessa hinder. Viktiga frågor att besvara är:
Vilka är kundens största pain points?
Vad skulle i störst utsträckning förenkla livet för användare och slutkunder?
Var finns de största möjligheterna att driva tillväxt och lönsamhet?
Analysera förutsättningar
Här kan vi börja skissa på prioriteringar och tänkbara initiala arbetsinsatser. Ofta kan utveckling inledas redan här och sedan fortsätta iterativt. Ett steg som inte bör hoppas över är att analysera förutsättningar och beroenden som kan påverka hur vi levererar högt värde så snabbt som möjligt. Viktiga frågor att ta hänsyn till inkluderar:
Finns det teknisk skuld eller existerande lösningar som är svåra att bygga bort eller uppdatera?
Finns det lagkrav eller andra hårda deadlines som påverkar vad som måste vara löst när?
Finns det kunskapsluckor eller informationsbrister som påverkar vår förmåga att bedöma effektivitet och lönsamhet?
Initial plan för MVP
Nästa steg är att föreslå en rimlig MVP (minimum viable product) baserat på all tillgänglig information. En MVP är en första leverans som snabbt och med små medel kan leverera ett tydligt värde. Det kan till exempel handla om att eliminera eller reducera en pain point eller en vital enabler. En MVP behöver inte vara perfekt utan kan utvecklas och förbättras över tid, men ska göra skillnad för kunden från första dagen den tas i bruk. Viktiga frågor att besvara när vi bygger MVP är:
Vilka möjliga leverabler kan utgöra en MVP?
Påverkar tidshorisonter vilken MVP vi bör välja?
Påverkar tekniska beroenden vilken MVP vi bör välja?
Påverkar vår analys- och uppföljningsförmåga vilken MVP vi bör välja?
Bygg vidare utifrån affärsvärde
Att etablera en plan för fortsatt arbete och en backlog av önskvärda insatser kan med fördel inledas simultant med steg fyra. Samtidigt är det oftast lättare att uppskatta tidsåtgång, identifiera fler eller nya beroenden samt förfina lönsamhetskalkyler när utvecklingsarbete väl har inletts och leveranser har börjat ske. Viktiga frågor att besvara är:
Har vi den information vi behöver för att förstå behov och beroenden för ärenden i vår backlog?
Har vi den information vi behöver för att kunna skapa business cases och prioritera vår backlog utifrån dessa?
Har vi den information vi behöver för att uppskatta ungefärlig tidsåtgång för ärenden i vår backlog?
Efterföljande arbete sker utifrån en levande prioritering, styrd av affärsvärde, och med blicken mot det långsiktiga målet. Om och när ny information förändrar förutsättningarna bör prioriteringar och planer uppdateras.
Jag hoppas att denna artikel har tydliggjort arbetet för en produktägare. Om du har några frågor eller vill prata vidare, skicka ett meddelande till mig eller någon av mina kollegor!
