Alussa olivat idea, tiimi ja MVP

Minimum Viable Productilla tarkoitetaan tekeillä olevan palvelun mahdollisimman yksinkertaista versiota, jolla voi suorittaa vain palvelun kaikkein olennaisimman toiminnon. Ideana on siis julkaista palvelun ensiversio mahdollisimman pian, alkaa kerätä käyttäjiltä dataa heti ja kehittää palvelua tämän datan perusteella.

”MVP on usein designin suhteen kompromissi. Siinä ei käytetä aikaa monimutkaisten transitioiden ja animaatioiden tekemiseen vaan testataan ensin, onko tekeillä olevalle palveluratkaisulle ylipäätään kysyntää”, sanoo Qvikin UX-suunnittelija Aura Palmgren. ”Hienot transitiot ja muut tehdään vasta, jos toiminto todetaan hyödylliseksi.”

Ennen kuin mitään lähdetään kehittämään on kiteytettävä, mikä tekeillä olevan palvelun perimmäinen idea on. Kaikkein olennaisimpien toimintojen ja yksinkertaisuuden löytäminen ei ole helppo tehtävä. Julkaisijan näkökulmasta on järkevää keskittyä siihen, mikä tekee sovelluksesta käyttäjälle ajankohtaisen ja lisää avauskertojen määrää.

Suurimpia etuja MVP-julkaisutavassa ovat turhan työn välttäminen ja käyttäjiltä oppiminen. Jos palvelua aletaan heti devaamaan monelle alustalle ja viimeisen päälle viilatulla designilla, saatetaan heittää hukkaan valtava määrä työtunteja. Kun tuotekehitys pohjataan MVP:stä kerättyyn tietoon, voidaan kaiken aikaa tietää, että muutoksen suunta on oikea ja työ tuottaa tulosta.

MVP = ruma sovellus?

MVP-työmalli ei tarkoita, että tehtäisiin huono, ruma ja vajavainen palvelu ja odotettaisiin käyttäjien ottavan sen avosylin vastaan. Monesti kuitenkin juuri rajan vetäminen julkaisukelpoisen MVP:n ja yleisölle vielä liian rouhean version välille on haastavaa. Jos versio on liian alkeellinen ja kökkö, ei sen pohjalta tehtyyn käyttäjätutkimukseenkaan voida luottaa.

”Onnistunut MVP on versio, josta on riittävästi hyötyä sekä käyttäjälle että julkaisijalle, mutta jonka tekeminen onnistuu nopeasti”, Palmgren sanoo. ”Tässä tarvitaan aika paljon rohkeutta ja luottoa julkaisijan puolelta.”

Onnistuneessa MVP:ssä on tavoitettu hyvän palvelun olennaisimmat piirteet. Lähde: Jussi Pasanen

Kevyt sovellus mahdollistaa, että sen jatkuva kehitys ja muokkaus onnistuu. Kun ensimmäinen versio on ulkona, on oppiminen ja mahdollinen suunnan muuttaminen nopeampaa – omat olettamukset voidaan todentaa oikeiksi tai vääriksi vain kokeilun kautta. Pidemmän päälle MVP-lähestymistapa on riskienhallinnaltaan tehokkaampaa ja säästää huomattavia määriä aikaa ja rahaa.

Riskienhallinta MVP:n avulla. Lähde: Lukas Fitti

Menestyksen mittarit antavat suunnan

Projektin alkuvaiheessa on hyvä tunnistaa, mitkä ovat palvelun konkreettiset tavoitteet ja milloin siihen ollaan tyytyväisiä. Jotta tätä pystytään seuraamaan, on luotava järjestelmä, jossa oppiminen käyttäjiltä ja itse prosessista onnistuu. Analytiikan ja käyttäjähaastattelujen avulla saadaan kerättyä tietoa, jonka perusteella uusia ja parempia päätöksiä voidaan tehdä – kunhan tärkeimmät mittarit on päätetty. Yleisesti näitä menestyksen mittareita kutsutaan KPI:ksi, eli Key Performance Indicatoreiksi.

Selkeiden KPI:den avulla voidaan luoda palautelooppi, jonka avulla MVP:n kehitystä ohjataan oikeaan suuntaan ja joka auttaa keskittymään olennaiseen. Keskeisimpiä KPI:tä miettiessä on toki osattava vastata myös muihin palvelun kannalta olennaisiin kysymyksiin.

Mittareita määrilteltäessä on olennaista, ettei keskitytä vain niin sanottuihin turhamaisuusmittareihin. Jos katsotaan esimerkiksi vain latauskertojen määrää, nähdään kaiken aikaa vain nouseva käppyrä, joka ei kuitenkaan kerro meille paljoa itse sovelluksesta. Latausmäärä on sinänsä sovelluksen kannalta hyvä mittari, mutta sen lisäksi pitää ottaa huomioon myös, miten usein sovellukseen palataan ja mitä sovelluksessa itse asiassa tehdään.

Ennen kaikkea on määriteltävä, mikä on se liiketoiminnallinen tavoite, jonka takia sovellus on olemassa, ja kuinka eri mittarit korreloivat tämän kanssa.