Hva er en god produkteier?

Flere av oss som jobber i Kantega har både jobbet som produkteiere, og vært leid inn for å støtte produkteiere. Noen ganger lurer kunder som har lite erfaring med smidig utvikling på hva som kreves av produkteieren, både med tanke på kapasitet og kompetanse. Dette er et viktig spørsmål, fordi produkteieren spiller en sentral rolle i et smidig utviklingsteam. 

Hva er egentlig produkteierens rolle?

Målet med denne artikkelen er ikke å definere produkteierbegrepet på nytt. Digitaliseringsdirektoratets prosjektveiviser og Scaled Agile Framework er eksempler på mer eller mindre presise definisjoner av ansvaret og oppgavene til en produkteier. I prosjektveiviseren beskrives ansvaret slik:

• Ansvarlig for at prosjektets leveringsomfang er utformet og beskrevet i form av en prioritert liste med produkter beskrevet som brukerhistorier (produktkø)
• Ansvarlig for kontinuerlig vedlikehold av produktkøen gjennom detaljering og forfining av de produktelementer som til enhver tid har høyest prioritert og klar for utvikling i neste sprint
• Ansvarlig for analyse og videre behandling av omfangsrelaterte endringsforslag”

Heldigvis ligger realitetene ofte gjerne et stykke unna slike definisjoner. I praksis er det stor variasjon på hva produkteieren må håndtere av ansvar, og hvordan. En smidig (“agil”) tilnærming (se The Agile Manifesto) innebærer at et team alltid vil se etter bedre måter å jobbe sammen på. Det betyr at forventingene til produkteierrollen bør avklares tidlig i et prosjekt, og at rollen kan og bør endre seg når teamet lærer noe nytt. For å svare mest mulig presist på hva som kreves av produkteieren, kan det være nyttig å forstå sammenhengen produkteieren skal utøve rollen innenfor.

Uforutsigbarhet

Hva som kreves av produkteieren avhenger blant annet av hvor mye forutsigbarhet vi har i utvikling av løsningen. Når sluttresultatet er ukjent og rammevilkårene stadig endrer seg, har vi lav forutsigbarhet. Er det for eksempel mulig å beskrive løsningen på forhånd, eller finnes det flere mulige alternative løsninger?

Det kan også hende at rammevilkårene er uforutsigbare, for eksempel ved at målene endrer seg, eller at de økonomiske rammene (og dermed kapasiteten) endrer seg.

De fleste IT-prosjekter er per definisjon uforutsigbare. En produkteier må altså forvente å håndtere mye uforutsigbarhet. Dette kan for eksempel handle om uforutsigbarhet i mottak av produktet. Ved å sørge for å få tilbakemeldinger fra kunder og brukere underveis, kan vi redusere risikoen for at kundene ikke vil benytte eller kjøpe produktet. I slike tilfeller kan som regel ikke produkteier bare prioritere blant eksisterende oppgaver i produktkøen, fordi vi må anta at endrede betingelser gjør en del av de opprinnelige antakelsene utdaterte. Et annet eksempel er at eksterne faktorer som marked eller underliggende teknologi endrer seg. Da må produkteier vurdere i hvilken grad dette påvirker oppgavene i produktkøen.

Kompleksitet

Vi står alltid overfor kompleksitet når vi utvikler IT-løsninger, men hvor mye en har av det varierer – kompleksitet er relativt. Kompleksitet kan, om vi forenkler litt, være knyttet både til teknologi og organisasjon. I begge tilfeller avhenger kompleksiteten av antall komponenter og avhengighetene mellom disse. Kompleksiteten vi har i organisasjoner er den dimensjonen som er mest interessant å drøfte for produkteierrollen. Forenklet sagt kan vi si at folk med selvstendige viljer fører til kompleksitet. Desto mer samarbeid som kreves for å løse et problem, og desto flere som må bidra eller har innflytelse, jo mer kompleksitet har vi.

For eksempel: Løsningen kan kreve mer eller mindre samarbeid for å løse tekniske utfordringer. Jo mer samarbeid som kreves, jo mer komplekst blir samarbeidet i teamet. En annen faktor som påvirker kompleksiteten er blant annet hvor mange interessenter som må håndteres, og hvor enige eller uenige de er, og hvor mange andre aktører (for eksempel eksterne leverandører) prosjektet/teamet er avhengig av.

