Tilanne on tämä: olet aloittamassa työtä tuoteomistajana tai tuotepäällikkönä hankkeessa, joka on ollut jo liikkeellä jonkin aikaa. Et ehkä ole täysi asiantuntija juuri siinä jutussa, mitä kehitetään. Tilanne on haastava. Miten oppisit nopeasti, jotta voit auttaa tuotekehitystä mahdollisimman pian toimimaan tehokkaammin?

Kuvaan tässä blogissa ensin kolme varmaa asiaa, mihin tulet joka tapauksessa törmäämään. Sitten kuvaan kolme asiaa, jotka ovat tuntemattomia. Nämä tuntemattomat asiat sinun pitää selvittää. Lopuksi annan neljä periaatetta, jotka toimivat kaikissa tämänkaltaisissa tilanteissa.

Huomaa! Jos joudut tällaiseen tilanteeseen, on avuksi jos sinulla on joku referenssimalli muistuttamassa siitä, mitä kaikkea pitää tehdä. Esittelemme päivitetyn tuotejohtamisen referenssimallin Antti Suvannon kanssa 5. joulukuuta webinaarissa.

Ensimmäinen varma asia: et tunne tuotetta vielä niin hyvin kuin sinun pitäisi.

On varmaa, että et ole vielä niin hyvä tuotteen, sen asiakkaiden ja markkinoiden asiantuntija. Sinun pitääkin aluksi tehdä suunnitelma, miten kehität omaa ymmärrystäsi ja taitojasi tuotteen ominaisuuksista ja käyttäytymisestä. Aluksi sinun on luotettava tuotekehitystiimiin (he ovat olleet tässä mukana alusta asti). Kokeile tuotetta, testaa sitä, tutki sitä sekä ympäristöä tullaksesi “tuotteen asiantuntijaksi” niin nopeasti kuin voit. Tavallisesti tämä vie kolmesta kuuteen kuukautta. Ota yhteyttä ja tapaa tärkeimmät asiakkaat ja sidosryhmät yrityksen sisällä. Keskustele heidän kanssaan. Millaisia haasteita heillä on? Miten voidaan yhteistyössä luoda maksimaalisesti lisäarvoa?

Toinen varma asia: saat vastuullesi laiminlyödyn backlogin tai roadmapin

Hyvin hoidettu backlog pitää projektin raiteillaan. Kun tuoteomistajaa tai tuotepäällikköä ei ole ollut vähään aikaan, tuotekehitysjono voi olla sekava; selkeiden tehtävien sijaan saatat löytää hämmentäviä muistiinpanoja. Monet näistä saattavat olla tiimin jäsenten kirjoittamia, jotka ovat ajatelleet enemmän teknologiaa kuin sitä, mitä käyttäjät haluavat.

Kolmas varma asia: jokainen tiimi on erilainen – joudut oppimaan ja sopeutumaan uuteen tiimidynamiikkaan

Jokainen tiimi toimii omanlaisellaan dynamiikalla ja rytmillä. Tätä rytmiä muokkaavat persoonallisuudet, aikaisemmat kokemukset ja vakiintuneet prosessit. Jos liityt tiimiin kesken matkan, kohtaat väistämättä vakiintuneen tavan tehdä töitä. Tiimin kokoukset, viestintä ja ihmissuhteet ovat asettuneet tiettyihin uomiin. Tämä dynamiikka voi olla saumatonta, tai siinä voi olla näkyviä aukkoja.

Riippumatta tilanteesta, tuotteen omistajan rooli ei ole ainoastaan ohjata tuotteen suuntaa, vaan myös edistää positiivista ja yhteistyöhenkistä tiimiympäristöä. Hyvä tuotejohtaja toimii ”voitelevana öljynä” tiimin kommunikaatiossa. Tässä suuri rooli on myös Scrum Masterilla, mutta tuotejohtajan ei kannata jättää tästä asiasta huolehtimista vain hänen harteilleen. Ymmärrä olemassa oleva dynamiikka, ja vaikka on tärkeää tuoda mukanasi oma asiantuntemuksesi ja uusi näkökulmasi, on yhtä tärkeää kunnioittaa vakiintuneita prosesseja ja ottaa käyttöön muutoksia vähitellen.

Ensimmäinen tuntematon: Tiimin backlog-itsekuri

