Ominaisuuksien paisuminen: mitä se on ja miten sitä ehkäistään

Meillä kaikilla on ollut ainakin yksi tuote, jota emme yksinkertaisesti saaneet julkaistua, koska tuntui aina olevan ”vielä yksi ominaisuus” lisättävänä. Joskus toimitusjohtaja lisäsi uusia ominaisuuksia laajuuteen. Toisille kyse oli jokaisen yksittäisen käyttäjäpyynnön huomioimisesta.

Syystä riippumatta olemme kaikki kokeneet loistavien tuotteiden hiljaisen tappajan – ominaisuuksien paisumisen.

Et voi kuvitellakaan, kuinka moni lupaava tuote on vajonnut kuiluun, koska kehitys- ja tuotetiimit eivät pystyneet julkaisemaan niitä ajoissa, samalla kun ne rakensivat tarpeettomia ominaisuuksia.

Jotta voisit välttää tämän yleisen sudenkuopan, selitän, mitä ominaisuuksien paisuminen tarkoittaa ja miten sitä voi torjua yksinkertaisilla taktiikoilla, kuten muutostenhallinnalla ja esihenkilöiden hallinnalla.

Mitä ominaisuuksien paisuminen (tai laajuuden paisuminen) tarkoittaa?

Kun ympärilläni puhutaan tuotteesta, joka kärsii ominaisuuksien paisumisesta, kuvittelen aina sen huolimattomasti täytetyksi olennoksi, jolla on ylimääräisiä ruumiinosia ja joka yrittää kävellä kaikkien lisäosien painon alla. Kun pyysin uutta (ja varsin vaikuttavaa) ChatGPT-kuvageneraattoria herättämään tämän mielikuvan eloon, se loi tällaisen kuvan.

P.S., tekoäly on itse asiassa varsin hyvä ideoimaan hyödyllisiä tuoteominaisuuksia, jos asia kiinnostaa.

Toisin sanoen ominaisuuksien paisuminen tarkoittaa ominaisuuksien hallitsematonta lisäämistä tuotteeseen ilman konkreettista visiota tai suuntaa. Se johtaa usein siihen, että julkaisujono kasvaa nopeammin kuin ominaisuuksia saadaan julkaistua.

Tilanteesta käytetään usein myös termiä laajuuden paisuminen. Näitä kahta termiä käytetään usein toistensa synonyymeina, mutta niiden välillä on hienoinen ero.

• Laajuuden paisuminen viittaa yleensä ominaisuuksien loputtomaan lisäämiseen julkaisusuunnitelmaan, mikä aiheuttaa viivästyksiä.
• Ominaisuuksien paisuminen keskittyy enemmän lopputulokseen – Frankensteinin hirviötä muistuttavaan tuotteeseen, jota on vaikea navigoida tai käyttää.

On olemassa myös kolmas samankaltainen termi – ominaisuustehtaan loukku. Käsittelemme sitä kuitenkin artikkelin lopussa olevassa kysymys- ja vastausosiossa.

Merkkejä ominaisuuksien paisumisesta

Ominaisuuksien paisumisen tärkeimmät oireet tuotteessasi ovat yleensä ilmeisiä ja helposti havaittavia. Joitakin selviä merkkejä ovat:

• Julkaisun laajuus kasvaa ilman selkeää selitystä sille, miksi tarvitsemme uusia ominaisuuksia.
• Julkaisujen viivästymiset johtuvat laajuuteen lisätystä toiminnallisuudesta.
• Sidosryhmäsi hallitsevat julkaisun laajuuden hallintaa hyväksymättä EI-vastausta.

Ominaisuuksien paisumisen vaara on siinä, että se on joskus salakavala ilmiö, jota on vaikea huomata ennen kuin on liian myöhäistä.

Jos et havaitse näitä merkkejä, tarkoittaako se, että olet turvassa ominaisuuksien paisumiselta? Ei oikeastaan. Ominaisuuksien paisumisen vaara on siinä, että se on joskus salakavala ilmiö, jota on vaikea huomata ennen kuin on liian myöhäistä. Tämä tarkoittaa, etteivät jotkin sen oireista ole helposti tunnistettavissa. Tässä niistä kaksi:

• Jatkuvat laajuuden muutokset. Laajuuden muuttaminen on Lean- ja ketterien menetelmien todellisuudessa hyväksyttävää. Joskus myös 1–2 ominaisuuden lisääminen julkaisun laajuuteen on hyväksyttävää, koska ymmärrät, että käyttäjälle tuotettava arvo menetetään ilman niitä. Kun julkaisun laajuus kuitenkin kasvaa jatkuvasti eikä lisäominaisuuksilla ole käyttäjälle suurta arvoa, kyse on ominaisuuksien paisumisesta.
• Sidosryhmät painostavat rakentamaan tuotteen lopullisen version. Ymmärrän, ettei beta- tai MVP-versio tuo sidosryhmillesi tuloja. Siksi on luonnollista, että he pitävät MVP:tä ajanhukkana ja haluavat keskittyä sen sijaan lopulliseen versioon. Lopullisten versioiden rakentaminen ilman, että MVP:n käyttäjät validoivat ensin ydintoiminnot, on kuitenkin varma tapa rakentaa asioita, joita ihmiset eivät tarvitse.

Kun tarkastelemme näitä oireita lähemmin (erityisesti hienovaraisia oireita), monet meistä ymmärtävät, ettei heidän kaoottinen projektin laajuutensa ole ”ketteryyttä”. Se on vanhaa kunnon ominaisuuksien paisumista.

Hyvä on, mutta miten tähän päädyttiin? Näytti siltä, että teit parhaasi pitääksesi laajuuden hallinnassa. Tarkastellaan yleisiä (ja yllättäviä) syitä, joiden vuoksi tuotteet kärsivät laajuuden paisumisesta.

Miksi ominaisuuksien paisumista tapahtuu?

Tässä sitä ollaan, kaikista taustajonon hallintaan kohdistuneista ponnisteluistasi huolimatta. Miten tähän päädyttiin? Useimmiten ominaisuuksien paisumisen perimmäisiä syitä on vaikea huomata ja vielä vaikeampi korjata pelkällä laajuuden hallinnalla.

The truth about project scope creep

Kun tarkastelen mutkaista polkua, jota kutsun urakseni, ymmärrän, että myös minä olen saanut osani ominaisuuksien hallitsemattomaan lisääntymiseen liittyvistä tapauksista. Taustalla olleet syyt eivät tuolloin olleet ilmeisiä. Suurin osa näistä opeista oli kantapään kautta opittuja läksyjä, jotka syntyivät juniorivuosinani yrityksen ja erehdyksen kautta. Mutta kun tarkastelen näitä tapahtumia nyt johtavan PM:n näkökulmasta, näen, missä asiat menivät pieleen.

Yleensä ominaisuuksien hallitsematon lisääntyminen tapahtuu jostakin seuraavista syistä:

• Sidosryhmien paine: Toisin sanoen ”Lisätään vielä yksi asia, ja siinä se”. Olet kuullut sen, minä olen kuullut sen. Joskus sidosryhmät ajattelevat, etteivät pienet muutokset laajuuteen vaikuta julkaisupäivään, koska kyse on jostakin todella pienestä. Ongelma on siinä, että pienimmänkin muutoksen on käytävä läpi koko koodin tarkistus-, laadunvarmistus- ja CI/CD-putki, mikä voi kestää päiviä.
• PM:t eivät sano tarpeeksi usein EI: Tiedän, että se on vaikeaa – etenkin silloin, kun sidosryhmille täytyy esittää vastalauseita. Useimmat heistä kuitenkin perääntyvät mielellään ideastaan, jos annat heille selkeän selityksen kompromisseista. Jos pystyt muuttamaan heidän ”pienen pyyntönsä” lisäajaksi, ylimääräisiksi laadunvarmistussykleiksi, suunnitteluresurssien tarpeeksi ja julkaisuaikatauluun kohdistuvaksi mahdolliseksi riskiksi, he ymmärtävät, ettei kyse ole vain nopeasta hienosäädöstä – vaan investoinnista, jolla on todellisia seurauksia.
• Jokaiseen asiakkaan pyyntöön suostuminen: Se on houkuttelevaa – erityisesti silloin, kun yrität voittaa kauppoja, pitää arvokkaat asiakkaat tai osoittaa olevasi valmis reagoimaan. Kaiken asiakkaiden pyytämän rakentaminen ei kuitenkaan tee tuotteestasi parempaa. Se tekee siitä vain paisuneen, epäjohdonmukaisen ja vaikeammin ylläpidettävän.
  
  Karua totuutta? Kaikki palaute ei ole yhtä arvokasta. Erinomaiset tuotetiimit tietävät, milloin toimia, milloin siirtää asiaa myöhemmäksi ja milloin päästää siitä irti – sillä jokaisella ”kyllä”-vastauksella on hintansa: tärkeää on luoda selkeä asiakaspalautesilmukka, joka auttaa priorisoimaan palautetta strategisesti ja pysymään linjassa tuotteesi vision kanssa.
