Product Owner

En product owner er bindeled mellem forretningen og udviklerne. Rollen kaldes også IT-product owner eller IT-produktejer. Personen bestemmer rækkefølgen: hvad bygger teamet i næste sprint, og hvad venter.

Det vigtigste værktøj er backloggen. Det er den prioriterede liste over alt, teamet kunne lave. Product owneren ejer den liste alene. Alle andre kan foreslå, men kun én bestemmer rækkefølgen.

Typiske opgaver

• Skrive brugerhistorier med accepterkriterier, så udviklerne ved, hvornår noget er færdigt.
• Prioritere backloggen løbende ud fra værdi, risiko og afhængigheder.
• Holde refinement med teamet, hvor opgaver bliver skåret mindre og estimeret.
• Deltage i sprintplanlægning og sætte målet for sprintet.
• Godkende eller afvise løsninger ved sprint review.
• Sige nej til stakeholders, der vil have deres ønske ind uden om listen.
• Beslutte, om en fejl skal rettes nu eller senere.
• Teste nye funktioner i testmiljøet, før de går i produktion.
• Holde roadmap opdateret og forklare ledelsen, hvorfor noget er udskudt.
• Måle om det, der blev bygget, faktisk bliver brugt.

En almindelig arbejdsdag
Dagen starter med daily standup klokken kvart over ni. Femten minutter, hvor teamet fortæller, hvad der blokerer. Derefter en time med refinement, hvor tre historier bliver skrevet færdige.

Midt på formiddagen kommer en afdelingschef med et hasteønske. Product owneren skriver det ned, men lover ingenting. Frokost. Om eftermiddagen er der møde med kundeservice om de fejl, brugerne ringer om.

Resten af dagen går med at skrive accepterkriterier og svare udviklere på Slack eller Teams. Mange spørgsmål lyder: hvad skal der ske, hvis brugeren gør sådan her? Product owneren skal kunne svare med det samme.

Hvor arbejder en product owner
Rollen findes overalt, hvor der udvikles software løbende. I Danmark er de største aftagere banker og pensionsselskaber, softwarehuse, teleselskaber, detailkæder med webshop og produktionsvirksomheder med digitale produkter.

Det offentlige har mange IT-produktejere. Kommuner, regioner, styrelser og fælleskommunale selskaber bruger titlen om den, der ejer et fagsystem. Her er en stor del af arbejdet leverandørstyring, fordi udviklerne sidder hos en ekstern leverandør.

Konsulenthuse udlejer også product ownere til kunder. Så hedder man ofte proxy product owner og har mindre mandat.

Regler der styrer prioriteringen
En product owner skriver ikke jura, men skal kende de krav, der binder produktet. Behandling af persondata i en ny funktion skal have et grundlag efter GDPR, og Datatilsynet forventer, at det er tænkt ind fra start, ikke bagefter. Offentlige websteder og apps skal leve op til webtilgængelighedsloven, hvor Digitaliseringsstyrelsen fører tilsyn. Private virksomheder inden for blandt andet e-handel, bank og transport er omfattet af tilgængelighedskravene i EU's tilgængelighedsdirektiv, som i Danmark er gennemført i lov om tilgængelighedskrav for produkter og tjenester. Bygger produktet på AI, sætter EU's AI-forordning krav til dokumentation og risikovurdering.

De krav kan ikke prioriteres væk. Det er derfor, de bør stå i accepterkriterierne og ikke i et notat, ingen læser.

Det man sjældent hører i opslaget
En product owner bestemmer meget lidt over mennesker. Der er typisk intet personaleansvar. Magten ligger i rækkefølgen på en liste og i at kunne forklare den.

En stor del af jobbet er at skuffe folk høfligt. Der er altid flere ønsker end kapacitet.

Der findes ingen dansk uddannelse, der hedder product owner. De fleste kommer ind via et andet job i eller tæt på et udviklingsteam.

Almindelige uddannelsesbaggrunde

• Cand.merc.it, cand.it i digitalisering eller informationsvidenskab. Fem år i alt.
• Datalogi eller softwareudvikling, fx datamatiker på to år eller diplomingeniør i softwareteknologi.
• HA eller cand.merc. i strategi, marketing eller innovation.
• Kommunikation, medievidenskab eller design, især til kundevendte produkter.