Kun aloitat uudessa tiimissä, et voi tietää, millainen tiimin itsekuri töiden aloittamisen suhteen on. Onko tapana ollut aloittaa töitä vain backlogin kautta, vai onko ollut sallittua ottaa työn alle työtä mistä vain, jos se on tuntunut tärkeältä. Sinun täytyy selvittää, mikä on vallitseva kulttuuri ja sopia ”tuotekehitysjonon säännöistä”. Esimerkiksi kaikki pienet tehtävät (15 minuutin työ) eivät tarvitse omaa tikettiä. Saatatte tiiminä päättää näin, tai asettaa rajan korkeammalle, tai olla asettamatta rajoja lainkaan. Se on sinun ja tiimin päätettävissä, mutta teidän täytyy keskustella siitä. On välttämätöntä sopia yhdessä ja asettaa joitakin rajoja.

Toinen tuntematon asia: Backlogin koko

Täysin tuntematon asia on se, miten ison backlogin kohtaat. Voit periä lyhyen vain muutaman kymmenen kohdan listan, tai toisessa äärimmäisyydessä voit törmätä backlog-mammuttiin, jossa on 2000 asiaa.

Hyvin pieni backlog on epäilyttävä. Pieni backlog on saattanut pysyä pienenä sen takia, että suurin osa työstä ei ole kiertänyt sen kautta. Jos tiimillä on kuitenkin vahva backlog kuri, ja backlog on silti hyvin pieni, tilanne saattaa olla hyvä, varsinkin jos backlogin kiertonopeus on suuri, ja suhteet sidosryhmiin on kunnossa.

Mammuttimaisen backlogin tapauksessa tuotekehitysjonoa on väärinkäytetty “toivelistana”, ja edessä on suursiivous. Kokemukseni mukaan todennäköisimmin kohtaat hieman turvonneen, muutaman sadan kohdan tuotekehitysjonon, ja sinun täytyy aloittaa sen siivoaminen ja turhan pois heittäminen (lisää tästä myöhemmin).

Kolmas tuntematon asia: Suhteet sidosryhmiin

Tiimin suhteet sidosryhmiin ovat kolmas tuntematon. Suhteet voivat olla normaalit ja terveet, mutta on myös mahdollista, että yhteyttä ei ole pidetty ollenkaan. Saattaa olla myös mahdollista, että joku muu henkilö on ottanut hyvin aktiivisen roolin tiimin työn ohjaamisessa. On mahdoton ennustaa millainen tilanne on syntynyt, jos tiimi on ollut pidempään ilman tuotepäällikköä tai tuoteomistajaa.

Sinun on selvitettävä, mikä tilanne on ja tehtävä yhteistyötä sen mukaisesti. Jos kyseessä on ”toimitusjohtaja”, pysähdy ja aloita tiimin suojeleminen tuotekehitysjonon avulla.

Neljä periaatetta uusille tuotejohtajille

Kun olet siis tällaisessa tilanteessa, ja jos edellä kerrotut tiedetyt ja tuntemattomat asiat kuulostavat tutulta, tässä on neljä periaatetta, jotka voivat auttaa.

Prinsiippi 1: Aseta lähitulevaisuuden tuotetavoite

Tuotetavoitteet (eng. Product Goal) on äärimmäisen voimakas tiimin toimintaa ohjaava asia. Niitä käytetään yleisesti aivan liian vähän.

Tuotetavoitteella saavutetaan seuraavat asiat

• Tavoitteet toimivat priorisoinnin apuvälineenä. Backlogille päästetään vain asiat, jotka auttavat pääsemään lähimpään tuotetavoitteeseen
• Jos tavoite on tarpeeksi selkeästi määritelty, tiimin kaikki jäsenet pystyvät itse valitsemaan oikeat tehtävät ja niiden laajuuden

Keskustele tiimin ja sidosryhmien edustajien kanssa, ja määritelkää yhdessä tavoite parin kolmen kuukauden päähän. Määritelkää lisäksi yksi tai kaksi tavoitetta kauemmas tulevaisuuteen.

Nyt voitte käyttää näitä tavoitteita seuraavasti

• Puhdista tuotekehitysjono kaikesta, mikä ei edistä tuotteen tavoitteita.
• Priorisoi jäljelle jäävät kohteet.
• Hylkää tai siirrä roadmapille ne kohteet, jotka eivät edistä valittua tavoitetta.

Miksi kannattaa aloittaa lähimmästä tavoitteesta, eikä tuotevisiosta? Yksinkertaisesti sen takia, että se on nopeampaa. Vision päivittäminen on iso ja pitkäkestoinen asia. Sillä ei saa aikaan nopeaa muutosta. Muutaman kuukauden päässä oleva selkeä tavoite mahdollistaa backlogin siivouksen, tehokkaan lähitulevaisuuden tekemisen priorisoinnin, ja lisää tiimin fokusta. Sen takia kannattaa aloittaa siitä.

