Tuotepäällikön näkökulmaa tuotejohtamisen referenssimalliin käsiteltiin edellisessä blogissa. Tässä blogissa puhutaan siitä, miten tuoteomistaja voi käyttää uudistettua tuotejohtamisen talomallia hyödyksi.

Tuotepäällikkö ja tuoteomistaja ovat yhdessä tuoteorganisaation ytimessä. He ovat tuotejohtajia, joilla on molemmilla vastuuna tuotteen menestys. Tämän parivaljakon yhteistyö onkin ehdottoman tärkeää. Roolit voi hoitaa myös yksin, mutta usein voi olla kannattavaa jakaa vastuut kahdelle henkilölle. Tuotepäällikkö ottaa strategisemman, kauemmas katsovan, ja markkinoiden tarpeisiin keskittyvän roolin. Tuoteomistaja taas ottaa vastuun lähitulevaisuuden tekemisestä, backlogista ja sen priorisoinnista, ja tiiviistä yhteispuhelusta kehitystiimin kanssa.

Talomallista voi jokainen tuoteomistaja havaita omat vahvuudet ja heikkoudet. Malli auttaa myös muistuttamaan siitä, missä asioissa yhteistyö tuotepäällikön ja muiden sidosryhmien kanssa toimii hyvin, ja missä on puutteita. Jokaiselle löytyy varmasti mallista asioita, joihin pitää panostaa, mutta tässä seuraavassa on lista asioita, joihin tuoteomistajan kannattaa kohdistaa huomiota. 

Tuotevisio

Varsinainen tuotevision määrittely on usein tuotepäällikön vastuulla. Tuoteomistaja toki auttaa sen rakentamisessa ja pitämisessä päivitettynä. Mutta erityisesti tuoteomistaja voi auttaa siinä, että tuotevisio jalkautetaan kehitystiimin tietoon. Tuotevisio on usein useiden vuosien päähän katsova. Yksittäisen kehittäjän näkökulmasta juuri sillä hetkellä työn alla olevaa tikettiä voi olla hankala yhdistää suureelliseen vuosien päässä olevaan visioon. Tähän välille tarvitaan välietappeja. Tätä varten tuotejohtajien pitää yhdessä määrittää tuotetavoitteet.

Tuotetavoitteet

Tuotetavoitteet ovat muutaman kuukauden välein toistuvia välietappeja kohti tuotevisiota. Lähinnä oleva tuotetavoite on hyvin konkreettinen ja työn alla olevien tarinoiden yhdistäminen siihen on paljon helpompaa. Koska tuoteomistaja on paljon tuotepäällikköä lähempänä kehitystiimiä, lähimmän tuotetavoitteen määrittely onnistuu häneltä helpommin. Tuotepäällikkö voi hahmotella tavoitteiden seuraavia askelia, koska niistä löytyy linkit roadmapiin. Lähimmät kaksi tuotetavoitetta taas ovat yhteydessä backlogiin.

Sprinttitavoitteet

Sprinttitavoitteet ovat aivan liian vähän käytetty ketterän toimintatavan osa. Niiden käyttö koetaan usein hankalaksi. Väitän, että suuri osa sprinttitavoitteiden käytön hankaluudesta johtuu siitä, että tuotetavoitteet puuttuvat. Sprinttitavoitteet pitäisi nimenomaan johtaa tuotetavoitteista. Sprinttitavoitteiden määrittely on ketterän tiimin vastuulla. Scrum tiimiin kuuluu Scrum Master, tuoteomistaja ja tiimi itse. Sprinttitavoiteet määritellään sprinttiä suunniteltaessa yhteisesti. Tavoiteasentantaan voi kuitenkin tuoteomistaja vaikuttaa.

Tuotevisiota, tuotetavoitteita ja sprinttitavoitteita kutsutaan yhteisnimellä tavoitehierarkia. Hierarkia pitää olla kunnossa, jotta ketterä tekeminen on mahdollista saada toimimaan tehokkaasti. Tuoteomistaja voikin ottaa vastuulleen tuotejohtamisen talon “portaikossa” olevista tavoitehierarkian osista erityisesti tuotetavoitteet ja sprinttitavoitteet.