• Kilpailupaine: Se, että kilpailija julkaisi näyttävän tekoälyominaisuuden, ei tarkoita, että sinun täytyy väkisin lisätä jotakin vastaavaa nykyiseen julkaisuusi. Liian nopeasti reagointi johtaa usein puolivalmiisiin ominaisuuksiin, jotka eivät todellisuudessa muuta tilannetta – ja mikä vielä pahempaa, ne voivat suistaa etenemissuunnitelmasi raiteiltaan, heikentää tuotteen laatua ja viivästyttää julkaisuja. Vahva tuotejohtaminen tarkoittaa usein sen tietämistä, milloin on syytä pysähtyä, arvioida tilanne ja suojella rakenteilla olevan tuotteen eheyttä.
• Selkeän laajuuden puuttuminen: Varhainen yhteisymmärrys siitä, mikä kuuluu mukaan ja mikä ei, on keskeistä aikataulusi suojelemiseksi. Se alkaa yhteisen laajuusymmärryksen rakentamisesta vankkojen Scrumin tuotehallintakäytäntöjen avulla.
• Ylisunnittelu: Ylisunnittelu alkaa usein hyvistä aikomuksista – tulevaisuudenkestävyydestä, optimoinnista ja kollegoiden vaikutuksen tekemisestä – mutta päättyy hauraisiin järjestelmiin, joita kukaan ei täysin ymmärrä. Todellinen taito ei ole monimutkaisen rakentaminen. Se on sen tietäminen, milloin sitä ei pidä tehdä. Tuotehallinnan keskeisten parhaiden käytäntöjen omaksuminen voi auttaa tiimejä keskittymään arvon tuottamiseen ilman tarpeetonta monimutkaisuutta.
• Kaikkien käyttötapausten kattaminen: Kaikki loppukäyttäjäsi eivät ole samanarvoisia. Jotkut ovat ”arvokkaampia kuin toiset” (toisin sanoen he tuovat sinulle enemmän rahaa). Tässä on Aha!-yrityksen perustajan ja toimitusjohtajan Brian de Haaffin sitaatti aiheesta käyttäjäpalautteen ja liiketoimintatavoitteiden tasapainottaminen.

Kun tarkastelet yllä olevaa luetteloa, huomaat todennäköisesti muutaman syyllisen piilevän omassa tuotteessasi. Vaikka ne saattavat yksittäin vaikuttaa harmittomilta, yhdessä ne nakertavat hiljalleen keskittymistäsi, etenemisnopeuttasi ja tuotteesi eheyttä.

Kuinka paljon ominaisuuksien hallitsematon lisääntyminen maksaa sinulle?

Lyhyt vastaus? Paljon! Ominaisuuksien hallitsemattomaan lisääntymiseen liittyy piilokustannuksia, jotka heikentävät hiljalleen tuotteesi laatua, suorituskykyä ja tiimin moraalia. Vaikka sen vaikutus käyttäjäkokemukseen on niin haitallinen, että se ansaitsee oman osionsa, tarkastellaan ensin muita tapoja, joilla se heikentää tuotettasi.

Julkaisuaikataulujen myöhästyminen

Markkinoille saapumisen nopeus on usein tärkeämpää kuin viimeistely. Opin tämän kantapään kautta rakentaessani ensimmäistä tekoälyominaisuuttani. Olin pakkomielteisen keskittynyt saamaan virheprosentin 0 %:iin, mutta toimitusjohtajani muistutti minua jatkuvasti: ”Sen ei tarvitse olla täydellinen – sen täytyy vain olla julkaistu.”

Hän oli oikeassa. Julkaisimme nopeasti, ja vaikka ominaisuus oli viimeistelemätön, olimme ensimmäisiä. Koska olimme kilpailijoistamme ensimmäisiä, jotka julkaisivat sen, ihmiset alkoivat yhdistää kyseisen tekoälyominaisuuden (kyse oli puheluiden yhteenvedoista; julkaisimme sen paljon ennen Microsoft Teamsia ja muita) brändiimme. Siksi monet jatkoivat työkalumme käyttöä, vaikka Teams julkaisi ominaisuuden, koska he olivat jo tottuneet siihen.

Tuo varhainen julkaisu toi meille bränditunnettuutta ja etumatkaa käyttökokemuksen hiomisessa kilpailijoiden vasta yrittäessä pysyä perässä. Jos olisimme odottaneet, olisimme saattaneet menettää tilaisuuden kokonaan.