Et viktig spørsmål en produkteier bør stille tidlig er hvor lett det er å få tilgang til sluttbrukere og interessenter, og hvor tett det kan jobbes på utviklingsteamet. Jo mer kompleksitet, desto viktigere er det for produkteier å samarbeide nært med teamet og til å kommunisere med interessenter.

I praksis betyr dette for eksempel at det stilles helt andre krav til en produkteier i en liten startup (lav forutsigbarhet, lav kompleksitet), enn til en produkteier som forvalter etablerte løsninger i en større virksomhet med mange interessenter (høy forutsigbarhet, høy kompleksitet). Dette er nærmere forklart senere, for deg som er interessert i å følge argumentasjonsrekka litt lenger.

Hva er en god produkteier?

Går det an å si noe generelt om hva som kjennetegner en god produkteier, til tross for at rollen bør tilpasses sammenhengen? Dette vil det selvsagt være mange meninger om. Disse stikkordene oppsummerer noen av innspill fra et faggruppemøtet for teamledelse i Kantega, hvor tema var produkteierrollen:

• Har god forretningsforståelse
• Skaper engasjement​
• Kan litt om brukerinnsikt​
• Er en del av teamet
• Diskuterer problemer sammen med teamet
• Deler kunnskap med teamet
• Vet ikke best selv, men kan være en som beslutter
• Opptatt av markedet og brukerne ​
• Forstår interessentene
• Håndterer forstyrrelser, filtrerer det som kommer eksternt fra
• Er streng på at forespørsler skal via produkteier
• God på delegering
• Tar del i strategiske og taktiske beslutninger

Da du leste gjennom lista så du kanskje at noen mener at produkteiere som beskytter teamet fra kompleksitet er gode produkteiere (håndterer forstyrrelser, tar imot forespørsler på vegne av teamet). Produkteieren kan velge å beskytte seg selv og teamet fra kompleksiteten ved å «sette foten» i døra for interessentene, men jeg har sett flere eksempler på at dette i praksis betyr å skyve utfordringene foran seg. Derfor tror jeg det det er smartere å se interessentene som en ressurs, heller enn et problem.

Men i noen sammenhenger kan dette likevel være riktig, under de rette rammebetingelsene. For eksempel dersom man har lite uforutsigbarhet, og mye kompleksitet. Spørsmålet er hvordan filtreringen skjer, og hva produkteieren gjør når noe filtreres. Involveres interessentene av produkteieren? Er det tilstrekkelig for teamet å kjenne til den filtrerte informasjonen, eller går informasjon som er viktig tapt underveis? Her finnes det selvsagt ingen fasit, men det er viktig å reflektere over ulemper og fordeler med hvordan du velger å utøve produkteierrollen.

Hva som kan påvirke ansvaret produkteier bør ta

Resten av artikkelen går litt mer i dybden på faktorer som kan påvirke hva som kreves av en produkteier, og hvilken rolle man kan eller bør ta. Jeg vil gjøre et forsøk på å beskrive dette ved å trekke opp noen dimensjoner fra Albert Boonstra og Cees Reezigts “Complexity-Predictability Project Diagnosis model”. I denne artikkelen antas det at måten et prosjekt bør ledes på avhenger av hvor prosjektet befinner seg langs to dimensjoner: Grad av forutsigbarhet, og grad av kompleksitet. Og da er tankerekken at dersom man antar at prosjekter bør ledes på ulike måter, så bør det også være variasjon i rollene og ansvaret den enkelte kan og bør ta – og det gjelder også produkteieren.

Boonstra og Reezigt forklarer de to dimensjonene gjennom tre egenskaper: Innholdet i prosjektet, og den indre og ytre konteksten (sammenhengen, eller miljøet) prosjektet gjennomføres innenfor.

Grad av forutsigbarhet

Den første dimensjonen handler om forutsigbarhet. Vi har, som nevnt tidligere, lav forutsigbarhet i situasjoner hvor sluttresultatet er ukjent og hvor rammevilkårene stadig endrer seg.

Når forutsigbarheten er høy er de organisasjonelle, funksjonelle og tekniske kravene tydelige og avklart (altså er innholdet forutsigbart). Interessentene er godt kjent med kravene, nødvendige ressurser er på plass og det finnes få avhengigheter utenfor produkt- eller prosjektorganisasjonen (den interne og eksterne konteksten er altså forutsigbar).

