Tuotejohtamisen talo on tuotepäällikön referenssimalli. Olemme esitelleet hiljattain uudistettua taloa jo muutamassa blogissa. Talomalli toimii muistilistana tuotepäällikölle – näitä asioita pitää muistaa tehdä. Tuotepäällikön rooli on melkein jokaisessa organisaatiossa omanlaisensa. Tässä blogissa esittelen seitsemän kohdan muistilistan tuotepäällikölle. Muistilistan myötä yhteistyö kehitystiimin kanssa paranee.

Tämä muistilista on tarkoitettu erityisesti tilanteeseen, jossa tuotepäälliköllä on apunaan erillinen tuoteomistaja. On myös mahdollista, että tuotepäällikkö itse hoitaa myös tuoteomistajan ketterää roolia. Jos tilanne on tämä, muistilistaa voi edelleen käyttää hyödyksi, mutta pitää muistaa, että tuoteomistajalla on muitakin tehtäviä. Olen tästä muistlistasta jättänyt pois esimerkiksi backlogin hallintaan ja priorisointiin liittyviä asioita. Muistilista on tärkeysjärjestyksessä, eli tärkeimmät muistettavat asiat tulevat heti ensiksi.

Sääntö #1: Tutustu ketteryyden perusperiaatteisiin

Vaikka tuotepäällikkö ei olekaan itse kehitystiimissä mukana, on hänen välttämätöntä ymmärtää ketteryyden perusperiaatteet. Miksi ketterä toimintatapa toimii hyvin? Miksi suunnitelmat kannattaa päivittää viimeisimmän tiedon perusteella? Erityisesti nopeasti muuttuvassa ympäristössä. Nykyään myös kehitettävät tuotteet ovat usein sellaisia, mitä kehittävä tiimi ei ole aikaisemmin rakentanut, ja rakennetaan usein teknologioilla joita tiimi ei ole aikaisemmin käyttänyt. Tällöin on välttämätöntä, että suunnitteluun ja työn määrittelyihin käytetään viimeisintä tietoa. 

Myös asiakkaiden tarpeet ovat nykyään hyvin dynaamisia. Tarpeita on lähes mahdotonta määritellä pitkän aikaa etukäteen. Kehitettävät järjestelmät ovat monimutkaisia, ja vasta kun niitä päästään kehittämään ja kokeilemaan, paljastuu tarkasti se, miten niiden pitäisi toimia. Tästä syystä myös tuotepäällikön pitää ymmärtää nämä ketterän tekemisen lainalaisuudet. Hyviä resursseja mihin kannattaa tutustua ovat Scrum guide, Agile manifesto, Scrumin arvot, ketteryyden periaatteet, Scrumin pilarit. 

Ketterän kehitystiimin toiminta perustuu pitkälle näihin ajatusmalleihin. Vaikka jokaisen tiimin toiminta onkin sovellus ideaalista ketterästä toimintamallista, kannattaa näihin teorioihin tutustua. Kannattaa myös miettiä, miten tuotepäällikkönä voi toimia niin, että näitä ajatuksia käyttävän tiimin olisi mahdollisimman helppo toimia.

Sääntö #2: Keskustele päivittäin tuoteomistajan kanssa

Saumaton yhteistyö tuotepäällikön ja tuoteomistajan välillä on yksi aivan ehdoton edellytys hyvälle ketteryydelle. Jos tässä yhteistyössä on mitään kuoppia tai mutkia, se on erittäin vaarallista. Olen valmennusurallani nähnyt useita tilanteita missä tämän parivaljakon kemiat ja luottamus ei toimi. Nämä tilanteet johtavat suuriin vaikeuksiin ja tehottomuuteen tuotteen kehittämisessä.

Luottamuksen yksi perusedellytys on säännöllinen kommunikaatio. Olen sitä mieltä, että yhteydenpito pitää olla päivittäistä. On se sitten yhteinen lounas, lyhyitä keskusteluja kahvitauolla, kokouksia, tai vain slack tai teams chattailyä, sillä ei ole niin merkitystä. Ottakaa tavaksi jutella joka päivä.

Jokapäiväinen keskustelu on tärkeää, koska se mahdollistaa seuraavia asioita:

• Nopea päätöksenteko 
• Tiedonjako 
• Ei unohdu kertoa mitään
• Nopea palaute ja tilaisuus demota uusimpia muutoksia
• Tarkempi priorisointi

Takaan, että yhteistyö ja luottamus paranee, kun kommunikaatio on päivittäistä. Sen ei tarvitse ottaa kuin kymmenen minuuttia, mutta ne minuutit maksavat itsensä takaisin moninkertaisesti.