Lisäksi koska julkaisimme ensimmäisinä, saimme etumatkaa ominaisuuden kehittämisessä ja viimeistelyssä, kun muut vasta julkaisivat ensimmäisiä, viimeistelemättömiä versioitaan.

Ominaisuuksien paisuminen hidastaa tiimejä – ja kuluttaa ne loppuun

Jokainen lisäämäsi ominaisuus ei ainoastaan vie aikaa rakentaa, vaan se lisää kuormaa kaikkeen, mitä sen jälkeen tehdään. Ajan myötä tuotteesi arkkitehtuuria on yhä vaikeampi hahmottaa. Pienetkin muutokset voivat käynnistää odottamattomien riippuvuuksien ketjureaktion tietomalleissa, käyttöliittymissä, testeissä ja työnkuluissa. Tämän seurauksena uusien ominaisuuksien julkaiseminen kestää kauemmin, virheiden korjaamisesta tulee riskialttiimpaa ja luottamus koodikantaan heikkenee.

Tämä hiipivä monimutkaisuus ei vaikuta vain toimituksiin – se heikentää myös työilmapiiriä. Kun tiimit joutuvat selvittämään poikkeustapauksia tai varomaan vanhojen päätösten seurauksia, tekemisen vauhti hiipuu. Ja kun julkaisut lykkääntyvät jatkuvasti laajenevan laajuuden vuoksi, on helppo tuntea, ettei mikään valmistu koskaan. Siitä työuupumus alkaa – ei kovasta työstä, vaan työstä, joka tuntuu johtavan ei mihinkään.

Miten ominaisuuksien paisuminen vaikuttaa UX:ään

Ominaisuuksien paisumisen vaikutus UX:ään on niin merkittävä, että minun on käsiteltävä sitä erillisessä osiossa. Hyvä käyttäjäkokemus on yksi tuotteesi menestyksen ratkaisevista tekijöistä, ja siihen kannattaa kiinnittää paljon huomiota. Loppujen lopuksi jokainen hyvän käyttäjäkokemuksen rakentamiseen käytetty dollari voi tuoda sinulle takaisin 100 dollaria tuloina.

Haluat tietenkin tehdä kaikkesi välttääksesi UX:ääsi vahingoittavia tekijöitä, mukaan lukien pelätyn ominaisuuksien paisumisen.

Mutta miten ominaisuuksien paisuminen tarkalleen ottaen vahingoittaa UX:ääsi? Näin:

Käyttöliittymän ylikuormitus

Ironista kyllä, useammat ominaisuudet eivät tarkoita parempaa tuotetta. Päinvastoin, liian monien asioiden lisääminen tuotteeseen heikentää sen käytettävyyttä.

Logiikka on tässä yksinkertainen – käytettävyys liittyy suoraan siihen, kuinka selkeä ja kevyt käyttöliittymäsi on. Ominaisuuksien paisuessa päädyt puolestaan ahtamaan käyttöliittymääsi kymmeniä ominaisuuksia painikkeineen, mikä tekee siinä navigoinnista vaikeaa.

Hienoissa tuotteissa jokaisella käyttäjäpolun näytöllä on yksi päätarkoitus. Kaikki kyseisen näytön elementit, jotka eivät palvele päätarkoitusta, häiritsevät käyttäjää ja vaikeuttavat hänen tavoitteensa saavuttamista. Siksi mitä vähemmän toissijaisia käyttöliittymäelementtejä sinulla on, sitä paremmaksi käytettävyys muuttuu.

Otetaan esimerkiksi tämä asuntolainan ennenaikaisen takaisinmaksun laskuri.

Jokainen tämän käyttöliittymän elementti palvelee yhtä tarkoitusta – auttaa sinua laskemaan asuntolainan takaisinmaksun. Siksi sitä on helppo käyttää, vaikka näkisit sen ensimmäistä kertaa. Siinä ei ole ylimääräisiä ominaisuuksia, jotka voisivat hämmentää tai kuormittaa sinua.

Katsotaan nyt Jiran automaatioeditoria.

Sattuivatko silmäsi pelkästään sen katsomisesta? Minun silmiäni ainakin sattuivat! Myönnän, että kyseessä on tehokas ominaisuus, jossa on paljon toimintoja. Atlassian onnistui kuitenkin lisäämään ne kaikki yhteen käyttöliittymään, mikä tekee siinä navigoinnista hieman pelottavaa.