Backlogin koon hallinta

On tärkeää, että backlogia ei päästetä kasvamaan optimikokoa suuremmaksi. Usein tämä optimikoko on pienempi kuin kuvitteletkaan. Noin 50 asiaa on usein hyvä peukalosääntö. On väistämätöntä, että backlogi yrittää jatkuvasti kasvaa tätä isommaksi.  Tuoteomistajan yksi tärkeimpiä tehtäviä onkin pitää backlogi tarpeeksi pienenä.

Backlogin koon hallinta hoituu parhaiten säännöllisillä “scan and plan” kokouksilla. Näissä kokouksissa puhdistetaan backlogilta vähemmän tärkeät asiat pois, ja tarkistetaan priorisointi yhdessä tiimin kanssa. Vain pitämällä backlog pienenä, tiimi pystyy varmistamaan että tehdään jatkuvasti oikeita asioita. Pieni backlog varmistaa myös nopean reagoinnin tarvittaessa.

Backlogin priorisointi

Tuoteomistaja priorisoi backlogia, ja tuotepäällikkö roadmapia. Tuotepäällikkö tuo roadmapilta “tarjolle” epic-tason asioita. Tuoteomistaja kuitenkin on päävastuussa siitä, mitä backlogille hyväksytään ja millaisin kriteerein.

Priorisointi on monimutkaista. Se tarkoittaa tasapainon hakemista uusien toimintojen kehittämisessä ja teknisen velan hallinnassa. Eri asikasryhmien, markkinoiden ja sidosryhmien tarpeita pitää kuunnella ja hakea optimia siinä, miten tuote tuottaa arvoa organisaatiolle. Priorisointi ei ole yksinkertaista. Sitä tehdään monilla eri tasoilla. Tuotepäällikkö priorisoi suurempia kokonaisuuksia ja roadmapia. Tuoteomistaja taas priorisoi työtä, joka on backlogilla ja pureskeltu pienemmiksi osiksi. Priorisoinnissakin auttaa selkeä visio ja aiemmin kuvattu tavoitehierarkia.

Demotilaisuudet ja palaute

Vaikka tiimilläkin on vahva vastuu demoista ja palautteen hakemisesta, tuoteomistajaa nämä asiat kiinnostavat myös paljon. Tuoteomistaja voi motivoida sidosryhmien edustajia tulemaan demotilaisuuteen ja yhdessä scrum masterin kanssa varmistaa että heidän palautteensa saadaan esiin. Palautteen saaminen on äärimmäisen tärkeää. Ilman palautetta koko ketterä toimintatapa menettää merkityksensä.

Palautetta pitää käyttää korjaaviin toimenpiteisiin, tulevan työn määrityksiin ja backlogin priorisointiin. Mutta pitää kuitenkin samalla muistaa, että tuoteomistaja tekee backlogin osalta päätökset. Sidosryhmäpalaute on vain tietoa, jota tuoteomistaja käyttää tähän päätöksentekoon.

Talomallin alin kerros ja portaikko

Tuoteomistajan huomio keskittyy tuotepäällikköä enemmän talomallin alimpaan kerrokseen, tuotekehitys- ja tuotantohuoneisiin. Tämän lisäksi tuoteomistaja on päävastuussa siitä, että portaikossa oleva tavoitehierarkia on selkeä, päivitetty ja kehitystiimi ymmärtää sen. Backlogin hallinta on täysin tuoteomistajan vastuulla, ja roadmapin osalta tuoteomistaja tukee tuotepäällikköä. Tämä siis periaatteena, jokainen tuotekehitysprojekti on erilainen, ja onkin syytä keskustella vastuista yhdessä. Uudistettua tuotejohtamisen talomallia kannattaa ehdottomasti käyttää keskusteluissa lähtökohtana ja pohjana.