Sääntö #3: Puhukaa rooleista ja vastuista

Jos tuotepäällikön ja kehitystiimin välillä on vaikeuksia, ne on usein johdettavissa epäselvyyksiin roolimäärityksissä ja vastuissa. Olen nähnyt monta kertaa, kuinka vastuujakoa selventämällä on löytynyt helppojakin tapoja parantaa yhteistyötä. Vastuukartta-harjoitus on hyvä tapa löytää epäselvyydet ja sopia mitä niille pitää tehdä. 

Vastuiden selkeytys vähentää konflikteja, ja auttaa tiimiä tekemään töitä enemmän itseohjautuen. Lisäksi siinä paljastuu usein asioita, mitkä ovat jääneet liian vähälle huomiolle. Vastuiden kartoittamisen harjoitus saattaa myös paljastaa juurisyitä ongelmiin. 

Olen ollut mukana harjoituksessa missä kaikille paljastui, miksi tuotepäällikkö ei ollut tehnyt jotain tarpeellisia asioita: hänen vastuullaan oli kolmekymmentä tärkeää asiaa. Oli käytännössä mahdotonta tehdä kaikkea. Keskustelu etenikin sitten siihen suuntaan, miten muu tiimi voisi auttaa ja tukea tuotepäällikköä.

Sääntö #4: Hyvät tuotevisio ja tuotetavoitteet 

Yksi hyvän ketteryyden perusasioita on tavoitehierarkia. 

• Tuotevisio
• Tuotetavoitteet
• Sprinttitavoitteet

Tuotevisio tarkoittaa tuotteen tavoitetilaa muutaman vuoden päästä. Se on tärkeä, mutta se on kehitystiimille liian kaukainen tavoite. Tarvitaan hyvin määriteltyjä astinkiviä kohti tuotevisiota. Tätä tarkoitusta varten tiimi tarvitsee selkeät tuotetavoitteet (engl: Product Goals). Tuotetavoitteet ovat muutaman kuukauden välein asetettuja hyvin konkreettisia tavoitteita. 

Roadmap voi määritellä moniakin näitä tuotetavoitteita, ulottuen usean vuodenkin päähän. Mutta varsinaisella tiimin kehitysbacklogilla on usein vain seuraavan tuotetavoitteen asioita. Backlogia, joka on roadmapiin verrattuna paljon suurempi sitoutuminen tiimiltä, pitää suojella. Backlog ei saa kasvaa liian suureksi. Backlogin hallinta ja priorisointi on tuoteomistajan tehtävä.

Tuotetavoitteiden määrittely kuuluu tuotepäällikön vastuulle, mutta tuoteomistaja on siinä vahvasti mukana. Seuraavassa esimerkkejä omasta työhistoriastani:

• Järjestelmän asennukseen käytettävän ajan pienentäminen
• Käyttöliittymän remontointi tukemaan suuriresoluutioisia 4K näyttöjä
• Järjestelmän tuki suurikokoisille tallennuskovalevyille
• Palvelun pilottikäyttövalmius
• Palvelun kaupallisen käytön valmius

Nämä tavoitteet johtavat suureen määrään backlogilla olevia kehitysasioita. Ne myös auttavat tiimiä valitsemaan bugeista ja teknisen velan asioista ne, jotka parhaiten vastaavat tuotetavoitteen “missiota”. Aina, kun olen ollut itse tilanteessa, missä priorisointi on ollut haaste ja tekemistä liikaa, selkeämmät tuotetavoitteet auttavat valitsemaan oikeat asiat työn alle. Selkeät tuotetavoitteet helpottavat myös uuden julkaisun viestintää asiakkaille. 

Sääntö #5: Osallistu demoihin aktiivisesti

Mene aina mukaan sprinttidemoihin! Osoita kiinnostusta ja kysy kysymyksiä. Anna palautetta. Kiitä ja arvosta tiimin työtä. Huomaa, että kaiken ei tarvitse mennä aina oikein, ja sinä et ole välttämättä aina oikeassa.

Demoissa on myös tärkeää perustella, miksi olet jotain mieltä. Huomaa, että olet tuotteen asiakas- ja markkinatarpeiden paras asiantuntija. Kun annat palautetta, selitä miksi olet jotain mieltä. Yhtä tärkeää on kuitenkin myös osata kuunnella. Tiimissä on monia erilaisia näkökulmia ja kokeneita kehittäjiä. On tärkeää pystyä myös kuuntelemaan heidän ajatuksiaan.