Jiran automaatio on siis elävä todiste siitä, miten liian monien ominaisuuksien luominen (eli ominaisuuksien paisuminen) heikentää käytettävyyttä.

Suorituskyvyn heikkeneminen

Käyttöliittymän navigoinnin vaikeuttamisen lisäksi ominaisuuksien paisuminen voi myös hidastaa tuotettasi merkittävästi.

Jokainen rakentamasi uusi ominaisuus sisältää ylimääräistä JavaScriptiä käyttäjän selaimen jäsennettäväksi sekä taustajärjestelmän logiikkaa palvelimiesi käsiteltäväksi. Siksi suuren määrän vähäarvoisia ominaisuuksia lisääminen kuormittaa sekä käyttäjien laitteita että palvelimiasi.

Tuotteen hidastuminen on yksi merkittävimmistä käytettävyysongelmista, joita voi esiintyä. Amazonin kuuluisa tutkimus osoitti, että 100 millisekunnin hidastuminen maksoi heille yhden prosentin tuloista.

Ominaisuuksien hallinnan (ja niiden hallitsemattoman lisääntymisen estämisen) ohjeet

Ominaisuuksien hallitsematon lisääntyminen haittaa tuotteesi kehitystä, ja sitä tapahtuu jatkuvasti. Hyvä uutinen on kuitenkin se, että sitä on myös melko helppo hallita ja ehkäistä (kun tiedät miten).

Tässä on kuusivaiheinen ohje sen pitämiseksi kurissa.

1. Perusta jokainen päätös tuotevisioon

Kun tuotteelta puuttuu selkeä, yhteinen visio, jokainen idea voi tuntua perustellulta – ja juuri näin ominaisuuksien hallitsematon lisääntyminen alkaa. Visio antaa tiimeille luvan keskittyä. Se määrittelee paitsi sen, mitä rakennetaan, myös sen, mitä ei rakenneta.

Otetaan esimerkiksi Figma. Alkuvaiheessa tiimi teki tietoisen päätöksen pysyä selainpohjaisena, vaikka monet käyttäjät pyysivät natiivisovellusta työpöytätietokoneille. Päätöksessä ei ollut kyse palautteen sivuuttamisesta, vaan sitoutumisesta pitkän aikavälin visioon saavutettavuudesta ja reaaliaikaisesta yhteistyöstä. Jos he olisivat myöntyneet jokaiseen pyyntöön, he olisivat saattaneet menettää juuri sen erottavan tekijän, joka teki tuotteesta Figman.

Vahva visio ei ole olemassa inspiroimista varten – se on suodatin. Ilman selkeää visiota priorisoinnista tulee neuvottelua. Sen avulla voit sanoa luottavaisesti ”ei vielä” – tai ”ei lainkaan”. On selvää, mikä ei kuulu mukaan.

2. Priorisoi tinkimättömästi tiekartan avulla

Asianmukaisesti toteutettu priorisointi on toinen tapa välttää ominaisuuksien hallitsematonta lisääntymistä. Avainsana tässä on ”asianmukaisesti toteutettu”. Se, että joka toiseen ominaisuusideaan lisätään merkintä ”pakollinen”, ei ole priorisointia.

Välttääksesi tämän tilanteen tarkastele visiotasi ja käyttäjiesi keskeisiä tarpeita. Jos ominaisuusidea ei edistä molempia samanaikaisesti, se ei mitä todennäköisimmin ole pakollinen.

Priorisointikehyksistä omat suosikkini ovat nämä kaksi:

MoSCoW: Yksinkertainen ideoiden luokittelu seuraaviin ryhmiin: ”pakollinen”, ”pitäisi olla”, ”voisi olla” ja ”ei toteuteta”. MoSCoW-menetelmällä priorisoitu tehtävälista näyttää tältä:

RICE: Se on taulukko, jossa jokainen rivi on ominaisuusidea ja jokainen sarake edustaa seuraavaa:

• Käyttäjien määrä, jota ominaisuus palvelee (tavoittavuus)
• Kuinka hyvin se ratkaisee käyttäjien ongelmia (vaikutus)
• Kuinka varma olet ominaisuuden onnistumisesta (luottamus)
• Sen rakentamiseen tarvittavat resurssit (työmäärä).

Tältä se näyttää:

