Jos tuotteesi ensijulkaisu ei nolottanut, saatoit tehdä jotain väärin
Tuotekehityksessä ajan trendi on MVP.
Mikä ihmeen MVP, saatat kysyä. Kuulostaa vitsaukselta jostain markkinointihelvetin sadististen lyhennelmien ylijäämävarastosta.
MVP:tä ei pidä sekoittaa VMP:hen (Urbaani sanakirja kertoo mistä on kyse, jos ei välittömästi muistu mieleen), vaikka moni huudahtaakin tässä vaiheessa MVP:stä että ”VMP!” ja sihtailee jo sivulta pois siirtymistä. Älä siirry vielä, sillä nyt tulee hyvää asiaa.
MVP – kelpoisuuden vähimmäistaso
Minimum Viable Product on joillekin tuttu HBO:n mainion komediasarjan Silicon Valley avausjaksosta, mutta markkinoinnin ja tuotekehityksen parissa askartelevat ovat tutustuneet käsitteeseen jo 2000-luvun alkupuolelta lähtien.
MVP-käsitettä kosketeltiin ohimennen jo edellisessä blogikirjoituksessa. MVP:llä tarkoitetaan sitä vähimmäistasoa, jolla tuote on kaupallisesti elinkelpoinen. Toisin sanoen, se suurin piirtein toimii, tuottaa ostajalleen jotain lisäarvoa ja on järkevän hintainen valmistaa sekä myös myydä.
Yleisesti käytetty MVP-vertaus kuvaa tuotekehitystä potkulaudasta polkupyörään ja lopulta moottoripyörään. Toisin sanoen, jokainen kehitysversio tarjoaa täysin toimivan tuotteen sen sijaan, että ensimmäisessä vaiheessa myyntiin tulisi vain moottoripyörän bensatankki ja vaihdelaatikko.
Facebookin perustaja Mark Zuckerbergin taas on sitä mieltä, ”jos et ole nolona ensimmäisestä tuotejulkaisustasi, olet tehnyt sen liian myöhään”. Tämä tarkoittaa sitä, että vaikka MVP on myyntikelpoinen ja toimiva tuote, se ei ole alkuunkaan täydellinen versio.
Kyse on optimipisteen hakemisesta siinä rajapinnassa, jossa tuote lakkaa olemasta betaversio itsestään, mutta sen päällä ei kannata istua enää sekuntiakaan kauempaa. Ominaisuuksia voi hioa vaikka maailman tappiin, mutta jossain vaiheessa rahaa on alettava tulla myös yritykseen sisään eli tuote on saatava markkinoille.
Tuote on aina toimiva, sinä et
Kun hyväpalkkaiset ihmiset ratkovat monimutkaisia ongelmia, on projektin tavoitteet määriteltävä hyvin.
Selkeiden tavoitteiden lisäksi myös menetelmillä on väliä. Lopputuloksen kannalta on merkitystä, kehitetäänkö tuotetta omalaatuisilla “häxäyksillä” vai skaalauksen kestävillä oppikirjamenetelmillä.
MVP-periaatteessa oleellista on tarjota aina markkinoille täysin toimiva tuote. Jos poikkeat raiteelta niin pahasti, että rikot tuotteesi, olet lukenut oppikirjoja väärin.
Tällaista on sattunut isoillekin yrityksille. Brellan kehityksessä olemme minimoineet tämän riskin eristämällä testattavan ominaisuuden omalle hiekkalaatikolleen.
Ostetaanko ulkoa vai tehdäänkö itse?
Oli lopputuote mikä tahansa, on useita tapoja toteuttaa se. Yksittäinen koodauskokeilu saattaa olla joskus niin mainio, että siitä voi kehittää oman tuotteensa. Mutta miten tätä lähdetään toteuttamaan tyhjältä pöydältä, niin että tuotteen skaalaus ei aiheuta ongelmia?
Esimerkiksi, 100 käyttäjän skenaario on hyvin erilainen verrattuna miljoonan käyttäjän tilanteeseen. Periaatteessa tuote toimii aina samoilla parametreillä, mutta kehitysvaiheessa on myös otettava huomioon palvelun käyttäjistä aiheutuva tekninen taakka. Sillä on ratkaisevaa merkitystä, että onko onlinessa sata vai miljoona ihmistä.
On arvokasta kyetä arvioimaan realistisesti sitä, miten paljon esimerkiksi seuraavan kahden vuoden ajan käyttäjiä on ja miten paljon he käyttävät tiettyä ominaisuutta. Tuote saattaa käyttää kolmannen osapuolen tarjoamaan rajapintaa, joka maksaa paljon, mutta jonka kehittämiseen talon sisällä ei ole resursseja.
Pahimmassa tapauksessa kolmas osapuoli vetää töpselin seinästä ja tuotteesi lakkaa toimimasta. Kahden vuoden päästä taas tilanne voi olla toinen, ja palvelu voidaan toteuttaa omana projektina.
Konkreettinen esimerkki. Brella pyörii palvelinalustalla nimeltä Heroku. Äärimmäisen hyvä palvelu. Voit luoda ominaisuuksia tai skaalata nappia painamalla. Loistavaa asiakaspalvelua, ei mitään moitittavaa.
Mutta: laadusta täytyy maksaa. Onko meidän järkevämpää maksaa Herokulle siitä, että piinkovat ammattilaiset huolehtivat palvelimien pystyssä pysymisestä vai pystytämmekö palvelimet omaan takahuoneeeseen, ja otamme samalla kantaaksemme kaikki ne tehtävät, mitä niiden konfigurointi ja ylläpito vaatii.
Toisin sanoen, MVP:tä on myös sen hahmottaminen, että mikä kannattaa pitää oman tuotekehityksen piirissä, ja mikä kannattaa ostaa ulkoa. Rajapintoja on nykyään niin paljon ja niin monenlaisia, että näiden priorisointi on välttämätöntä.
Rakennatko oman rekisteröitymisjärjestelmän vai tehdäänkö ”Sign in with Facebook”? Kirpputori-appissa Facebookin avulla kirjautuminen riittää, mutta viranomaistietojärjestelmissä tätä ei toivottavasti edes harkita.