Adgangskrav følger den valgte uddannelse. Til datamatiker kræves typisk en gymnasial eksamen med matematik på mindst C-niveau eller en relevant erhvervsuddannelse.

De almindeligste veje ind

• Fra supporter eller superbruger, der kender systemet og brugerne bedst.
• Fra tester, som allerede læser krav og finder hullerne i dem.
• Fra business analyst eller kravspecialist.
• Fra udvikler, der gerne vil tættere på beslutningerne.
• Fra projektleder, når organisationen skifter til agilt arbejde.
• Fra en fagperson i forretningen, fx en sagsbehandler, der bliver IT-produktejer for sit eget fagsystem.

Den sidste vej er meget almindelig i det offentlige. Man kender arbejdsgangen, og resten lærer man undervejs.

Certificeringer
De tæller i ansøgninger, men erstatter ikke erfaring. De tre mest udbredte er:

• Certified Scrum Product Owner (CSPO) fra Scrum Alliance. To dages kursus.
• Professional Scrum Product Owner (PSPO I og II) fra Scrum.org. Kan tages som ren eksamen uden kursus.
• SAFe Product Owner/Product Manager (POPM) fra Scaled Agile. Bruges i store organisationer med mange teams.

Rollen er defineret i The Scrum Guide, som Scrum.org og Scrum Alliance udgiver sammen. Den er kort og gratis. Læs den, før du går til samtale.

Hvad arbejdsgivere reelt kigger efter

• At du kan skrive en brugerhistorie, en fremmed forstår.
• At du kan forklare en prioritering, du har truffet, og hvad du fravalgte.
• At du kan tale med udviklere uden at kode selv.
• At du kender domænet, fx bank, sundhed, logistik eller forsikring.

Domæneviden vejer ofte tungere end certifikatet. En product owner i en bank skal forstå hvidvaskregler og betalingsflow. Det lærer man ikke på to dage.

Karriereveje videre
En typisk rute er product owner, senior product owner og derefter product manager. Product manageren arbejder mere med marked, forretningsmodel og roadmap på længere sigt.

Derefter kan det gå mod Head of Product eller Chief Product Officer. Andre skifter til agil coach, til leverandørstyring eller bliver selvstændige konsulenter. Nogle går tilbage til projektledelse, hvis de savner at styre en hel leverance.

Product owneren skriver, prioriterer og måler. Værktøjerne følger de tre ting.

Backlog og opgavestyring
Jira er langt det mest udbredte. Azure DevOps bruges i virksomheder, der kører på Microsoft-stakken. Nogle mindre teams bruger Trello, Linear eller Asana. I opslag står Jira næsten altid nævnt ved navn.

Du skal kunne mere end at oprette en opgave. Du skal kunne bygge et board, sætte filtre op og trække et burndown eller velocity-diagram frem til et statusmøde.

Dokumentation
Confluence hænger sammen med Jira og bruges til krav, referater og beslutninger. Notion og SharePoint ses også. Pointen er at kunne finde tilbage til, hvorfor noget blev besluttet.

Design og brugerinddragelse
Figma til at se og kommentere design, før det bygges. Miro eller FigJam til workshops, story mapping og flowdiagrammer. Product owneren tegner sjældent selv, men skal kunne læse et prototypeflow og finde de tilfælde, designeren har glemt.

Data og måling
Google Analytics 4, Amplitude eller Mixpanel til at se, om en ny funktion bliver brugt. Hotjar til optagelser af brugeradfærd. Power BI eller Tableau til rapporter til ledelsen.

Grundlæggende SQL er en stor fordel. Kan du selv trække et tal, behøver du ikke vente tre dage på en dataanalytiker.

Produktstyring i det store
Productboard, Aha! eller Jira Product Discovery bruges til roadmap og til at samle ønsker fra kunder. Ses mest i softwarehuse med mange kunder.

Teknisk berøring
Postman til at se, hvad en API faktisk svarer. Adgang til testmiljø og til logværktøjer som Kibana eller Grafana. Feature flags i LaunchDarkly eller lignende, så en funktion kan slås til for få brugere først.

Kommunikation
Slack eller Microsoft Teams hele dagen. PowerPoint til styregruppen. Meget af jobbet er korte skriftlige svar, der fjerner tvivl hos en udvikler med det samme.