Molemmat näistä viitekehyksistä ovat riittävän yksinkertaisia, jotta voit priorisoida tehtäväjonosi laskentataulukossa tai esitystiedostossa. Suosittelen kuitenkin käyttämään sen sijaan erityisesti tuotehallintaan tarkoitettua työkalua (esimerkiksi Aha!- tai ProdPad-työkalua), sillä ne automatisoivat suurimman osan työstäsi ja integroituvat tehtävienhallintaohjelmistoosi.

3. Vahvista ominaisuudet ennen niiden rakentamista

Kokemukseni perusteella ideoiden validointi on yksi tehokkaimmista tavoista torjua hyödyttömät ominaisuusideat. Se on erityisen hyödyllistä silloin, kun sidosryhmät painostavat sinua. Jos heillä on idea, jonka he haluavat sinun toteuttavan, validoi se ensin.

Idea joko läpäisee validoinnin, jolloin ymmärrät, että se kannattaa rakentaa, tai se epäonnistuu ja sinulla on empiiristä näyttöä, jonka voit esittää sidosryhmillesi kertoessasi heille EI.

Validoinnissa voit käyttää seuraavia lähestymistapoja:

1. Haastattele käyttäjiä selvittääksesi, tarvitsevatko he sitä.
2. Rakenna klikattavia prototyyppejä ja anna käyttäjien kokeilla niitä sekä antaa sinulle palautetta.
3. Tee A/B-testejä saadaksesi analyyttistä tietoa siitä, käyttävätkö ihmiset ideaa vai jättävätkö he sen huomiotta.
4. Rakenna ominaisuudesta MVP (minimitoimiva tuote) -versio, julkaise se ja testaa sitä.

Tämän luettelon lähestymistavat etenevät edullisimmasta (haastattelut) kalleimpaan (MVP). Siksi neuvoni on aloittaa ensimmäisestä vaihtoehdosta. Sen avulla voit hylätä huonon ominaisuusidean käyttämättä siihen liikaa aikaa ja vaivaa.

4. Aseta laajuudelle rajat ja pidä niistä kiinni

Yksi keino on myös yksinkertaisesti kieltäytyä muuttamasta julkaisun laajuutta. Ei tosin täysin kieltäytyä, vaan pitää alkuperäinen laajuus ennallaan, ellei esiin tule jotakin kriittistä, joka on tehtävä. 

Ainoa hyväksyttävä syy muuttaa laajuutta on se, kun huomaat, ettei alkuperäinen suunnitelmasi pysty kattamaan käyttötapausta, jota varten ominaisuus on rakennettu.

Oletetaan esimerkiksi, että olet tekemässä verotusasiakirjojen käsittelyyn tarkoitettua tekoälytyökalua ja se tukee vain kuvatiedostoja. Ymmärrät jossakin vaiheessa, että monet verotusasiakirjat ovat PDF-tiedostoja eivätkä kuvia. Jos PDF-tiedostoja ei tueta, ominaisuudestasi tulee hyödytön. Tässä tilanteessa laajuutta on hyväksyttävää muuttaa.

Tämä prosessi tunnetaan muutostenhallintana, ja se on erinomainen työkalu laajuuden hallitsemiseen.

5. Kouluta ja saavuta yhteisymmärrys sidosryhmien kanssa

Puolen tusinan toimitusjohtajan kanssa työskentelyyn perustuvan kokemukseni mukaan useimpia ei haittaa kuulla sanaa ”ei” – kunhan pystyt perustelemaan miksi.

Johtajat haluavat edetä nopeasti, mutta he luottavat sinuun tuodessasi esiin sen, mitä seurauksia pieneltä vaikuttavalla pyynnöllä voi olla.

Mary Abbajay teoksessa Managing Up

Et tarvitse dramaattista puolustuspuhetta – riittää, että ilmaiset kompromissit selkeästi. Kun he näkevät, miten pyyntö voisi viivästyttää toimitusta tai vaarantaa muita tärkeitä tavoitteita, useimmat eivät vain kunnioita vastalausettasi, vaan ovat tyytyväisiä siihen, että joku ajattelee välitöntä kyllä-vastausta pidemmälle.

 6. Tarkasta ja karsi säännöllisesti

Me kaikki tiedämme, että tehtäväjonot pitäisi pitää siisteinä, mutta niiden on helppo antaa paisua puolivalmiiden ideoiden ja kauan sitten unohdettujen ominaisuuspyyntöjen hautausmaiksi. Sen sijaan että suhtautuisit tehtäväjonon jalostamiseen neljännesvuosittaisena syyllisyysrituaalina, ajattele sitä säännöllisenä ylläpitona – kuten kasvien kastelemista tai kuvakaappausten poistamista työpöydältä.

