Minimum Lovable Productia (MLP) käsittelevän blogisarjan viimeisessä osassa sukellamme digitaalisen tuotteen elinkaarivaiheeseen. Nyt olemme siinä vaiheessa, että ”vähimmäinen” on jo saavutettu ja tuote tulisi julkaista ja sitä pitää jatkokehittää ja/tai ylläpitää.
Kun MLP-tuote on valmis ja ehkä jo käytössä, on seuraava askel laajentaa sen ominaisuuksia kohti viimeistellympää kokonaisuutta. Tällöin keskitymme teknisen vakauden parantamiseen ja niiden lisäominaisuuksien toteuttamiseen, jotka jätimme alkuvaiheessa pois.
Tuotteesta riippuen tavoite voi olla joko varmistaa, että kertaluontoinen tuote on vakaa ja helposti ylläpidettävä sen koko elinkaaren ajan, tai kuten useimmissa tapauksissa – jatkaa kehitystä ja rakentaa entistä parempaa tuotetta rakastettavan perustan päälle.
Tuotteen julkaisu
Jos luit tämän blogisarjan aikaisemmat osat, niin tiedät, että alkuvaiheen kehitysprosessi on toteutettu tiiviissä yhteistyössä eri käyttäjäryhmien kanssa. Rakastettavan tuotteen myötä nämä alkuvaiheen käyttäjät voivat toimia ohjelmistosi parhaimpina lähettiläinä. Tämä voi näkyä esimerkiksi tuotteen laajempana käyttöönottona yritysympäristössä tai kuluttajasovelluksen varhaisina omaksujina.
Vaikka moni päätös tässä vaiheessa on tekninen, erityisesti skaalautuvuuteen kannattaa kiinnittää huomiota. Jos tuotteesi menestyy, joudut ratkaisemaan infrastruktuuriin liittyviä haasteita. ”Konepellin alla” olevat ongelmat, kuten kuormantasauksen tarpeet ja lisääntyvät datamäärät, voivat hidastaa vasteaikoja ja heikentää käyttökokemusta, joka aiemmissa testiryhmissä teki tuotteestasi rakastettavan. Nämä ovat yleisiä ohjelmistokehityksen haasteita, mutta vältettävissä rakastettavuuteen panostamalla. Pienetkin käyttöliittymän häiriöt voivat vahingoittaa mainettasi tärkeiden alkuvaiheen käyttäjien silmissä. Huonot ensivaikutelmat ovat erityisen vaikeita korjata hyviksi jälkeenpäin, olipa kyse sanallisesta palautteesta tai käyttäjän suorasta kokemuksesta.
On myös mahdollista, että käyttäjätestaus joka johti rakastettavaan lopputulokseen, on sisältänyt jotain huomaamatonta, joka ei välttämättä heijastu todellisiin käyttäjäryhmiin. Silloin on tärkeää selvittää, edustaako testausvaiheen käyttäjäryhmä todellista käyttäjäkuntaa vai onko tarpeen miettiä uutta suuntaa. Mitkä ovat tuotteesi rakastettavat ja vähemmän rakastettavat ominaisuudet? Mitä kannattaa säilyttää ja mistä kannattaa luopua?
Rakastettavan tuotteen ylläpitäminen ja sen jatkokehittäminen
Rakastettavuus on kontekstisidonnainen ominaisuus. Kun ohjelmisto saavuttaa elinkaarensa ylläpitovaiheen, pitäisi olla selvää, mihin rakastettavuus oikeastaan perustuu. Se voi tarkoittaa esimerkiksi ”konepellin alla” olevia teknisiä asioita, kuten nopeita vasteaikoja, jotka edellyttävät erityistä huomiota infrastruktuurin ylläpidossa ja skaalautuvuudessa.
Tekninen velka on hankala asia, joka voi hallitsemattomana kasvaa eksponentiaalisesti ja muodostua kehityksen esteeksi. Tämä voi johtaa siihen, ettei uusia päivityksiä ja ominaisuuksia pystytä toimittamaan halutussa aikataulussa. Tässä vaiheessa on tärkeää ymmärtää, mikä tekee tuotteestasi rakastettavan: missä tuotannon alkuvaiheessa otetut oikopolut alkavat kostautua merkittävästi? Esimerkiksi nopea ja huolimaton tietokantaratkaisu saattaa olla järkevää päivittää hajautettuun ja skaalautuvaan järjestelmään, jos se estää rakastettavan tuotteen kaatumisen siinä vaiheessa, kun ohjelmisto saavuttaa alkuperäistä laajemman käyttäjäkunnan. Toisaalta rakastettava tuote voi houkutella innokkaita käyttäjiä, jotka vaativat uusia ominaisuuksia – ja viivästykset taas saattavat turhauttaa heitä. Esimerkkejä tällaisista tilanteista löytyy usein peliteollisuudesta.
Usein kuitenkin käyttäjäkokemus (UX) käy läpi muutoksia jatkuvan kehityksen myötä. Jatkuvasti kehittyvän ohjelmiston kohdalla on houkutus lisätä yhä uusia ominaisuuksia eri käyttötarkoituksiin tai liittää ohjelmisto eri ulkoisiin palveluihin. Tällainen ylimääräinen kuorma voi kuitenkin heikentää käyttäjäkokemuksen rakastettavuutta, muuttaen yksinkertaisen ja selkeän käyttöliittymän sekavaksi ja raskaaksi kokonaisuudeksi. Toisaalta lisäominaisuudet voivat olla juuri sitä mitä käyttäjät haluavat tai tarvitsevat. Voimme kuitenkin integroida uusia elementtejä rakastettavuutta vaarantamatta. Tapauskohtaisesti tämä voi tarkoittaa esimerkiksi muokattavaa käyttöliittymää käyttäjän tarpeisiin tai harvemmin käytettyjen ominaisuuksien siirtämistä erillisiin näkymiin.
Vaikka houkutus lisätä uusia ominaisuuksia on suuri, on tärkeää miettiä, voimmeko toteuttaa ne rakastettavasti. Jos tuotteen pääominaisuudet on tehty huolella ja rakkaudella, kömpelö ominaisuus erottuu samalla tavalla kuin tahmea välilyöntinäppäin näppäimistössä. Toisaalta liiketoiminnallisia päätöksiä on pakko tehdä: ovatko ominaisuudet kömpelyyden arvoisia? Monissa tapauksissa vahva ydintuote ja sujuvat peruskäyttötapaukset tekevät tuotteesta käyttökelpoisen, vaikka mukana olisi joitakin harvoin käytettyjä mutta hieman vaivalloisia ominaisuuksia.
Tie eteenpäin
Usein MLP-tuotteet tähtäävät kasvuun. Kasvun saavuttamiseksi on monia keinoja, mutta jokaisella vaihtoehdolla on omat sudenkuoppansa ja vaatimuksensa. Sovelluksen rakastettavuuden säilyttäminen on itsessään liiketoimintapäätös, joka sisältää kustannuksia, mutta saattaa samalla auttaa säilyttämään kilpailuedun. Tapauksissa, joissa ohjelmistoa kehitetään ennalta määrättyyn käyttötarkoitukseen, kuten joukkoliikenteen lippu- ja reittipalvelu, päätös korostaa rakastettavuutta ja helppokäyttöisyyttä jatkuvassa kehityksessä vaikuttaa suoraan käyttäjien elämään. Tämä voi puolestaan toimia parhaana mahdollisena referenssinä työnne laadusta.
Lopuksi
Rakastettavien tuotteiden rakentaminen vaatii aikaa ja työtä. Monet kehittäjät saattavat väittää, että MLP:n tulisi olla jokaisen ohjelmistotuotteen lähtökohta, sillä miellyttävien asioiden rakentaminen on monille kehittäjille innostavampaa.
Totuus on kuitenkin se, että joskus nopeat ja ei niin viimeistellyt ratkaisut voivat olla tehokkain vaihtoehto esimerkiksi tilanteissa, joissa käyttäjät eivät välitä käyttöliittymän ulkoasusta, vaan haluavat vain saada työnsä tehdyksi. MLP ei ole ratkaisu jokaiseen ohjelmistoon, jonka aiotte rakentaa, mutta aina kun tavoitteena on voittaa käyttäjät puolelleen ja pitää heidät, ajattelutavan muuttaminen rakastettavan tuotteen rakentamiseen saattaa olla oikea valinta.
Toivomme, että olemme tarjonneet näkemyksiä tehokkaasta tuotekehityksestä rakastettavalla tavalla.
Kiinnostuitko? Kerromme mielellämme lisää miten me Identiolla voisimme auttaa teitä luomaan jotain rakastettavaa käyttäjillenne.
Osa 1: Näin rakennamme Minimum Lovable Productin vuonna 2025 – ymmärryksen saavuttaminen
Osa 2: Näin rakennamme Minimum Lovable Productin vuonna 2025 – sovelluksen kehittäminen
Osa 3: Näin rakennamme Minimum Lovable Productin vuonna 2025 – tuotteen julkaisu
