Monessa yrityksessä strategian toteuttaminen on hidasta. Vaikka visio olisikin kirkas ja askeleet sen saavuttamiseen ovat tiedossa, tuntuu kuitenkin siltä, että tuotekehitystiimien aika kuluu taktiseen tekemiseen. Tämä voi johtaa kilpailukyvyn rapautumiseen, sillä muutos on jatkuvaa. Yrityksen johtamisen kannalta on tärkeää, että siihen löytyy tehokkaita keinoja.
Tiimien suuntaan ongelma näkyy niin, että tuotteella on kyllä backlogi, mutta tuotteen kehityssuunta on osittain hämärän peitossa. Kehittäjät kyllä tekevät backlogilta asioita ja toimintoja, mutta jokapäiväistä työtä on hankala yhdistää tuotteen pitkän tähtäimen suuntaan. Tämä johtuu siitä, että tuotevisio on hämärä ja kaukana, ja tuotejohto on unohtanut määritellä selkeät tuotetavoitteet. Tuotetavoitteiden puuttuessa tiimin on hankala käyttää tehokkaasti omaa työkaluaan, sprinttitavoitteita.
Pelkkä tuotevisio ei riitä
Tuotevision pitäisi kuvastaa tuotteen tilannetta useamman vuoden päästä. Sen pitäisi olla kauaskantoinen tavoite siitä, mihin kehitystiimi ja tuotejohto haluavat tuotetta viedä. Ketterät toimintamallit puhuvat tuotevision tärkeydestä, mutta usein tuotevisio on joko unohtunut määritellä, hautautunut tuotepäällikön työpöydän laatikkoon pölyä keräämään, tai sitten unohtunut vuosien varrella päivittää vastaamaan nykyhetken tilannetta.
Tuotevisio täytyy muistaa pitää tuoreena, mutta sen lisäksi se tarvitsee rinnalleen pienempiä tavoitteita, astinkiviä, jotka vievät tuotetta kohti visiota. Nämä tavoitteet voidaan jakaa tuotetavoitteisiin (Product Goals) ja sprinttitavoitteisiin (Sprint Goals). Jos tuotevisio on vuosien päässä, lähimpien tuotetavoitteiden pitäisi olla vain kuukausien päässä.
Sprinttitavoitteet johdetaan lähimmästä tuotetavoitteesta
Ketterä tiimi asettaa sprinttitavoitteet sprintin alussa ja ne liittyvät lähimpään tuotetavoitteeseen. Sprinttitavoitteiden avulla tiimi varmistaa että oikeat asiat tulevat valmiiksi. Koko tiimi tietää mikä on tärkeää tässä sprintissä. Sprinttitavoitteiden avulla tiimi voi esimerkiksi daily-kokouksessa varmistaa että oikeat asiat ovat valmistumassa, eikä kukaan aloita työtä sellaisen sprint-backlog asian kanssa joka ei auta sprinttitavoitteiden saavuttamisessa.
Tuotetavoitteiden puuttuminen johtaa ongelmiin
Nyt olemme varsinaisen ongelman äärellä. Usein tuotekehityksessä ei ole selkeästi määritettyjä tuotetavoitteita. Usein myös sprinttitavoitteita on yritetty käyttää ja sitten niiden käyttö on unohtunut, kun se on osoittautunut vaikeaksi. Onko sitten yhtään ihme, jos tuotteen suunta tuntuu hämärältä, ja tehtävien maadoittaminen tuotevisioon hankalalta?
Tuotetavoitteiden pitäisi olla noin 2-6 kuukauden päässä tulevaisuudessa. Tavoitteiden väli voi olla pidempi, jos kehitettävä ratkaisu on monimutkaisempi ja vaatii usean tiimin yhteistyötä. Jos tavoitteeksi on määritelty parin kuukauden päässä oleva uusi toiminto, pitäisi kehittäjän olla varsin helppo ymmärtää miten oma työ siihen liittyy. Lisäksi tämä helpottaa kehitystyön hallitsemista, niin että ei lähdetä tekemään tarpeettoman vaikeita ratkaisuja.
Tavoitteet helpottavat priorisointia
Kun tuotetavoite on määritelty, sprinttitavoitteet on paljon helpompi ottaa ja pitää käytössä. Kehitystiimien pitäisikin aina lähestyä tuotevisiota sillä ajatuksella, että se pilkotaan tuotetavoitteiksi ja sitten sprinttitavoitteiksi. Kutsun tätä itse tavoitehierarkiaksi.
Vahva tuotetavoite on korvaamaton apu backlogin hallintaan ja priorisointiin. Ohjeeni tuoteomistajille on: “Hyväksy backlogille pääasiassa vain seuraavaan tuotetavoitteeseen vieviä asioita.” Muille pyynnöille vastataan “Ei juuri nyt.” Backlogin pitäminen hyvin pienenä helpottaa backlogin jalostamista ja myös lisää tiimin ketteryyttä. Muu tuleva työ hallinnoidaan roadmapissa.
Tuotetavoite määrittelee backlogin optimikoon
Oikein käytettynä tuotetavoite määrittelee myös backlogille optimikoon. Jos tuotetavoitteiden väli asettuu luonnollisesti kahteen kuukauteen, myös backlogin pitäisi olla noin kahden kuukauden työt sisältävä. Jos tavoitteiden väli on puoli vuotta, backlogikin saa olla puolen vuoden mittainen. Usein pidempi tavoiteväli tarkoittaa monimutkaisempaa kehitystilannetta ja isompaa kehitysorganisaatiota, jolloin hieman pidempi backlogi on hyödyksi.
Sprinttitavoitteiden käyttö helpottuu
Tuotetavoitteiden määrittelystä päävastuussa on tuotepäällikkö. Tuotetavoitteet kannattaa taas tehdä yhteistyössä tuotepäällikön ja tuoteomistajan kanssa. Kehitystiimien ja tuotejohtajien kannattaa muistaa ottaa tuotetavoitteet ja sprinttitavoitteet käyttöön yhtä aikaa ja pitää käyttöä aktiivisena. Tavoitteet auttavat toisiaan: sprinttitavoitteet on helpompi ottaa käyttöön kun tuotetavoitteet on määritelty, ja tuotetavoitteet on helpompi saavuttaa kun sprinttitavoitteiden käyttö on tiimeissä rutiinia.
Tuotetavoite ei ole staattinen
Tuotetavoite voi myös muuttua. Ketterän toimintatavan suurimpia hyötyjä on, että tiimi voi suunnittelussa aina hyödyntää uusimman tiedon ja kerätyt opit. Tuotetavoitekin voi uusimpien kokemusten perusteella muokkautua. Jos tuotetavoitetta muokataan, siihen vahvasti linkitetty backlogikin todennäköisesti tarvitsee rankkaa remonttia.
Tuotetavoite: tuotejohdon tärkein työkalu
Hyvät tuotetavoitteet auttavat tiimiä monella tavoin:
- Tiimi kokee sprinttitavoitteiden käytön helpommaksi
- Sprinttitavoitteiden käytöllä saadaan tehostettua ketterää tekemistä
- Motivaatio paranee kun oma tekeminen yhdistyy selkeämmin tuotteen suuntaan
- Backlogin koon hallinta helpottuu, kun tuotetavoitetta voi käyttää backlog-hyväksyntään
Eficode auttaa!
Hyvien tuotetavoitteiden määrittäminen ja käyttö vaatii harjoittelua, mutta tarjoaa niin valtavasti hyötyjä suuremman tehokkuuden ja tiiviimmän, laadukkaamman backlogin muodossa, että tuotepäällikköjen ja tuoteomistajien on syytä ottaa tämä työkalu käyttöön. Tuotetavoitteiden, tuotevision, tuotestrategian ja backlogin hallinnan kanssa voi kokenut valmentaja olla suureksi avuksi. Autamme näissä asioissa mielellämme. Ota yhteyttä.
Referenssimalli tuotejohtajan avuksi: tule mukaan webinaariimme
Tuotetavoitteet, tuotevisio ja tuotestrategia ovat vain pieni osa kaikkea sitä, mitä tuotejohtajien pitää hallita. Olemme kehittäneet Eficodella tuotejohtamisen referenssimallin, jossa kuvataan koko tuotejohdon työsarka. Referenssimallilla saadaan monia etuja. Tärkeät, mutta ei niin kiireelliset asiat eivät unohdu. Tehtävistä ja vastuunjaosta on helpompi sopia. Kaikki sidosryhmät myös ymmärtävät mitä kaikkea tuotepäällikön pitää hoitaa.
Esittelemme juuri päivitetyn tuotejohtamisen referenssimallin webinaarissamme 5.12. Toivottavasti tulet kuulemaan ajatuksiamme.
Rekisteröidy webinaariin tästä:
https://www.eficode.com/fi/webinar-from-vision-to-implementation-what-modern-product-management-involves
Julkaistu: 7. marraskuuta 2023