Yksi yllättävän hyödyllinen harjoitus (malta vielä hetki) on se, mitä kutsun nimellä tuotepuun karsiminen. Kuvaat tuotteesi ominaisuudet puun osina – runkona, oksina ja lehtinä – ja päätätte tiiminä, mikä kukoistaa, mitä pitää karsia ja mistä voidaan luopua. 

Se on visuaalista, yhteistyöhön perustuvaa ja oudolla tavalla tyydyttävää – ja se saattaa auttaa sinua vihdoin tekemään rauhan tehtäväjonosi kanssa.

Tosielämän esimerkkejä ominaisuuksien paisumisesta

Monet meistä ajattelevat, että ominaisuuksien paisuminen on harvinaista tai jotain, mitä kohtaamme uramme alkuvaiheessa ja opimme sitten hallitsemaan. Ei suinkaan. Jopa teknologiajätit ja lupaavat startup-yritykset ovat päätyneet tilanteeseen, jossa ominaisuuksien paisuminen on ollut lähellä niiden tuotteiden tuhoamista. Tässä on pari tunnettua esimerkkiä.

Esimerkki 1: Windows Vista

On olemassa teoria, jonka mukaan Microsoft epäonnistuu joka toisessa Windows-versiossa. XP oli mahtava. Siksi Vistasta tuli luonnollisesti katastrofaalinen.

Niin kävikin. Se oli paisunut ja yli-insinööröity käyttöjärjestelmä, joka vaati liikaa laskentatehoa ja oli tunnetun epävakaa.

Yksi syy tähän sekavaan julkaisuun oli toiminnallisuuksien paisuminen. Microsoft halusi parantaa kaiken kerralla yhdessä uudessa julkaisussa. He lisäsivät hienostuneen käyttöliittymän, muuttivat tietoturva-arkkitehtuuria, halusivat täyden taaksepäinyhteensopivuuden ja hienoja pienoisohjelmia.

Kaiken tämän seurauksena ihmiset kieltäytyivät päivittämästä XP:stä Vistaan. PC-maailma piti sitä epäonnistumisena, ja Microsoft pystyi palauttamaan maineensa vain julkaisemalla hämmästyttävän seuraajan Vistalle – Windows 7:n.

Esimerkki 2: Google Wave

Rehellisesti sanottuna en koskaan ymmärtänyt, mistä tässä tuotteessa oli kyse. Google Waven kerrotaan olevan työkalu, joka mahdollistaa reaaliaikaisen yhteistyön esimerkiksi asiakirjojen kaltaisten aineistojen parissa. Minä kuitenkin näen sen järjestäytymättömänä kasana hämmästyttäviä mutta merkityksettömiä ominaisuuksia.

Se on loistava esimerkki jonkin rakentamisesta ilman visiota ja strategiaa. Kyllä, Google Waven reaaliaikaiset yhteistyöominaisuudet päätyivät Google Docsiin ja niistä tuli sen keskeinen ominaisuus, joka ratkaisi todellisia käyttäjien tarpeita. Alkuperäinen tuote oli kuitenkin vain joukko yhteen niputettuja ominaisuuksia, joilla ei ollut käytännöllistä tarkoitusta.

Esimerkki 3: Snapchatin uudelleensuunnittelu

Kun Snapchat julkaisi valtavan käyttöliittymäuudistuksensa vuonna 2018, ihmiset raivostuivat.

Syy siihen, ettei kukaan pitänyt uudesta ulkoasusta, oli muiden tämän luettelon esimerkkien tavoin se, että siinä oli aivan liikaa ominaisuuksia ilman selkeää suuntaa. Snapchat-tiimi keskittyi niin paljon lukuisten ”hienojen” ominaisuuksien lisäämiseen, että se unohti täysin johdonmukaisten käyttäjäpolkujen ylläpitämisen.

Seurauksena oli paljon hämmennystä, kun ihmiset eivät löytäneet uudesta käyttöliittymästä haluamaansa ominaisuutta.

Milloin toiminnallisuuksien laajentaminen on hyvä asia

Kuten olen aiemmin maininnut, kaikki laajuuden kasvattaminen ei ole pahasta. On harvinaisia tapauksia, joissa uusien ominaisuuksien lisääminen julkaisun laajuuteen on hyväksyttävää.

Nyrkkisääntönä on, että uuden ominaisuusidean on täytettävä samanaikaisesti nämä kolme kriteeriä, jotta se voidaan sisällyttää laajuuteen:

• Käyttäjät ovat validoineet sen. Kokeiltuaan prototyyppejäsi tai MVP:täsi käyttäjät ovat huomauttaneet, että tietty ominaisuus puuttuu ja että se on heille tärkeä.
• Se on strategian mukainen. Käyttäjien pyytämä ominaisuus edistää visiotasi ja strategiaasi.
• Sinulla on varaa toteuttaa se. Tämän ominaisuuden lisääminen ei siirrä julkaisuaikataulua merkittävästi, ja yrityksessäsi on riittävästi ylimääräisiä työntekijöitä sen rakentamiseen.

Jos huomaat, että ominaisuusideasi täyttää nämä kolme kriteeriä, se on todennäköisesti todella tärkeä, ja sen huomiotta jättäminen johtaa julkaisun jälkeen huonoon käyttökokemukseen. Joten sen lisääminen laajuuteen on hyväksyttävää.

Miten otamme hyvät ideat talteen suistamatta keskittymistämme raiteilta?

Hyvät ideat eivät aina noudata etenemissuunnitelmaasi. Ne ilmaantuvat kesken sprintin, kahvikeskustelun aikana tai ”nopeana Slack-viestinä”, joka ei ole lainkaan nopea. Haasteena ei ole ideoiden pysäyttäminen – vaan sen tietäminen, miten niitä voi säilyttää ilman suunnan menettämistä.

Näin pidät oven avoinna antamatta laajuutesi lipsua:

• Varaa paikka ideoille, jotka eivät ole ajankohtaisia nyt. Se voi olla työjono-sarake, tiimin dokumentti tai Notion-taulu — mikä tahansa työnkulkuusi sopiva ratkaisu. Olennaista on, että se on näkyvillä, sitä tarkastellaan säännöllisesti eikä sitä kohdella hautausmaana. Näin tiimi voi sanoa ”kyllä, mutta myöhemmin” sen sijaan, että se sanoisi ”toki, ujuttakaamme tämä mukaan”.
• Käytä viitekehyksiä, jotka osoittavat prioriteetin eivätkä vain säilytä asioita. Tuotepuut, Nyt/Seuraavaksi/Myöhemmin-taulut tai tasoitetut tiekartat auttavat havainnollistamaan kompromisseja. Kun joku lisää uuden idean, voit osoittaa taulua ja sanoa: ”Tämä on hyvä idea — tässä on sen paikka.” Se auttaa kaikkia säilyttämään yhteisen kontekstin.
• Arvioi ideoita harkitusti, älä reaktiivisesti. Varaa säännöllisesti aikaa ideoiden uudelleenarviointiin. Käykää muutaman viikon välein läpi, mitä on tullut sisään. Mikä on muuttumassa kiireellisemmäksi? Mikä on edelleen kiinnostavaa mutta ei hyödyllistä? Tämä rytmi antaa hyville ideoille tilaa kypsyä — ja suodattaa melun pois.
• Kerro sidosryhmille selkeästi, mikä otetaan mukaan ja mikä siirretään myöhemmäksi. Jos joku tärkeä henkilö tuo sinulle ominaisuuspyynnön, älä jätä sitä huomiotta. Kuittaa se, kerro, mihin se sopii (tai ei sovi), ja varmista, että se kirjataan ylös. Kun ihmiset tietävät, että heidän palautettaan arvostetaan — vaikka sen toteutusta siirrettäisiin — he todennäköisemmin kunnioittavat myös keskittymistäsi.

Yhteenvetona: kaikkea ei tarvitse julkaista heti. Tallenna ideat huolellisesti, älä paniikissa. Tuleva tiekarttasi kiittää sinua.

Johtopäätös: käytä visiota suodattimena, älä muurina

Ominaisuuksien paisuminen ei johdu ideoista — kyse on kompromisseista. Jotkin uudet pyynnöt ovat toteuttamisen arvoisia jopa kesken sprintin. Ilman selkeää visiota ja prosessia vaikutusten punnitsemiseen sanot kuitenkin vain kyllä melulle.

Kun uusi ominaisuus tulee esiin, älä kysy vain:

”Pitäisikö meidän rakentaa tämä?”

Kysy:

”Mitä jää rakentamatta, jos teemme tämän?”

Se on todellinen kustannus. 

Mitä seuraavaksi

Muista tilata uutiskirjeemme saadaksesi lisää tuotehallinnan resursseja ja oppaita sekä uusimmat podcastit, haastattelut ja muut alan johtajien ja asiantuntijoiden näkemykset.