Når vi har lav forutsigbarhet kan målene være utydelige og i endring som en konsekvens av interne interessekamper, endring i rammebetingelser eller ny informasjon (for eksempel om ringvirkningene av prosjektet). Det kan også være uklart om de nødvendige ressursene er tilgjengelig, og kan i tillegg ha avhengigheter som teamet/prosjektet ikke har kontroll på. En har heller kanskje aldri utviklet en lignende løsning tidligere. 

Ved høy forutsigbarhet forventes ikke store overraskelser, mens de bør forventes ved lav forutsigbarhet.

Grad av kompleksitet

Den andre dimensjonen er graden av kompleksitet. Ved lav kompleksitet forholder vi oss til noen få og enkle komponenter og har få avhengigheter, og dette kan gjelde både teknisk og organisatorisk. Avgrensede tekniske utfordringer (eller “innholdet” i prosjektet) kan løses av en enkelt ekspert. Dersom innholdet har høy grad av kompleksitet er det beste at eksperter fra ulike fagdisipliner jobber sammen for å løse et problem.

Hvis vi tar utgangspunkt i det indre og ytre miljøet så er kompleksiteten lav når det er få interessentgrupper å forholde seg til, eller det er enighet mellom disse gruppene. Slike interessentgrupper kan være selve teamet, de kan finnes i egen organisasjon eller hos kunden eller leverandører. Når kompleksiteten er høy kan prosjektet forårsake konflikt mellom noen av disse gruppene, for eksempel om mål eller prioriteringer.

Hvordan lede prosjekter innenfor disse dimensjonene?

Basert på disse to dimensjonene beskriver Boonstra og Reezigt fire typer prosjekter karakterisert ved hvor de ligger langs de ulike dimensjonene. Her er det viktig å merke seg at egenskapene ved et prosjekt kan endre seg, ved at det får mer eller mindre forutsigbarhet eller kompleksitet, noe som igjen krever fleksibilitet med hensyn til hvordan prosjektet ledes.

