En Product Owner sin teknisk bakgrunn er ikke et problem. Deres mangel på produktvisjon er. Se 5 tips for nybegynnere Product Owners.
Skjønnheten ved å jobbe i IT-bransjen er at du tar på deg nye utfordringer stort sett hver dag. Imidlertid var det ganske skremmende for meg, en person som har jobbet med kommunikasjon i mesteparten av min karriere, å ta på meg rollen som Product Owner i en digital produktutviklingsprosess.
Jeg er leder for markedsføring uten reell teknisk bakgrunn. Så det har alltid fått meg til å undre—er det virkelig så stor forskjell mellom en teknisk og en ikke-teknisk Product Owner? Basert på min nylige erfaring og noen diskusjoner jeg hadde med programvareutviklere i teamet vårt, har jeg bestemt meg for å samle noen tips for folk som kan befinne seg i en lignende situasjon.
5 tips for nye og ikke-tekniske Product Owners
Den tekniske fordelen trenger ikke å være urettferdig
Det er ingen vits i å late som det ikke er noen forskjell mellom en Product Owner med og uten teknisk bakgrunn.
Tekniske Product Owners har en fordel når det gjelder å kommunisere med utviklingsteamet eller være en proxy mellom det interne teamet og den eksterne tjenesteleverandøren. De forstår tekniske nyanser og er i stand til å presentere løsninger og lage brukerhistorier. Å sette akseptansekriterier er en naturlig prosess for dem.
Utviklerne jeg har diskutert dette med sier at selv om de kan se forskjellen mellom å jobbe med tekniske og ikke-tekniske Product Owners, er det ikke automatisk et problem.
Det som er avgjørende i en Product Owners rolle er at:
- De har en klar visjon for produktet.
- De er besluttsomme og fokuserte.
- De har motivasjon.
Ha en klar visjon for produktet ditt
Å ha en klar visjon for et produkt er nøkkelen til en mye smidigere utviklingsprosess. Å forstå behovene til brukerne og kundene dine, ha spesifikke mål i tankene - alt dette gjør prosessen med å ta de riktige design- og utviklingsbeslutningene uendelig enklere. Det er utrolig vanskelig å lage brukerhistorier og prioritere funksjoner uten å vite hva vi faktisk ønsker å oppnå.
Du må holde målet i tankene gjennom hele prosessen. Hva er formålet med denne komponenten? Hva er fordelen for brukeren? Hvis du ikke er sikker på hvordan du skal komme dit - det er greit, det er derfor du har ansatt et dyktig team. Men hvis du ikke kjenner målet bak en funksjon, kan det bli et problem. Du er den som er ansvarlig for forretningsmålene til løsningen din.
Det er alltid bra å starte med ditt gode gamle “HVORFOR?” og “HVA?”. Det vil gjøre utviklingsprosessen til bare om “HVORDAN?”. Og for å finne ut av dem vil du ha støtten fra et helt utviklingsteam. Sammen vil dere kunne finne den beste fungerende løsningen.
For å klargjøre visjonen, kan du starte med en Product Design Workshop som vil hjelpe deg med å organisere hele utviklingsprosessen. Det kan også hjelpe deg med å unngå fallgruven av å planlegge for mange oppgaver på en gang eller prioritere for mange funksjoner for den første utgivelsen.
Ikke vær redd for å ta en beslutning
Hvis du vil at arbeidet skal gå smidig, husk at du må være personen som tar den endelige avgjørelsen. Ikke la det være opp til utviklerne å bestemme når funksjonen er klar. Du er den som kjenner behovene produktet må oppfylle. Utviklerne er vanligvis en gjeng smarte mennesker—noe som ofte betyr at de kan ha en tendens til å overkomplisere ting. Det er fordi de ønsker at funksjonaliteten skal dekke alle mulige bruksområder. Din rolle er å kutte dette kort da du ikke vil ende opp med en overkomplisert funksjon.
Når du jobber med et utviklingsbyrå, er det også nyttig å innse at du ikke bestiller et ferdig digitalt produkt—det er ikke en butikk. Du bestiller arbeid fra et dyktig team som vil gjøre alt de kan for å lage et produkt du har kommet opp med. Men det er ikke slik at det er klart. Det må utvikles. Og bare en produktleder har den nødvendige kunnskapen om hvordan produktet vil bli håndtert (go-to-market strategi, videre utviklingsplaner, et team som vil være ansvarlig for produktet internt, brukere, osv.). Derfor må PO være personen som tar de endelige beslutningene.
“Skriv et motiverende sitat her”
Produktlederen må være motivert for å finne de mest optimale løsningene, og du kan være den personen selv uten teknisk bakgrunn. Men bare hvis du kjenner brukerne dine og virkelig tror på verdien produktet ditt kan tilføre livene deres.
Det er viktig å være til stede, ikke la utviklingsteamet stå alene, fordi det gir mye rom for spekulasjoner om hva som skulle leveres. Du vil ikke at teamet skal miste forretningskonteksten for arbeidet sitt. Det er din rolle å spesifisere hva som må leveres og beskrive akseptkriteriene. Ellers kan det hende du ikke får det du har forventet. La oss ta en oppgave som et “innloggingspanel”: vil du at brukeren skal kunne logge inn via sosiale medier? Hvilke? Eller skal det være kun e-post? Du skjønner poenget.
Still spørsmål
Jeg ble overrasket over hvor mye man kan plukke opp bare ved å lytte til en diskusjon i et teknisk team. Men jeg har lært enda mer ved å stille direkte spørsmål. “Er det mulig å…?”, “Hva er forskjellen mellom…?” — Jeg tror jeg har stilt det spørsmålet hundre ganger i løpet av utviklingsprosessen og har ingen anger på det. Var det irriterende? Kanskje. Var det nødvendig og nyttig til slutt? Absolutt. Tross alt var det den eneste måten å sikre vår gjensidige forståelse på, og også et flott verktøy for å bygge tillit. Teamet visste at hvis jeg ikke forsto noe, ville jeg spørre om det i stedet for å nikke og late som om alt var klart (noe som kunne skape problemer senere i prosessen).
Å være en Product Owner - avsluttende tanker
Å være en Product Owner er en ansvarlig jobb, men en veldig tilfredsstillende en. Mitt siste råd ville være dette: kom forberedt, kjenn din visjon, og ikke stress. Med det rette teamet ved din side, er du klar for et stort eventyr. Og et flott fungerende produkt ved målstreken.
Sjekk også
