OKR on puhuttanut viime vuosina paljon. Yksi OKR-mallin parhaista puolista on se, että se neuvoo ilmaisemaan tavoitteet (objectives) haluttuina seurauksina (outcome-based goals).
Tässä artikkelissa kerron kolmesta hyödystä, jotka seuraavat siitä, että tuotekehitysorganisaatio siirtyy määrittelemään tavoitteensa haluttuina seurauksina.
Mitä ovat haluttuina seurauksina esitetyt tavoitteet
Haluttuina seurauksina esitetyt tavoitteet (engl. outcome-based goals) ovat erilainen tapa kirjata tavoitteita, kuin mihin olemme tottuneet.
Perinteisessä tavoiteasetannassa tavoitteet ovat yleensä jompaa kumpaa tyyppiä seuraavista:
- Tuotoksena esitetty tavoite, esim. uuden tuoteversion julkaisu. Tavoitteessa kerrotaan, mikä tuotos aiotaan tehdä tai saada aikaan.
- Liiketoiminnan KPI-mittarin (engl. key performance indicator) tuloksena esitetty tavoite, esim. tuoteliiketoiminnan tuotto nousee 20% viime vuodesta.
Tuotoksina esitetyt tavoitteet ovat tyypillisiä projektinhallintamaailmassa ja KPI-mittareina esitetyt taas liiketoimintamaailmassa.
Tuotoksina esitettyjen tavoitteiden heikkoudet ovat kahtalaiset. Ensinnäkin ne sitovat asiantuntijoiden kädet. Kun tavoitteessa on ilmoitettu jo haluttu tuotos, jää asiantuntijoille vain kuvatun tuotoksen toteuttaminen. Toiseksi ne eivät takaa menestymistä tai ohjaa tekemistä välttämättä oikeaan suuntaan. Se, että uusi tuoteversio saadaan julkaistua, ei vielä takaa, että se tulee menestymään.
KPI-mittareiden tuloksina esitetyt tavoitteet taas ovat liian korkealla tasolla, jotta ne sellaisenaan voisivat ohjata tuotekehitystä. Ne voivat antaa suuntaa, mutta niiden lisäksi tarvitaan tarkempia tavoitteita tekemisen fokusta ohjaamaan.
Haluttuina seurauksina kuvatut tavoitteet (engl. outcome-based goals) ovat juuri näitä tarkempia tavoitteita, jotka eivät kuitenkaan sido asiantuntijoiden käsiä.
Tälläiset tavoitteet kuvaavat sitä, miten halutaan jonkun tietyn viiteryhmän käyttäytymiseen vaikuttaa. Tässä muutama esimerkki:
- [B2B-SaaS-tuotteen] pk-yritysasiakkaista 80% jatkaa vuositilaustaan tilauksen loppuessa (nykyinen tilanne 50%)
- 20% enterprise-tilaajista korottaa tilauksensa platinatasolle
- Tuoteländärin konversioprosentti kaksinkertaistuu
- Käyttäjäryhmän A viikottainen käyttöaika tuplautuu
Näistä esimerkeistä kaikki voisivat olla tarkempia haluttuina seurauksina ilmaistuja tavoitteita KPI-tavoitteelle tuoteliiketoiminnan tuotto nousee 20%.
Tälläisiä tavoitteita voi johtaa KPI-tavoitteista esim. vaikutuskartoitusmenetelmällä (engl. impact mapping). Mutta se on aihe omalle artikkelilleen.
Esim. Jeff Gothelfiltä löytyy hyviä artikkeleita terminologiasta (Output, outcomes, impacts and KPIs) sekä siitä, kuinka ohjata tuotekehitystä OKR:illä / haluttuina seurauksina ilmaistuin tavoittein.
Mitä hyötyä haluttuina seurauksina ilmaistuista tavoitteista sitten on?
Tässä 3 vastausta:
- Voidaan johtaa liiketoiminnan KPI-tavoitteista strategia
- Voidaan jäsentää ja järkeistää tuotebacklogi
- Voidaan tehdä product discovery -työtä järjestelmällisesti
1. Voidaan johtaa liiketoiminnan KPI-tavoitteista strategia
Tyypillisesti tuoteliiketoiminnalle asetetaan tavoitteet KPI-mittareiden tulosten muodossa. Esim.
- tuoteliiketoiminnan tuotto nousee 20% viime vuodesta
- markkinaosuus nousee 30%
KPI-mittareiden tuloksina esitetyt tavoitteet ovat liian korkealla tasolla, jotta ne sellaisenaan voisivat ohjata tuotekehitystä.
Tämä voi tehdä näin asetetuista tavoitteista motivaatiota syöviä tuoteorganisaatiolle. Tavoitteet voivat tuntua todellisuudesta irrallisilta ja hankalasti saavutettavilta.
KPI-tavoitteiden pilkkominen haluttuina seurauksina ilmaistuiksi tavoiteaihioiksi voi auttaa tässä. Vaikutuskartoituksella (engl. impact mapping) voidaan tuottaa skenaarioita, joilla KPI-tavoitteisiin päästäisiin. Näistä voidaan sitten valita houkuttelevimmat prioriteettilistan kärkeen product discovery- ja tuotekehitystyöhön.
Tällä tavalla muodostuu tuoteorganisaation joustava ja oppiva strategia liiketoiminnallisten tavoitteiden saavuttamiseksi. Ja tuoteorganisaatio palauttaa tällä tavalla toimijuuden tunteen itselleen.
2. Voidaan jäsentää ja järkeistää tuotebacklogi
Tuoteomistajien ja muiden tuoteihmisten arjen aikasyöppö on tuotebacklogin mikromanagerointi. Tällä tarkoitan sitä, että usein tuotebacklogilla on:
- paljon ideoita tulevista ominaisuuksista, joiden tekemistä ei ole vielä aikataulutettu,
- todella monentasoisia asioita rinnakkain, joita pitää priorisoida keskenään (uusia ominaisuuksia, korjauksia, vanhojen toteutusten häntiä jne.),
- puutteita ja muita asioita, joille ei ehkä koskaan löydy sopivaa toteutusajankohtaa tai
- uusimmat kehityskohteet pilkottuna kehitystiimien taskeiksi asti.
Tai jopa jonkinlainen yhdistelmä näitä kaikkia. Se, mikä näitä yhdistää, on se, että tälläinen tuotebacklogin sisältö vaikeuttaa backlogin hallintaa ja priorisointia. Ja kun sanon että vaikeuttaa, niin tarkoitan sitä, että jo tuotebacklogin sisällön läpikäyntiin menee huomattavasti aikaa viikottain. Puhumattakaan priorisoinnista ja hallinnasta.
Mitä sitten haluttuina seurauksina ilmaistut tavoitteet voivat tuoda tähän? Ne antavat toisen tavan hallita ja priorisoida tuotekehitystä tuotebacklogin lisäksi.
Kun tuoteorganisaatiolla on priorisoitu lista haluttuina seurauksina esitettyjä tavoitteita, vain tällä hetkellä tärkeimpiin tavoitteisiin liittyvät ratkaisut tarvitsee viedä tuotebacklogille. Ideaalitilanteessa tavoitteita olisi tietysti työn alla vain yksi kerrallaan.
Joka tapauksessa ratkaisujen, uusien ominaisuuksien, kehitystaskien jne. linkittäminen tavoitteisiin auttaa järjestämään tuotebacklogia niin, että sen mikromanagerointitarve vähenee.
3. Voidaan tehdä product discovery -työtä järjestelmällisesti
Product discoveryllä tarkoitetaan sitä tuotekehityksen työtä, joka pyrkii kasvattamaan liiketoiminta- ja asiakasymmärrystä parempien tuotekehityspäätösten tekemiseksi. Product discovery jää usein liian vähälle huomiolle tuoteorganisaatiossa.
Hyvä yleiskatsaus product discoverystä löytyy Teresa Torresin kirjasta Continuous Discovery Habits sekä Torresin Product Talk -sivustolta.
Haluttuina seurauksina esitetyt tavoitteet tarjoavat product discovery -työlle selkeän fokuksen: hankkia lisäymmärrystä siitä, mitä tarpeita, haasteita jne. asiakkaat kokevat tavoitteen kuvaamaan teemaan liittyen. Ja mitä mahdollisuuksia tämä ymmärrys luo tuotekehitykselle.
Jos esim. tavoitteena on vuositilausten jatkamisprosentin (engl. traction eli pito) kasvattaminen, voidaan product discovery -työ keskittää tähän:
- haastatellaan vuositilaajia ja pyritään saamaan selville, kuinka hyödylliseksi he palvelun kokevat
- hankitaan eri tavoin tietoa vuositilauksen lopettamisen syistä
- hankitaan lisäymmärrystä niistä tilanteista, joissa asiakkaat eivät koe saaneensa palvelusta vastinetta rahoilleen
- kartoitetaan kerätyn ymmärryksen pohjalta mahdollisuuskarttaa (opportunity map) siitä, millaisia asiakkaiden haasteita paremmin ratkaisemalla voitaisiin vaikuttaa asiakkaiden kokemukseen palvelun hyödyllisyydestä
- ideoidaan ratkaisuoptioita niihin mahdollisuuksiin, jotka nähdään tärkeimmiksi
- validoidaan ratkaisuoptioita kevyesti asiakkaiden kanssa
Tälläinen järjestelmällinen product discovery -työ tukee tuotekehityksen ratkaisukehityspuolta (product delivery) siinä, että valitaan oikeat asiat kehitykseen.
Kiinnostaako kuulla lisää tästä aiheesta?
Tämä kirjoitus jatkaa sarjaa tuoteorganisaation johtamisesta: kuinka luodaan yhteistä ymmärrystä ja isoa kuvaa niin, että itseohjautuvat tuotetiimit voivat edistää tehokkaasti yhteistä visiota.
Lähestyn aihetta niin, että kirjoituksesta hyötyisivät sekä isompien organisaatioiden tuote- ja liiketoimintaihmiset kuin startupeissakin toimivat. Lisäksi mielestäni tämä aihe on tärkeä myös product ownereille sekä agilevalmentajille.
Jos aihe kiinnostaa, tilaa itsellesi päivitykset mailiboksiisi uusista postauksista tähän sarjaan laittamalla osoitteesi alle:
Otsikkokuva: Sarah Wolfe, Unsplash
Antti Kirjavainen
Antti Kirjavainen