Designprosjekter (noe jeg tror må leses som «prosjekter som kan planlegges og designes") har mye forutsigbarhet, det er lite uenighet og det finnes nok ressurser til å nå målene man er blitt enig om. I teknologiprosjekter handler dette om å få kjent teknologi til å fungere. Et eksempel er implementering av etablerte ERP-løsninger i nye virksomheter. Prosjektet er toppstyrt og deltakerne vet hva som forventes av dem. Tydelige prosjektstrukturer er på plass. Aktiviteter planlegges nøye og følges opp tett og strukturert. Prosjektet måles gjerne både på tid, kostnad og scope.

Forhandlings- og ekspertise-prosjekter har også mye forutsigbarhet, samtidig som det er høy grad av teknisk kompleksitet og sprikende meninger blant interessentene (eksempelvis om målsettinger og prioriteringer). Et eksempel på denne typen prosjekt er innføring av selvkjørende tog (hvor en har forutsigbarhet fordi løsningen kan beskrives på forhånd). Å forhandle fram enighet gjennom involvering av sentrale interessenter er en viktig oppgave for prosjektet, enten ved å kartlegge og gjøre avklaringer på forhånd, eller sørge for at det finnes rom for håndtering av sprikende interesser underveis. 

Utviklingsprosjekter kjennetegnes ved lite forutsigbarhet, og lite kompleksitet. Et eksempel er et prosjekt hvor medisinsk personell utvikler et system for medisinsk diagnostisering, støttet av AI-ekspertise. I slike prosjekter er det tydelige mål, og et godt og nært samarbeid på tvers av fagdisipliner (altså lav kompleksitet). Fordi sluttproduktet er uforutsigbart (det kan ikke beskrives på forhånd) legges det vekt på læring og eksperimentering, og det leveres konkrete resultater ofte etter modeller fra smidig utvikling (f.eks. ved å arbeide i sprinter).

Utviklings-, forhandlings- og ekspertiseprosjekter kjennetegnes av både lav forutsigbarhet og høy kompleksitet. Prosjektet er teknisk komplekst, uforutsigbart og en har sprikende interesser blant både interne og eksterne prosesser. Et eksempel på slike prosjekt er digitaliseringsprosessen mange mediehus har vært gjennom.

Produkteierens rolle i disse prosjekttypene

Egenskapene til et prosjekt kan endre seg over tid, noe som kan endre rollene og kravene til produkteieren. For eksempel fra å arbeide i en startup som over tid utvikler seg til en større og mer kompleks organisasjon, samtidig som produktet stadig blir mer forutsigbart. Flere andre faktorer kan også virke inn, for eksempel vil ansvaret og arbeidshverdagen til en produkteier i et team med stor grad av autonomi, hvor produkteieren har rom for å ta raske beslutninger, fortone seg annerledes enn i en organisasjon som viser mindre tillit og i større grad detaljstyrer ovenfra. I en større organisasjon kan også produkteieren også enten velge å jobbe for at interessentene skal bli mer enig (ved å være en megler eller aller helst rådgiver), eller å være en dørvakt som beskytter teamet fra uenighetene.

Men ved å ta utgangspunkt i de fire prosjekttypene blir det mulig å se for fire ulike situasjoner som stiller ulike krav til produkteieren.

Designprosjekter: Forutsigbarheten både ved løsningen som skal utvikles, og planen for å realisere løsningen, tillater at produkteieren kan arbeide strukturert med kartlegging og detaljering og prioritering av behov og krav, og sørge for at resten av teamet har et godt grunnlag for å jobbe effektivt. Produkteieren deltar i sprintplanleggingsmøter, og ellers tilgjengelig for raske avklaringer med teamet. Fordi tydelige prosjektstrukturer er på plass, og forventningene er avklart, trenger ikke produkteieren bruke mye tid på involvering av interessentene, eller håndtere sprikende meninger om retning og prioriteringer.

Forhandlings- og ekspertise-prosjekter: Selv om alle i og rundt prosjektet har en felles forestilling om sluttresultatet (det selvkjørende toget), så er det ikke nødvendigvis enighet om den tekniske løsningen eller hvordan gå fram for å realisere den. For en produkteier er det ikke nødvendigvis veldig utfordrende å dokumentere brukerbehovene eller beskrive kravene, men det vil være uenighet om prioriteringer. I slike situasjoner kan produkteieren blir eksponert for sprikende interesser i organisasjonen, og da kan det være nødvendig å ta en aktiv rolle med tanke på å få involvert interessentene og avklaringene som er nødvendig for å kunne realisere løsningen på en effektiv måte. Eller: Stille seg «i døra» for å beskytte teamet (noe jeg personlig tror er et dårlig alternativ, blant annet fordi teamet går glipp av informasjon og innspill som kan ha stor verdi).

Utviklingsprosjekter: Uforutsigbarheten med tanke på løsningene skal lages fører til at produkteier ikke kan arbeide strukturert og metodisk med å beskrive og prioritere krav, på samme måte som i designprosjekter. I en slik sammenheng er det en fordel om produkteier bidrar til å utforske og eksperimentere seg fram til løsninger, som en del av et tverrfaglig utviklingsteam som involverer og tester på brukere eller kunder hyppig underveis. Min erfaring er at hva som står i backlogen er mindre viktig enn i prosjekter hvor løsningen er mer åpenbar, fordi teamet sammen opparbeider seg en felles forståelse av hva som skal lages, og fordi det finnes en forståelse for at en får læring underveis som tilsier at detaljerte krav er bortkastet. 

Utviklings-, forhandlings- og ekspertiseprosjekter: For en produkteier kan denne typen prosjekt være svært krevende, fordi det verken er en åpenbar løsning eller forutsigbare rammebetingelser, samtidig som interessentene har sprikende meninger om både målsettinger og prioriteringer. Produkteieren kan havne i en situasjon som både krever at hen involverer seg i arbeidet med å forme og beskrive den nye løsningen, samtidig som hen må involvere og gi råd til interessentene for å sikre at det gjøres gode prioriteringer. Med andre ord krever det at produkteieren må ha kapasitet og erfaring til å kunne sjonglere mange baller samtidig.

Produkteieren vs produktlederen

Kanskje spesielt for de to sistnevnte prosjekttypenes del kan det være hensiktsmessig å tenke produktorientert (noe som kan komme i konflikt med prosjekttankegangen), og at produkteieren også utøver produktledelse. Dette er et tema som mange andre også er opptatt av, men som det ikke er meningen å gå i dybden på her. En god start på som fersk produkteier er å forstå omgivelsene du skal jobbe innenfor, og forhåpentligvis har denne teksten gitt en pekepinn på hva som kreves i den situasjonen du befinner deg i. Lykke til!

Anbefalt lesning:

Complexity-Predictability Project Diagnosis model. Albert Boonstra, Cees Reezigt. https://www.researchgate.net/publication/338871262_Complexity-Predictability_Project_Diagnosis_model