Muista, että on myös mahdollista saada demoja muuallakin kuin sprinttidemo tilaisuudessa. Ole valmis antamaan palautetta myös kesken sprintin, jos tiimi sitä kaipaa. Demotilaisuudessa on myös täydellinen tilaisuus kertoa tiimille uutisia asiakkaista ja markkinoista. Älä ajattele, että demo on yksisuuntainen tie. Valmistaudu kertomaan lyhyesti missä markkinoilla mennään, ja miten markkinoiden tilanteen muutokset vaikuttavat priorisointiin.

Sääntö #6: Hallitse roadmapia

Roadmapin hallinta tarkoittaa sitä, että varmistetaan että asiat on oikeassa prioriteetti- ja aikajärjestyksessä. Eri suunnista, asiakkailta, sidosryhmiltä, markkinoilta, tulee jatkuvasti tietomuruja, jotka vaikuttavat prioriteetteihin ja siihen, miten roadmapilla olevia asioita määritellään. Näitä tietomuruja (insights) kannattaa pyrkiä keräämään ja ylläpitämään roadmapin yhteydessä.

Roadmap tarvitsee myös hallinnan kokouksia, jossa tärkeimpien sidosryhmien kanssa katsotaan roadmapin tilaa. Näissä kokouksissa kannattaa siivota asioita pois ja myös keskustella siitä, mitä roadmapilta aloitetaan seuraavaksi.

Hallintaan liittyy myös epävarmuuden hallinta. Jokaisessa tulevassa työssä on tietty määrä epävarmuutta ja oletuksia. Suuri osa näistä oletuksista tai arvauksista on mahdollista tehdä ja saada oikein. Haasteena on tunnistaa, mitkä oletuksista ovat kriittisiä tai vaarallisia oletuksia. Kun nämä on valittu tai tunnistettu, tuotepäällikön vastuulla on järjestää testejä tai kokeiluja, joilla saadaan lisätietoa näistä oletuksista. 

Nämä testit voivat olla vaikka keskusteluja asiakkaan kanssa, fokusryhmiä, A/B testausta tai muuta vastaavaa. Todella hyvät kehitysorganisaatiot tekevät tällaisia testejä joka viikko. Niistä saadaan dataa, jonka perusteella voidaan tehdä oikeita päätöksiä tarkasti.

Sääntö #7: Auta tiimiä kurinalaiseen ketteryyteen

Kurinalainen ketteryys tarkoittaa sitä, että 

• tiimi pyrkii aina määrittelemään aloitettavat työt backlog refinement -kokouksessa
• Tiimi on määritellyt Definition of Done ja Definition of Ready -sopimukset. 
• Tiimi pyrkii tekemään työmääräarviointia kaikelle aloitettavalle työlle, ja ei aloita liian suuria työkokonaisuuksia
• Tiimi ei koe painetta yliladata kehityssprinttejä
• Tiimi pyrkii vähentämään meneillään olevan työn määrää, ja nostamaan sen sijaan työn virtausnopeutta
• Tiimille ei “pusketa” työtä, vaan tiimi itse pystyy valitsemaan sopivan määrän työtä joka vie tuotetta kohti seuraavaa tuotetavoitetta.

Kaikki nämä ylläolevat asiat ovat kehitystiimin itsensä vallassa toteuttaa. Mutta tuotepäällikkönä voit käytökselläsi helpottaa tiimiä pysymään näissä sopimuksissa. Tuotepäällikkö ei saisi asettaa tiimille painetta toteuttaa tiettyä määrää uusia toimintoja. Kaiken pitää perustua prioriteetteihin. Tehdään tärkeimmät asiat valmiiksi.

Tuotepäällikkönä autat tiimiä kurinalaiseen ketteryyteen myös hyväksymällä sen, että suunnitelmista löytyy epävarmuutta. Ketteryydessä ainoa sitoutuminen tehdään sprintti kerrallaan. Kaikki muu on arviota ja arvauksia. Sinun pitää sisäistää tämä, ja alkaa arvioida asioita niiden todennäköisyyden perusteella. Kun kommunikoit muille sidosryhmille ja asiakkaille, muista sanamuodoissa ja kielenkäytössä tämä. Vältä “varmoja lupauksia” jos vain mahdollista. Jos jokin asia on “pakko tehdä”, tee se selväksi myös kehitystiimille, ja ole valmis neuvottelemaan sisällöstä.

Lopuksi, tue tiimin Scrum Masteria. Monissa tiimeissä Scrum Masterin rooli nähdään “pakollisena pahana”, vaikka tämä rooli onkin todella tärkeä. Hyvä Scrum Master johtaa tehokkaampaan tekemiseen, parempaan laatuun ja tyytyväisempiin asiakkaisiin. Scrum Masterin työ on arvokasta. Yritä omalla kommunikoinnilla ja kielenkäytöllä auttaa organisaatiota ymmärtämään tämä.