luxshan ratnaravi bloghoved

Produktlederens dilemmaer

Product Manager. Produktejer. Product Owner. Produktansvarlig. Produktchef. Lad os fremover bruge ordet 'produktleder'. Selvom nogle af jobbene har overlap, mens andre komplimenterer hinanden, er fællesnævneren, at personen i denne rolle sidder med mangen et spændende dilemma. Herunder giver jeg mine bud på, hvordan disse problemstillinger kan løses.

Klar prioritet >< udviklerinvolvering

Stereotypen går på, at en udvikler (eller rettere; programmør) i gamle dage var en introvert nørd, der helst sad og kodede i kælderen med kasser af colaer. Han (det var jo aldrig en hun) ville helst ikke have med andre mennesker at gøre, men ville blot have en tydelig opgaveliste, som han kunne løse. Denne type nørd findes helt sikkert stadig - men min erfaring er, at hvor udviklere tidligere fandt tilfredsstillelse i at udforske, hvordan opgaven kunne løses, vil de i dag også vide, hvorfor. Dette stiller relevante, kommunikative krav til dig som produktleder, da denne udvikling kan føre til utilsigtede dilemmaer i en agil kontekst, hvor produktlederen forventes at have en klar prioritering på opgaverne, men hvor den fastlagte prioritet udfordres af udviklerne. Behøves dette imidlertid være noget negativt?

Min holdning er, at jo flere der udfordrer prioriteringen, desto skarpere bliver man nødt til at være med argumenterne for den valgte prioritet, som dermed altså ikke bare kan være en POOMA (Pulled Out Of My Ass), men i stedet bør bygge på kundeinput, data fra brugen af produktet og lignende målbare fakta. Det, at udviklerne har en holdning til produktretningen, er et tegn på engagement, og produktlederen bør betragte udviklerteamet som endnu en værdifuld interessent af produktet. Selvom deres opgave er at løse 'hvordan', og produktlederens er 'hvad' og 'hvornår', er der kæmpe gevinster i at inddrage udviklerne i førstnævnte. Husk derfor at få deres besyv med i dit arbejde med at prioritere prioritere backloggen, inden den evt. skal godkendes hos ledelsen - dermed bliver det ikke kun det umiddelbare planlægningsarbejde nemmere, men du vil have et udviklingsteam, som tager ejerskab for prioriteringen og dermed de næste features.

Kundekrav >< strategi/roadmaps

Skal man følge kundernes krav til applikationen eller virksomhedens foruddefinerede teknologistrategiske roadmaps? Umiddelbart bør dette være en no-brainer; selvfølgelig skal produktudvikling drives af brugerne/kunderne, da produktets eksistensberettigelse beror på, at brugerne vil betale for at bruge eller få udviklet det. Dog eksisterer der i større virksomheder højest sandsynligt langsigtede teknologiske målsætninger, såsom modning af en given teknologi som Cloud eller Robotics, der kan spille ind på, hvilken retning det givne produkt kommer til at tage - men forhåbentligt er disse to strømninger ikke modsatrettede.

En tilgang kunne være at lade kundekravene diktere selve indholdet/features'ne af produktet, mens fx teknologi-roadmaps/-strategier agerer springbræt til, hvordan indholdet implementeres. Se på de prædefinerede strategier som en oplagt måde at få afprøvet ny, værdifuld teknologi, der kan løfte produktets anvendelse og potentiale til et nyt niveau, i stedet for som en begrænsning af friheden for produktudviklingen. Medmindre brugerne er meget it-teknisk funderede og kun stiller krav i dén retning, bør det bagvedliggende (såsom arkitektur og platform) ikke være af speciel relevans for dem, så længe produktet lever op til diverse SLA'er og OLA'er - det vigtigste for dem er funktionaliteten.

Én kundes krav >< andre kunders krav

Ligeså oplagt det er, at kundekrav bør drive produktudviklingen, ligeså svært kan det være at finde den rigtige prioritet mellem forskellige kunders forskellige krav. Selve prioriteringen af features er en videnskab/religion i sig selv, og der er mange måder at finde frem til "sandheden".

