Jos minulta kysytään, kaksi tärkeintä tuotehallinnan taitoa ovat prioriteettien tunteminen ja "ei."-sanan sanominen
Tänään perehdymme ensin mainittuun (sillä jälkimmäinen ansaitsee oman oppaansa) ja autamme sinua priorisoimaan työsi sekä pitämään kaikki linjassa prioriteettiesi kanssa.
Tärkeä huomautus tuoteominaisuuksien priorisointikehyksistä
Ennen kuin alamme tutkia tapoja priorisoida työlistaasi, haluan jakaa kanssasi yhden tärkeän vinkin.
Priorisointikehyksiä ei ole tarkoitettu tulkittaviksi kirjaimellisesti.
Ei, sinun ei tarvitse käyttää sitä täsmälleen siinä muodossa kuin se on kirjoitettu kirjassa (tai tässä oppaassa). Johtamasi tuote saattaa olla täysin erilainen kuin tuotteet, joita kirjoittaja johti kirjaa kirjoittaessaan. Erilaiset tuotteet tarkoittavat erilaisia todellisuuksia ja tarpeita. Siksi on täysin hyväksyttävää mukauttaa kehystä omiin tarpeisiisi. Loppujen lopuksi hyvä kehys on sellainen, joka toimii sinulle.
Kokeiltavaksi tarkoitettuja tuotteen priorisointikehyksiä
Tiesitkö, että olemassa on Thanoksen priorisointikehys? Poistat vain satunnaisesti puolet kaikista työlistasi ominaisuuksista!
Ei, keksin tuon itse. Mutta ymmärsit pointtini. Erilaisia kehyksiä on yksinkertaisesti aivan liikaa. Niitä on niin paljon, etten mitenkään pysty käsittelemään niitä kaikkia tässä oppaassa. Rehellisesti sanottuna en usko, että olet täällä opetellaksesi ulkoa miljoonaa kehystä.
Siksi käyn sen sijaan läpi ne, joita olen itse käyttänyt tuotehallinnan päivittäisessä työssäni, ja jaan kanssasi pari käytännön vinkkiä jokaisesta. Kannattaa myös pohtia, miten voisit hyödyntää tekoälyä ominaisuuksien priorisoinnissa näiden kehysten rinnalla.
1. Kanon malli
Tämä priorisointimenetelmä on saanut nimensä lahjakkaan japanilaisen kirjailijan ja johdon konsultin Noriaki Kanon mukaan. Hänen lähestymistapansa kauneus piilee sen yksinkertaisuudessa.
Kano ehdotti ominaisuuksien jakamista seuraaviin ryhmiin:
- Pakolliset: Nämä ovat tuotteesi perusominaisuuksia, ja niiden puuttuminen johtaa huonoon asiakaskokemukseen (huono asiakaspysyvyys ja asiakaspoistuma ovat taattuja). Hyvä esimerkki tästä on Intercomin keskusteluominaisuus tai G2:n asiakaspalautteen haku.
- Suorituskyky: Nämä ominaisuudet luovat käyttäjälle arvoa yleisyytensä perusteella. Mitä enemmän niitä on, sitä enemmän arvoa ne tuottavat. Tarkastellaan esimerkiksi nykyaikaisen sähköauton akkukapasiteettia ja toimintasädettä. Parempi toimintasäde (yleensä) tuottaa kuljettajille enemmän arvoa. Toinen esimerkki on Zapierin integraatioiden määrä.
- Houkuttelevat: Sen sijaan, että nämä ominaisuudet tuottaisivat suoraa arvoa ja ratkaisisivat käyttäjien ongelmia, ne keskittyvät tuotteidesi miellyttävyyden parantamiseen. Projektinhallintatyökalun kauniisti suunnitellut tuotevisio-osat tai auton nahkaistuimet ovat esimerkkejä näistä.
Jos visualisoisimme näiden ominaisuustyyppien yleisyyden ja niiden tuottaman asiakastyytyväisyyden välisen suhteen, se näyttäisi jotakuinkin tältä.
Tässä näemme, että suorituskykyominaisuudet ovat luonteeltaan lineaarisia (eli niiden lisääminen tuottaa enemmän arvoa). Pakolliset ominaisuudet puolestaan eivät tuota paljon lisäarvoa. Sen sijaan niiden tarkoitus on poistaa käyttäjien tyytymättömyyttä.
Lopuksi houkuttelevien ominaisuuksien luokka antaa sinulle ylimääräisen tyytyväisyyslisän. Sillä ei kuitenkaan ole mitään vaikutusta, jos olet mokannut jonkin "pakollisen" ominaisuuden kanssa.
Have an account? Log In
Kanon malli käytännössä
Miten Kanon mallia sovelletaan käytännössä? Kokemukseni mukaan Kanoa käytetään harvoin priorisointi- tai ideointikokouksissa. Syynä on se, että kyseessä on erittäin intuitiivinen asia, eikä sitä tarvitse piirtää valkotaululle ja pyytää ihmisiä luokittelemaan ominaisuuksiaan näiden kolmen kategorian perusteella.
Sen sijaan sidosryhmät yleensä opetetaan ajattelemaan Kanon tavalla. Näin ennen kuin he tulevat luoksesi uuden ominaisuuspyynnön kanssa, he käyvät idean mielessään tämän kehyksen läpi ja päättävät, kannattaako sitä tutkia tarkemmin vai ei.
Tällä tavoin delegoit osan ominaisuuksien priorisointityöstä sidosryhmillesi ja säästät valtavasti aikaa pitkissä ideointisessioissa.
2. MoSCoW-menetelmä
MoSCoW-menetelmä on yksi suosituimmista ominaisuuksien priorisointimenetelmistä. Sen suosion taustalla ovat kaksi asiaa: yksinkertaisuus ja tehokkuus.
Tämän menetelmän soveltamiseksi sinun tarvitsee vain tarkastella jokaista luettelossasi olevaa ominaisuutta ja antaa sille yksi näistä neljästä prioriteetista:
- Pakollinen
- Pitäisi olla
- Voisi olla
- Ei tule olemaan
Yleensä määrität nämä prioriteetit useiden tekijöiden yhdistelmän perusteella. Näitä ovat esimerkiksi käyttäjille tuotettava arvo, liiketoiminta-arvo, strateginen yhteensopivuus, toteutuksen monimutkaisuus ja muut tekijät.
Tältä tyypillinen ominaisuuslista näyttää musiikin suoratoistopalvelulle, kun sovellat siihen MoSCoW-menetelmää.
- Tässä olemme määrittäneet offline-tilalle ”pakollisen” prioriteetin, koska monet käyttäjistämme kuuntelevat musiikkia lentokoneessa.
- VR-kokemukset puolestaan saivat prioriteetin ”ei tule olemaan”, koska niiden toteuttaminen on melko vaikeaa ja hyvin harvoilla käyttäjillä on niiden kokemiseen tarvittavat VR-kuulokkeet.
MoSCoW käytännössä
Vaikka voit käyttää MoSCoW-menetelmää tehokkaasti priorisointikokousten ohjaamiseen, siinä on yksi haittapuoli, joka tekee siitä vähemmän tehokkaan tällaisissa tilanteissa.
Koska prioriteetti perustuu useiden tekijöiden yhdistelmään, jokaisen tiimin jäsenen on melko aikaa vievää selittää tuoteratkaisujensa perustelut. Kokemukseni mukaan MoSCoW-istunnot ovat melko hitaita ja tehottomia muihin viitekehyksiin verrattuna.
Se ei kuitenkaan tarkoita, etten pitäisi MoSCoW-menetelmästä. Itse asiassa se on viitekehys, jota käytän useimmiten. Suosikkikohteeni MoSCoW-menetelmän käyttöön on PRD:n ominaisuuslista.
Annan lukijoille yleensä ennen ominaisuuksien listaamista asiakirjassa taustatietoa käyttäjäarvosta, teknisistä monimutkaisuuksista ja muista tekijöistä. Kun he siis näkevät jonkin ominaisuuden vieressä merkinnän ”Pakollinen”, heillä on riittävästi taustatietoa ymmärtääkseen nopeasti päätökseni perustelut.
Näin MoSCoW antaa minulle helposti omaksuttavan ominaisuuslistan tuotevaatimusasiakirjassa.
3. RICE-menetelmä
Toisin kuin kaksi edellistä menetelmää, RICE-pisteytysmalli on hieman jäsennellympi ja vähemmän riippuvainen intuitioon perustuvasta päätöksenteosta. Se tunnistaa neljä erillistä priorisointitekijää ja mahdollistaa niiden kunkin erillisen määrällisen arvioinnin. Nämä tekijät ovat:
- Tavoittavuus: Se ilmaisee niiden käyttäjien osuuden, joihin tämä ominaisuus vaikuttaa.
- Vaikutus: Vaikutuksen suuruus.
- Luottamus: Osoittaa, oletko varma siitä, että tavoitetut ihmiset saavat kyseisen hyödyn.
- Työmäärä: Se on ajanjakso, jonka kehitys- ja tuotetiimisi tarvitsevat tämän ominaisuuden valmiiksi saamiseen.
Yleensä valitset ominaisuuden ja annat sen jälkeen jokaiselle näistä neljästä tekijästä pisteet välillä 0–10. Tämän jälkeen lasket RICE-pisteet tällä kaavalla.
Lopuksi järjestät ominaisuuslistasi tämän viitekehyksen päämittarin eli RICE-pisteiden mukaan (korkeampi pistemäärä = korkeampi prioriteetti). Tältä RICE-priorisoinnin tulos näyttää.
- Tässä listassa näemme, että uusi käyttöliittymä on saanut korkeimman pistemäärän vähäisen työmääränsä ja suuren tavoittavuutensa/vaikutuksensa ansiosta.
- Pilvisynkronointi-ominaisuus puolestaan on listan lopussa, koska sen toteuttaminen vaatii tiimiltäsi paljon työtä.
RICE-pisteet käytännössä
Olen maininnut toistuvasti, etteivät MoSCoW ja Kano sovellu parhaiten priorisointi- ja ideointikokouksiin. Mutta mitä viitekehystä käytän tällaisissa tilanteissa? RICE-menetelmää!
Kun annat kullekin tekijälle erilliset pisteet, ihmisten on helpompi esittää päätöstensä perustelut näissä kokouksissa (mikä puuttuu MoSCoW-menetelmästä). Lisäksi voit antaa kunkin tekijän pisteyttämisen niiden tiimikavereiden tehtäväksi, joilla on kyseisestä alueesta eniten tietoa.
Tuotekehitystiimisi on esimerkiksi paras taho antamaan työmääräpisteet. Data-analyytikkosi puolestaan ymmärtävät parhaiten kyseisen ominaisuuden mahdollisen tavoittavuuden.
4. Käyttäjätarinoiden kartoitus
Teknisesti käyttäjätarinoiden kartoitus ei ole priorisointikehys. Sen sijaan sitä käytetään tiimille tehtävän työn järjestämiseen ja sellaisten ominaisuuksien tunnistamiseen, joita on lisättävä täydellisten käyttäjäpolkujen toteuttamiseksi.
Luodaksesi tarinakartan luettelet keskeiset käyttäjätoiminnot (tai tehtävät) ja kirjoitat sitten ylös tehtävät, jotka käyttäjien on suoritettava niitä varten. Tämän jälkeen luettelet kaikki ominaisuudet, jotka sinun on rakennettava, jotta käyttäjät voivat suorittaa nämä tehtävät. Voit tehdä tämän muistilapuilla valkotaululle tai käyttää jotakin monista tuotepäälliköille tarkoitetuista työkaluista.
Tältä kartta näyttää musiikin suoratoistopalvelun tapauksessa.
Tässä vaiheessa et luultavasti vielä tee juurikaan priorisointia.
Joka tapauksessa kunkin tehtävän edellyttämien ominaisuuksien kirjoittaminen ylös auttaa sinua silti priorisoinnissa, sillä huomaat, että tietyistä toiminnoista puuttuu ominaisuuksia (ja ne ovat sinulle ensisijaisia).
Lisäät sitten nopeasti nämä puuttuvat ominaisuudet työjonoon ja siirrät ne sen kärkeen varmistaaksesi, että kyseinen toiminto on toteutettu käyttäjiäsi varten.
Yllä olevassa esimerkissä meillä on aktiivisesti kehitettävä MVP-tarinakartta (valmiiden tarinoiden nimen vieressä on valintamerkki). Kun tarkastelemme sitä, näemme, että tilinhallintatoiminto on keskeneräinen, koska emme ole vielä rakentaneet sosiaalisen median kirjautumisia.
Ennen kuin aloitamme artistin/albumin haun parissa työskentelyn, meidän pitäisi siis ensin saada tilinhallintatoiminto valmiiksi.
Tarinakartat tosielämässä
RICE-menetelmän tavoin tarinakartat sopivat erinomaisesti priorisointi- ja ideointipalavereihin. Yksi tämän kehyksen tärkeimmistä hyödyistä on sen kyky tuoda käyttäjän näkökulma kokoushuoneeseen.
Käyttäjien toimintoja ja tehtäviä tarkastelemalla tiimikaverisi ehdottavat epätodennäköisemmin ominaisuusideoita, jotka eivät liity asiakkaidesi tarpeisiin ja kipukohtiin. Vaikka he ehdottaisivatkin niitä, voit helposti antaa niille matalan prioriteetin, koska nämä ominaisuudet eivät auta käyttäjiä suorittamaan tehtäviään.
5. Mahdollisuuksien pisteytys
Rakenteeltaan mahdollisuuksien pisteytys muistuttaa RICE-menetelmää. Toisin kuin sen vastineessa, mahdollisuuksien pisteytysjärjestelmän kriteerit eivät kuitenkaan ole kiveen hakattuja, vaan saat itse valita ne.
Jos esimerkiksi haluat sovittaa korkean tason etenemissuunnitelmasi yhteen johdon kanssa, voit käyttää kriteereinä tuotestrategian sopivuutta, toteutettavuutta ja mahdollista liikevaihtoa. Tältä näyttää tällaisella kehyksellä priorisoitu etenemissuunnitelma.
Tässä olemme käyttäneet asteikkoa 0–5 kunkin tekijän pisteyttämiseen ja laskeneet kaikkien tekijöiden summan jokaiselle luettelon kohdalle.
Pisteytyskortit tosielämässä
Omat kriteerit voi valita joustavasti, joten pisteytyskortit sopivat erinomaisesti tiimien välisiin yhteensovittamispalavereihin.
Jos esimerkiksi sinun on sovitettava etenemissuunnitelmasi yhteen laki- ja turvallisuustiimien kanssa ja kuultava heidän näkemyksiään prioriteeteista, valitset heille merkityksellisiä kriteerejä (esim. oikeusjutun riski suhteessa liiketoiminta-arvoon). Markkinointitiimin kanssa voit puolestaan käyttää kriteereinä työmäärää, kustannuksia, liiketoimintatavoitteiden mukaisuutta, markkinapeittoa ja luottamusta.
More Articles
6. Työmäärämatriisi
Muistatko Eisenhower-matriisin, jota käytetään henkilökohtaisten hankkeidesi priorisointiin? Työmäärämatriisi on siitä versio, joka on suunniteltu paremmin uusien tuoteominaisuuksien käsittelyyn.
Sen koko nimi on arvon ja työmäärän matriisi, koska se pystyy havainnollistamaan näiden kahden tekijän suhdetta kunkin tehtäväsi kohdalla. Tältä se näyttää.
Sijoitat työmäärän Y-akselille ja asiakasarvon X-akselille. Tämän jälkeen jaat sen Eisenhower-matriisin tavoin neljään neljännekseen ja sijoitat ominaisuutesi kuhunkin niistä niiden arvon ja työmäärän perusteella. Tämän jälkeen priorisoit tehtäväsi seuraavassa järjestyksessä:
- Nopeat voitot (vaikuttava ominaisuus, jonka voit toteuttaa nyt)
- Suuret hankkeet (strategisesti tärkeät ominaisuutesi)
- Täyteominaisuudet (mahdolliset ominaisuudet, joiden toteutus on kevyt ja joita kannattaa harkita myöhemmin)
Työmäärää kuluttavaan neljännekseen kuuluvat ominaisuudet yleensä hylätään, koska niiden pitämisessä työjonossa ei ole lainkaan järkeä.
Vaivamatriisi käytännössä
Tämän viitekehyksen merkittävin hyöty ja haittapuoli liittyvät sen yksinkertaisuuteen.
Se on hyödyllinen, koska voit helposti selittää priorisointiprosessin huoneessa oleville ihmisille ja alkaa heti valita sen avulla oikeita ominaisuuksia.
Haittapuolena on, ettei vaivamatriisi tuo esiin eri tekijöitä, joilla on merkittävä rooli priorisoinnissa (luottamus, tavoittavuus, riippuvuudet jne.).
Siksi tämän viitekehyksen paras käyttötapaus ovat lyhyet yhteensovittamispalaverit, joissa yksityiskohdilla ei ole merkitystä (sillä yleensä järjestätte jatkoksi perusteellisemman RICE-menetelmää hyödyntävän istunnon).
Saavuta sidosryhmien yhteisymmärrys tuotteen etenemissuunnitelmasta
Työn priorisointi on tärkeää. Siitä ei kuitenkaan ole hyötyä, jos et ole saavuttanut kaikkien yhteisymmärrystä prioriteeteistasi. Monet tänään käsittelemistämme viitekehyksistä ovat luonteeltaan yhteistoiminnallisia ja auttavat saavuttamaan yhteisymmärryksen automaattisesti.
Jos kuitenkin päätät valita viitekehyksen, joka ei edellytä kaikkien sidosryhmien kokoamista samaan huoneeseen, varmista, että olet jakanut priorisoidun luettelosi olennaisten henkilöiden kanssa ja sovittanut sen yhteen heidän odotustensa ja tarpeidensa kanssa.
Älä unohda tilata uutiskirjettämme saadaksesi lisää tuotehallinnan resursseja ja oppaita sekä uusimmat podcastit, haastattelut ja muut toimialan johtajien ja asiantuntijoiden näkemykset.
