Tuotteen omistaja ja tuotepäällikkö – kaksi roolia
Näyttää siltä, kuten muun muassa Google-hakujen tilastot osoittavat, että monet käyttäjät ovat erittäin kiinnostuneita siitä, mitä pätevyyksiä tuotteen omistajalla tulisi olla ja mitä tehtäviä hänellä on. Tärkeää on, että kyselyt esitetään usein tietyssä yhteydessä – näyttää siltä, että ketterän ketteryyden täysimääräisessä hyödyntämisessä vaikeutena on tuotepäällikön ja tuoteomistajan tehtävien erottaminen toisistaan.
Google Trendsin viiden viime vuoden aikana antamien esimerkkitietojen perusteella ketteryyden yleistyminen ei ole vaikuttanut PO:n ja PM:n välisen tietoisuuden lisääntymiseen. Lisäksi asiaa koskeva huomio on edelleen kasvussa.
Lisäksi kyselyt, jotka koskevat tiettyjä rooleja ketterässä toiminnassa, ovat kasvussa. Tällöin voidaan myös tehdä se johtopäätös, että monissa yrityksissä nykyiset toteutukset eivät olleet riittäviä erottelemaan molempia rooleja koskevia osaamisalueita ja -alueita, tai ne eivät ottaneet niitä käyttöön lainkaan. Edellä mainitut seikat voivat yksinkertaisesti johtaa tilanteeseen, jossa organisaatio voi toki ”demonstroida” trendikkään ketterän metodologian käyttöönottoa, mutta se on kaukana siitä, että se saisi tästä käyttöönotosta täyttä hyötyä. Ei ole vaikea kuvitella viestintäkaaosta ja organisoinnin puutetta, joka liittyy toimivaltuuksien moninkertaistumiseen ja jatkuvaan prosessiin, jossa tuotepäällikkö ja tuoteomistaja joutuvat tielle. Miten estää it-projektin epäonnistuminen?
Mikä on tuoteomistaja vs. tuotepäällikkö?
Miten siis selittää näiden kahden roolin ero mutkattomasti? Kannattaa kääntää huomio siihen, mihin sekä tuotepäällikön että tuoteomistajan huomion tulisi kohdistua. Ensimmäisessä tapauksessa rooli keskittyy ensisijaisesti suhteeseen organisaation ulkopuolisiin keskuksiin. Juuri tuotepäällikön tulisi keskittyä markkinatilanteen valvontaan sekä ensisijaisesti asiakkaiden ja heidän tarpeidensa tuntemiseen. Tuotepäällikön olisi ensisijaisesti opittava asiakkaan oletukset tuotteesta tai tietyistä markkinoiden tarpeista ja välitettävä ne organisaation sisällä. Voidaan sanoa, että tässä yhteydessä hän on tietolähde, josta saadaan tietoa dynaamisesti muuttuvista ulkoisista olosuhteista ja asiakkaiden odotuksista (ottaen luonnollisesti erityisesti huomioon näiden odotusten muutokset), jotka sitten siirretään organisaatioon.
Ei kuitenkaan pidä missään nimessä olettaa, että tuoteomistaja ja tuotepäällikkö ovat jossain määrin vastakkain, mikä johtaa siihen, että tuotepäällikön on pakko viestiä organisaation toiminnoista ulospäin. Päinvastoin, hänen tehtävänään on varmistaa asianmukainen yhteistyö projektiryhmän kanssa sekä laadunvarmistus. Kun ketterässä järjestelmässä tuotepäällikkö hankkii ulkoisia tietoja, tuoteomistaja jakaa ne mahdollisimman optimaalisella tavalla organisaation sisällä, erityisesti prosessiin osallistumaan nimetyille työntekijöille. Näin ollen ei voida puhua mistään rinnakkaisesta toiminnasta, vaan yhteistyön tai jopa tiedon ristikkäisen läpäisyn välttämättömyydestä. Voidaan jopa sanoa, että projektipäällikkö ja projektin omistaja luovat yhdessä yhtä prosessia – ulkoisia tekijöitä koskevien tietojen pohjalta he kohtaavat pisteessä, jossa tiedon on saavuttava organisaation jäsenille.
Mikä on PO:n ja PM:n välinen suhde?
Edellä mainituissa käsitteissä voi olla tiettyä vaaraa – toisaalta puhutaan tilanteen välttämisestä, jossa osaamiset ovat päällekkäisiä, ja toisaalta niiden keskinäisestä päällekkäisyydestä. Se ei ole erehdys – tuotteen omistajan ja tuotepäällikön välinen suhde sekä niiden välisen viestinnän suunnat ovat ristikkäisiä. Jotta tuoteomistaja voi hankkia arvokasta tietoa ulkopuolelta, hänen on tunnettava tiimi ja sen kyvyt. Samoin tuotepäälliköllä on oltava tietoa markkinatilanteesta ja asiakkaan odotuksista, jotta hän voi kommunikoida tehokkaasti projektiryhmien kanssa ja varmistaa lopputuotteen asianmukaisen laatutason.
Melissa Perri, kokenut tuotepäällikkö ja Harvard Business Schoolin vanhempi luennoitsija, on jakanut aiheesta mielenkiintoisen mielipiteen: ”On tärkeää, että tiimin koon suhteen on joustavuutta myös tuotteen vaiheen mukaan. Jos annat tuotepäällikölle suuren scrum-tiimin backlogin täytettäväksi, kun olet discovery-tilassa, hän pitää backlogin täytettynä. Hän joutuu kuitenkin myös olemaan kahden vaiheilla: pitääkö hän työnkulun kehittäjille ja yrittääkö hän tehdä työtä suunnan validoimiseksi. Tämän seurauksena kumpaakaan ei saada tehtyä hyvin. Jos haluat rakentaa tuotteita, esim. ohjelmistotuotekehitystä, jotka luovat arvoa yrityksellesi ja asiakkaillesi, tarvitset yrityksessäsi hyvän tuotehallinnan perustan. Jos haluat, että työntekijäsi voivat edetä urallaan, sinun on annettava heille tämä perusta, jotta he voivat kasvaa ylempiin tehtäviin. Muistuta siis työntekijöitäsi siitä, että he kaikki ovat tuotepäälliköitä. Useimmiten he saattavat olla tuoteomistajan roolissa Scrum-tiimissä, mutta heidän on silti ajateltava tuotepäällikön tavoin ja varmistettava, että rakennamme oikeita asioita”.
Nämä hienovaraiset yhteyksien ja riippuvuuksien säikeet voidaan siis tiivistää toteamukseen, jonka mukaan tuotepäällikkö luotaa hankkeita, joihin organisaation tulisi osallistua, ja tuoteomistaja työskentelee tiimin kanssa niiden kehittämiseksi. Tällaisesta näkökulmasta käsin voidaan puhua terveistä, vankoista ja tehokkaista suhteista, jotka ovat ketterän menetelmän mukaisia.