Meget kort sagt; ved at stille det rigtige 'hvorfor' til kravstilleren, så vedkommendes pain points kommer frem, er det typisk muligt at gruppere de forskellige krav under nogle overordnede pains. Ved at koble disse pains til produktets hovedbrugerrolles arbejdsgange og behov bliver det mere tydeligt, hvordan prioriteten kan være. Som med meget andet handler prioritering af krav om fravalg og begrænsning, og har man en tydelig forståelse og beskrivelse af de(n) typiske brugerrolle(r)s behov, øger man både chancen for produktsucces, og hvor intuitiv selve processen med at prioritere kundekrav bliver.

Produktledelse >< topledelse

Efterhånden proklamerer enhver virksomhed med respekt for sig selv, at den er agil og kundevendt. Derfor har man selvfølgelig SCRUM-teams med udfarende Product Owners, så man kan lave det, 'kunden vil have'. Alligevel finder mange agile teams sig selv i en virkelighed, hvor det mere er chefen/direktøren/ledelsen, som tager beslutningen om produktets retning, end det er produktlederen (som det jo bør være). Men kan man egentligt gøre noget ved det?

Måske ikke fra én dag til den anden, men på den lidt længere bane er løsningen ret banal; affind dig indledningsvist med tingenes tilstand, men få vist ledelsen og dine interessenter, at du som produktleder er i stand til at levere og få gjort produktet til en succes - hvorved du bliver en succes. Dermed får ledelsen tillid til dig og dine evner som produktleder, og de vil (læs: bør) trække sig fra at micro-manage produktudviklingen og overlade mere og mere til dig. Ingen får et stort ansvar, og specielt ikke soloansvaret for retningen på et softwareprodukt, bare pga. jobtitlen alene - kommer resultaterne, kommer ansvaret og tilliden til at træffe selvstændige beslutninger helt af sig selv.

Efterspørgsel >< hypotese

Bør man lave det, kunderne direkte efterspørger, eller skal man prøve at forudsige deres fremtidige behov? Den "sikre" vej er selvfølgelig at finde tilstrækkelige forskellige kunder, der uafhængigt af hinanden vil have en bestemt funktionalitet (hvis den passer ind i produktstrategien). I takt med, at man som produktleder bliver skarpere på produktets hovedbrugerroller, kundernes arbejdsgange og pains, samt hvilken funktionalitet der bliver brugt mest, bliver man i bedre og bedre stand til at komme med kvalificerede hypoteser om kundernes uudtrykte behov. Jo bedre man lærer produktets brugere at kende, desto nemmere bliver det at komme med kvalificerede hypoteser om, hvilken retning produktet bør tage.

Dette er dermed reelt ikke et dilemma, men et mål, man bør sigte efter; i stedet for reaktivt at lave det, kunderne eksplicit efterspørger, bør man stræbe efter en mere proaktiv tilgang til nye features via målbare hypoteser - og opdatere sin Definition of Done til først at være opnået, når den nye feature rent faktisk er blevet benyttet af brugeren (som man kender det fra 'hypothesis-driven development).

Ovenstående var mine bud på, hvordan man kan håndtere nogle af de interessante dilemmaer/problemstillinger, man kan støde på som produktleder - hvilke sidder du med, og hvordan løser du dem?

Relateret indhold

Luxshan Ratnaravis billede

Kommentarer (1)

Therese Hansen

Gode problemstillinger du tager op - jeg sidder dagligt og modtager input fra vores brugere og forsøger at omsætte det til et sammenhængende roadmap, som også tager faktiske data om hvordan det nuværende produkt bliver brugt, vores vision for produktet og nytænkning ind i ligningen. Det er en kunst - og en fantastisk sjov opgave.

Vi laver et lille hverdagsværktøj, hvor visionen er at blive vores brugeres "forside til internettet" og på grund af typen af vores produkt, har jeg en opgave som overskygger alle de andre; dogfooding. Hvis ikke jeg selv har lyst til at bruge produktet som det første hver dag, så er der stadig lang vej til succes. At jeg bruger produktet meget gør også, at jeg ser nogen fejl og mangler før de når vores brugere + at jeg har en føling med produktet, som gør det nemmere at kommunikere om produktet med "andre brugere" + vurdere vigtigheden af det input der kommer fra vores brugere, fordi jeg har føling med hvor ofte et brugsscenarie/en fejl opstår og om det er centralt for brugeroplevelsen eller en edgecase.

Det er naturligvis ikke alle "produktledere" der har et produkt som egner sig godt til daglig dogfooding, men hvis man har, så er det en yderst vigtig del af arbejdet som "produktleder".

Log ind eller opret en konto for at skrive kommentarer