Vaikka tämä menetelmä ei aina johda täydellisen oikeaan tavoitteeseen, on hyvin todennäköistä, että se ohjaa tuotetta hyödylliseen suuntaan.

Prinsiippi kaksi: Pidä backlog tarpeeksi pienenä

Jos perit backlogin, joka on jo aika pienikokoinen (50-100 asiaa), kiinnitä ensin huomiota backlog kuriin tiimissä. Kulkeeko kaikki työ tosiaan backlogin kautta? Jos näin on, tilanne saattaa olla aika hyvä. Puhu kuitenkin myös sidosryhmien kanssa. Onko heillä tarpeita, joita tiimi on laiminlyönyt?

Todennäköisempää on kuitenkin, että perit tilanteen, jossa backlog on liian iso. Hyvän backlogin ylärajana voi pitää tilanteen mukaan noin 100–150 asiaa. Jos backlog on tätä suurempi, pitää aloittaa siivous.

Siivousta varten hyödyttää, jos olet tehnyt tuotetavoitteet kuten prinsiipissä yksi kerroin. Siivous on parasta tehdä yhdessä tiimin ja tärkeimpien sidosryhmien kanssa. Muistakaa – kaikki mitä valitaan poistettavaksi backlogilta, mahdollistaa sen, että backlogille jäävä työ tehdään paremmin ja varmemmin. Äärimmäisessä tilanteessa saattaa olla jopa parasta, että laitetaan koko backlog roskakoriin ja rakennetaan uusi.

Prinsiippi kolme: Pidä huolta, että backlogin hallinnan ja jalostamisen seremoniat kehittyvät

Tuotteen roadmap ja backlog tarvitsee hallintaa. Backlogin jalostamiseen (refinement) ja roadmapin läpikäyntiin (grooming) pitää olla säännölliset kokoukset. Näitä kokouksia ja niihin liittyviä työkaluja ja valmistautumisen keinoja pitää jatkuvasti kehittää.

Backlogin jalostamisen kokous tiimin kanssa olisi hyvä järjestää joka viikko. Tämä kokous keskittyy lähimmän muutaman viikon sisällä tapahtuvaan tekemiseen, ja sen yksityiskohtiin. Tässä refinement-kokouksessa voidaan keskustella yksittäisistä tehtävistä, käyttäjätarinoista ja niiden kokoarvioista, hyväksyntäkriteereistä ja toteutustavasta. Tunti tai kaksi tuntia viikossa on hyvä investointi tähän.

Roadmapin läpikäynti grooming-tyyliin on hyvä pitää vähintään kerran kuussa. Tähän voi osallistua tärkeimpien sidosryhmien edustajia tiimin tai tiimin edustajien lisäksi. Roadmap keskustelut ovat usein astetta korkeammalla tasolla, keskustellen ominaisuuksista tai epiceista. Nämä keskustelut saattavat katsoa noin 3–9 kuukautta tulevaisuuteen.

Tärkeä transition on, kun asiat siirtyvät roadmapilta backlogille. Tässä hetkessä tehdään päätös, jos asia todella pääsee toteutukseen. Onko se tarpeeksi hyvin ymmärretty? Onko aika sille juuri nyt? Onko muistettu miettiä, mitkä ovat isoja oletuksia? Onko riskaabeleimmat oletukset muistettu testata jollain tavalla?

Ylläpitämällä roadmapia ja backlogia aktiivisesti ja erillään, pystytään pitämään backlog tarpeeksi pienenä. Tämä auttaa pitämään backlogin jalostamista tehokkaana. Backlogin ja roadmapin hallinnan seremoniat ovat tärkeitä, ja niitä pitää kehittää jatkuvasti. Ette saavuta täydellistä hallintaa nopeasti. Tärkeämpää on jatkuva kehitys.

Prinsiippi neljä: Opi tuntemaan avainsidosryhmien edustajat

Muista pitää tapaamisia säännöllisesti avainsidosryhmien edustajien kanssa. Ne voivat olla lounastreffit, tai sitten vaan mene kertomaan heille, miten heitä kiinnostavat asiat ovat edistymässä. Säännöllisyys on tärkeää. Kun annat heille tietoa heitä kiinnostavista asioista, hekin auttavat sinua, esimerkiksi kertomalla tietoa markkinoista, asiakkaista, tai tuotteeseen liittyvistä haasteista.

Aloittaminen tuotteen omistajana

Jo käynnissä olevaan projektiin hyppääminen tuotteen omistajana voi olla haastavaa. On monia asioita, joita et ehkä tiedä, ja monia ongelmia korjattavana. Mutta jos noudatat tässä blogikirjoituksessa esitettyjä periaatteita, voit nopeasti päästä raiteille ja auttaa tiimiäsi.