MVP (Minimum viable product) on käsite, jonka jokainen teknologialalla työskentelevä tuntee. Sillä viitataan tuotteen ensimmäiseen julkaisukelpoiseen versioon, josta on karsittu kaikki paitsi olennainen. Termi toistuu niin usein, että se alkaa tuntua itsestään selvältä. Ja juuri siinä piilee ongelma.
Projektipäällikkönä olen vuosien varrella oppinut, että teknologian, aikataulujen, budjetin ja laajuuden rinnalla on syytä varmistaa että kaikilla osallisilla on sama käsitys siitä, mitä "minimum" oikeastaan tarkoittaa.
Kun asiakas kuulee sanan MVP, hän kuvittelee usein kevyen mutta viimeistellyn tuotteen, jonka voi huoletta antaa käyttäjien eteen heti julkaisupäivänä. Toimisto taas saattaa ajatella huomattavasti raakileempaa versiota, joka sisältää ainoastaan tärkeimmät toiminnallisuudet, ja jonka on tarkoitus kehittyä sen mukaan, miten se osoittautuu toimivaksi oikeassa käytössä. Jos kukaan ei pysähdy tarkistamaan, kumpi näistä tulkinnoista – tai jokin niiden välimuoto – on oikeasti kehitteillä, lopputulos voi olla pettymys kaikille osapuolille. Asiasta sopiminen ajoissa on kaikkien etu.
Miten tähän sitten käytännössä päästään? Ensinnäkin on tärkeää ymmärtää, että MVP:n sisällön määrittely ei ole pelkkä tekninen skouppauskysymys. Se on ennen kaikkea suunnitteluhaaste, jonka ratkaiseminen edellyttää aitoa ymmärrystä siitä, mitä asiakas yrittää saavuttaa.
Esimerkiksi: ammattilaisille suunnattu työkalu on eri asia kuin sovelluskaupassa huomiosta kilpaileva kuluttajasovellus. Koulutetun henkilöstön käyttämän sisäisen alustan ei tarvitse olla visuaalisesti viimeistelty heti ensi metreillä, mutta B2C-tuotteessa näyttävä ensivaikutelma voi hyvinkin olla korkea prioriteetti. "Minimum viable" on siis aina kontekstisidonnainen asia.
Tämä on myös yksi syy sille, miksi huolellinen discovery-vaihe maksaa itsensä takaisin. Kun liiketoimintatavoitteet ovat selkeät ja kohderyhmä on ymmärretty kunnolla, päätökset siitä, mikä on ydintoiminnallisuutta ja mikä mukavaa höystettä, ovat paljon helpompia tehdä ja perustella.
Asia, josta kannattaa puhua ajoissa vaikka se tuntuisi hankalalta, on kysymys siitä onko MVP tarkoitettu skaalautuvaksi. On totta, että MVP on useimmiten pohja, joka kehittyy vähitellen valmiiksi tuotteeksi. Mutta joskus on perusteltua rakentaa versio, jolla testataan oletuksia ja kerätään käyttäjäpalautetta, ja joka myöhemmin rakennetaan olennaisilta osin uudelleen. Näissä tapauksissa esimerkiksi tekninen velka tai mutkien oikominen kehityksessä eivät välttämättä ole samalla tavalla kriittisiä tekijöitä.
Parhaan ratkaisun löytäminen ei ole aina ilmeinen päättelyketju, ja eri MVP-strategioiden haitat ja hyödyt kannattaa käydä läpi avoimesti – digitaaliset tuotteet kun ovat monitasoisia kokonaisuuksia, ja pohdinnoissa voi päätyä yllättävän syviin vesiin.
Jonkun on myös ohjattava nämä keskustelut – ja se vastuu kuuluu tuotteistuksen, suunnittelun ja kehityksen avainhenkilöille. Odotusten hallinta ei ole pelkkä pehmeä taito, vaan osa projektin ydintoimintaa. Kun keskustelut käydään ajoissa ja niihin palataan säännöllisesti, positiiviset vaikutukset tuntuvat vielä pitkään MVP:n julkaisun jälkeenkin.
Onko MVP:n rakentaminen yrityksessäsi ajankohtainen teema? Ota yhteyttä – autamme sinua määrittelemään järkevästi mitoitetun kokonaisuuden.
