ODI ja palautematriisi - priorisoinnin apuvälineitä tuotehallintaan
Outcome-driven innovation (ODI) ja palautemateriisi ovat loistavia tuotehallinnan eli priorisoinnin välineitä. Niistäkään ei ole kuitenkaan apua jollei niiden käyttöön raivaa aikaa.
Mitä käyttäjät ihan ihan oikeasti tarvitsevat ja mitä taas eivät? Siinä tuoteomistajan tuhannen taalan kysymys, kun pohditaan niukkojen resurssien eli kehitysajan ja -budjetin käyttöä asiakastarpeiden täyttämiseksi niin, että myös liiketoiminta on tyytyväinen.
Priorisointimatriisit ovat tuttua tavaraa, joiden suurimpana ongelmana on usein se että niitä ei käytännössä tule käytettyä. Ja tämä ei ole mikään ihme, kun miettii minkälaisen palautteiden vyöryn keskellä tuoteomistaja usein tekee työtään. Oikeasti hyödyllisten välineiden pitää olla ehkä hiukan hienojakoisempia, jotta kaaos oikeasti järjestyisi. Seuraavassa tällaiseksi oikeasti hyödylliseksi työvälineeksi kaksi erilaista ehdotusta.
Outcome-driven Innovation (ODI) kun käytössä kattavaa käyttäjädataa
Outcome-driven innovation (ODI) on huikea priorisointinäkemyksen muodostamisen työkalu silloin, kun käytössä on paljon käyttäjädataa joko analytiikasta tai käyttäjätutkimuksesta. Monesti tämä on todellisuutta esim. tuotekeskeisissä organisaatioissa, joissa käyttäjän kokemuksen tutkimiseen on hyvä rutiini ja siihen investoidaan.
Opportunity-driven innovation -menetelmän voi tiivistää kahteen kysymykseen.
Jos jobs to be done -ajattelulle rakentavan ODI:n ajatuksen pelkistää vielä loppuun linkattua blogiartikkeliakin tiiviimmäksi, se mahtuu kahteen pointtiin:
Selvitetään, miten tärkeä kukin palvelun toimintokokonaisuus on käyttäjälle
Selvitetään, kuinka tyytyväinen käyttäjä on siihen tällä hetkellä
Tästä yksinkertaisesta ristiintaulukoinnista saadaan selville, mihin paukut kannattaa laittaa: niihin toimintokokonaisuuksiin, jotka ovat käyttäjille tärkeitä mutta joihin he eivät tällä hetkellä ole tyytyväisiä.
Samalla monesti tulee havaintoja siitä, että moni asia joita oli varauduttu hieromaan, eivät itse asiassa käyttäjien näkökulmasta enää vaadikaan lisäkehittämistä.
Palautematriisilla spontaani palautetulva järjestykseen
Tuotehallinta eli tuoteomistajan priorisointityö tapahtuu monesti ympäristössä, jossa huudetaan lujaa monelta suunnalta. Kaikille oma kokemus ja omat tarpeet on se kaikkein tärkein.
Kun yritetään miettiä, mihin palautteista kannattaisi reagoida ja minkä verran, avuksi analysointiin voi tulla palautematriisi. Ideana on yksinkertaisesti suhteuttaa palauteaiheet toisiinsa: Miten isoa ja tärkeää käyttäjäryhmää palautteen antaja edustaa? Miten paljon käyttöä hankaloittava ongelma on kyseessä? Miten usein käyttäjä tähän ongelmaan törmää?
Palautematriisi auttaa määrämuotoistamaan palautteen
Kymmenien tuhansien käyttäjien päivittäin kohtaama ongelma ansaitsee erilaiset kehityspaukut kuin muutamien käyttäjien kuukausittain kokema. Ja vaikka tämä kuulostaa yksinkertaiselta periaatteelta, huutomyrskyn keskellä palautteiden suhdetta toisiinsa on joskus aika vaikea erottaa ennen kuin niitä alkaa järjestelmällisesti verrata toisiinsa. Tähän palautematriisi voi tuoda hyvän avun.
Vain ne priorisointivälineet auttavat joita oikeasti käytetään
Kuten alussa totesimme, yleisin priorisointiapuvälineiden ongelma on että niitä ei käytännössä käytetä. Tähän syynä on usein ajan puute - jos tuoteomistaja yrittää pitää juuri ja juuri nenän pinnalla sprinttien vilistessä, analyysiin ei välttämättä jää juurikaan aikaa ennen kuin on jo pakko hyökätä kirjoittamaan auki kehitysjonon kohtia kehitystiimille.
Niinpä tärkein systemaattisen priorisoinnin tae on, että kalenterista löytyy säännöllisiä yhtenäisiä työaikoja käyttäjäpalautteen käsittelyyn, analysointiin ja työstämiseen kehitystiketeiksi. Ketteryyskielessä tätä kutsutaan usein kehitysjonon työstöksi, ja on hyvä muistaa että sen kannattaa tapahtua monella aika- ja abstraktiotasolla - välillä myös irrallaan seuraavan sprintin hyväksymiskriteereistä.
Lähteitä ja työkaluja
Kattavampi artikkeli Outcome-driven innovation -menetelmästä (englanniksi)