Olen melko varma, että lähes kaikki teistä ovat kuulleet MVP-konseptista. On kuitenkin myös hyvin mahdollista, että suurin osa teistä pitää MVP:itä erittäin teoreettisena asiana, jota on harvoin hyödynnetty käytännössä todellisessa maailmassa. Totuus on kuitenkin se, että esimerkkejä elinkelpoisista vähimmäistuotteista on kaikkialla ympärillämme ja monet maailmanlaajuisesti tunnetut ohjelmistotuotteet ovat aloittaneet MVP:inä.
Kokeneena tuotepäällikkönä, jolla on kokemusta MVP:iden rakentamisesta, haluan jakaa muutaman menestystarinan osoittaakseni, kuinka arvokas tämä konsepti voi olla pienelle startup-yrittäjälle.
Mikä on MVP?
Elinkelpoinen vähimmäistuote on yksi Lean Startup -menetelmän keskeisistä elementeistä. Menetelmän on kehittänyt Eric Ries tuotteiden rakentamista varten.
Leanin ja MVP:n taustalla oleva keskeinen ajatus on, että startup-yritykset epäonnistuvat jatkuvasti. Tämän riskin pienentämiseksi sinun kannattaa ensin luoda tuotteestasi hyvin pieni versio, joka sisältää sen keskeiset ominaisuudet, varmistaa, että asiakkaat haluavat käyttää sitä, ja vahvistaa liikeideasi toimivuus ennen kuin ryhdyt kehittämään lopullista tuotetta.
Sukelletaan nyt joidenkin menestyneimpien MVP-esimerkkien tarinoihin.
Esimerkki 1: Dropboxin epätavallinen MVP-kehitysmuoto
Aloitetaan alustasta, jota monet meistä todennäköisesti käyttävät tärkeiden asiakirjojen digitaalisten kopioiden tallentamiseen tai yrityksen tallennustilana kaikelle, jonka parissa tiimisi työskentelee yhdessä.
Pilvitallennuksesta on tullut olennainen osa elämäämme, ja nykyään se on arkipäiväinen ratkaisu sekä henkilökohtaiseen että ammatilliseen käyttöön. Vuonna 2007 tilanne ei kuitenkaan ollut tämä, kun Drew Houston päätti perustaa Dropboxin.
Vaikka Dropbox ei tuolloin ollut markkinoiden ensimmäinen pilvitallennuspalvelu (Box ja Amazon S3 tarjosivat jo vastaavaa palvelua), se oli ensimmäinen, joka tarjosi saumattoman käyttökokemuksen tiedostojen synkronointiin pilven kanssa.
Drew keksi mielenkiintoisen ratkaisun pilvitallennukseen. Sen sijaan, että joutuisit lataamaan ja hakemaan tiedostoja manuaalisesti, Dropbox loisi tietokoneellesi kansion, jonka sisältö pysyisi synkronoituna pilven kanssa. Sinun tarvitsi siis vain lisätä tiedostoja tähän kansioon tai poistaa niitä sieltä – kaikesta muusta huolehti Dropbox.
Tämä kaikki tuntuu meistä nykyään itsestään selvältä, mutta tuolloin se oli jotain hämmästyttävää.
Tällaisen saumattoman käyttökokemuksen luominen tarkoitti kuitenkin sitä, että Drewn tiimin oli kehitettävä työpöytäsovellukset useille käyttöjärjestelmille ja luotava monimutkainen tiedostojen synkronointimekanismi, joka hoitaisi kaiken puolestasi taustalla.
Tämän vuoksi Drew ei voinut kehittää Dropboxista MVP-versiota sovelluksena, sillä jo pienimmänkin ominaisuusmäärän sisältävä sovellus olisi edellyttänyt täysin toimivaa palvelininfrastruktuuria ja sen rakentaminen olisi vienyt hänen tiimiltään paljon aikaa.
Hän halusi kuitenkin todella saada varhaisessa vaiheessa palautetta sekä käyttäjiltä että sijoittajilta, sillä se auttaisi häntä välttämään kalliit virheet sovelluskehitysprosessissa ja rakentamaan jotain, josta markkinat pitäisivät.
Niinpä hän valitsi hyvin epätavallisen lähestymistavan. Hänen MVP:nsä oli esittelyvideo. Aivan oikein: hän loi yksinkertaisesti tuotteestaan selitysvideon, jossa hän näytti, kuinka saumattomasti tiedostojen synkronointi Dropboxin kanssa toimi.
Kun Drew alkoi näyttää tätä videota kohdeyleisölleen, vastaanotto oli paljon parempi kuin hän osasi odottaa. Dropboxin verkkosivuston kävijämäärä nousi useisiin satoihin tuhansiin ja beta-version kokeilemista varten laaditulle jonotuslistalle ilmoittautui 75 000 ihmistä.
Dropboxin opit
Ehkä tärkein opetus, jonka saamme Drew'n ja hänen tiiminsä tarinasta, on se, että ohjelmistostartupien maailmassa on ajateltava laatikon ulkopuolelta eikä saa antaa teknisten rajoitteiden rajoittaa itseään.
Drew tiesi, että eteneminen ilman käyttäjien tarpeiden selvittämistä olisi kohtalokasta. Niinpä hänen oli keksittävä vaihtoehtoinen ratkaisu täysin toimivalle MVP:lle.
Sillä ei oikeastaan ole väliä, millainen MVP:si on. Se voi olla mobiilisovelluksen mallinnos tai rautalankamalli tai WordPressin päälle rakennettu valesivusto. Kunhan valitsemasi MVP-tyyppi auttaa sinua saamaan palautetta ja testaamaan oletuksiasi, olet oikealla tiellä.
Toinen meille tärkeä opetus on, ettei oppimisvaiheen ohittamiselle ja tuotteen jatkuvan kehittämisen laiminlyönnille ole mitään tekosyytä.
Have an account? Log In
Esimerkki 2: Amazonin olematon taustajärjestelmä
Ennen kuin Amazonista tuli ohjelmistoyritysten jättiläinen, se aloitti tunnetusti verkkokirjakauppana.
Mielenkiintoinen osa Amazonin syntytarinaa oli se, ettei Jeff Bezosin visio Amazonista rajoittunut kirjojen myymiseen verkossa. Hänen tavoitteensa olivat paljon suuremmat kuin maailman suurimmaksi verkkokirjakaupaksi kasvaminen, kuten Amazonin nykyinen koko osoittaa.
Syy, miksi hän päätti aloittaa kirjoista, oli varsin käytännöllinen — kirjoja oli helppo löytää ja edullista lähettää kaikkialle maailmaan.
Verkkokaupan luominen on nykyään erittäin helppoa Shopifyn, WooCommercen ja monien muiden valmiiden työkalujen ansiosta. Mutta vuonna 1994, kun Bezos perusti Amazonin, hänen täytyi kehittää koko kauppa käyttöliittymästä taustajärjestelmään täysin alusta alkaen.
Jeffillä ei ollut mahdollisuutta investoida kokonaisen verkkokaupan rakentamiseen. Niinpä hän omaksui startup-yritysten johtamisessa ”Ozin velhon” lähestymistavan. Käyttöliittymä hänellä kuitenkin oli valmiina — verkkokauppa, jossa ihmiset saattoivat selata kirjoja, lisätä niitä ostoskoreihinsa ja tehdä tilauksen.
Taustajärjestelmää ja tilausten automaattista käsittelyä ei kuitenkaan ollut. Kun joku osti kirjan Amazonista, Jeff kävi henkilökohtaisesti ostamassa sen fyysisestä kirjakaupasta ja lähetti sen asiakkaalleen julkisen postipalvelun kautta.
Sen lisäksi, että tämä lähestymistapa mahdollisti Jeffille liiketoiminnan aloittamisen ilman suurta ennakkoinvestointia, hän sai sen avulla myös varhaista käyttäjäpalautetta sekä ylläpitämästään verkkosivustosta että koko tuotteiden verkossa myymisen prosessista.
Jeff sisällytti käyttäjäpalautetta jatkuvasti palveluunsa, ja vuonna 1999 Amazon oli kehittynyt sellaiseksi, jonka tunnemme paremmin.
Käyttäjäpalautteen toteuttamisen lisäksi Jeff alkoi myös tavoitella suurempaa kunnianhimoaan lisäämällä verkkosivustolle uusia tuoteryhmiä. Vuonna 1999 Amazon myi jo musiikkia, videoita, elektroniikkaa, leluja ja muuntyyppisiä tuotteita.
Amazonista opitut asiat
Jeff on yksi vanhan koulukunnan perustajista, jotka aloittivat yrityksensä ”äitinsä autotallissa”. Vaikka hän käytti ”Ozin velhon” lähestymistapaa, koska hänellä ei yksinkertaisesti ollut varaa täysin kattavaan verkkosivustoon, hän noudatti lopulta hyvää käytäntöä selvittämällä ensin, toimiiko liiketoimintamalli, ennen kuin rakensi tuotteen.
Esimerkki 3: Zapposin kassavirtanegatiivinen MVP
Jatketaan verkkokaupan pioneereista ja puhutaan Zapposista, valtavasta verkossa toimivasta vaatteiden ja asusteiden kaupasta, joka tarjoaa kymmeniätuhansia tuotteita ja on tuottanut pari miljardia liikevaihtoa.
Zapposin tarina alkaa vuodesta 1999, jolloin sen perustaja Nick Swinmurn käytti paljon aikaa etsiessään lähikauppakeskuksesta tiettyä kenkäparia, jonka hän halusi, mutta ei löytänyt sitä. Hän ymmärsi nopeasti fyysisten myymälöiden ongelman — niissä on aina saatavilla rajallinen valikoima kenkämalleja, koska laajan valikoiman ylläpitäminen kasvattaisi jokaisen yksittäisen myymälän varastointi- ja varastokustannuksia.
Siksi kenkäbrändit yleensä suosivat vain suosituimpien ja valtavirtaisten mallien esittelyä ja myyntiä useimmissa keskikokoisissa ja pienissä myymälöissään ja pitivät harvinaisemmat mallit saatavilla vain suurimmissa myymälöissään.
Jos siis halusit jotain valtavirrasta poikkeavaa, et löytänyt sitä paikallisesta kauppakeskuksestasi, vaan jouduit matkustamaan pitkän matkan lähimpään myymälään, jossa suosikkibrändisi tuotteita oli saatavilla.
Verkkokauppa sen sijaan pystyy esittelemään käyttäjille teoriassa rajattoman määrän tuotteita riippumatta siitä, asuvatko he pienessä kaupungissa, jossa on pieni kauppakeskus, vai valtavalla metropolialueella, jolla on suurmyymälöitä.
Amazonin Jeffin tavoin Nickillä ei ollut taloudellisia mahdollisuuksia rakentaa kokonaista verkkokauppaa alusta alkaen. Vaikka hän olisi teoriassa voinut pyytää sijoittajilta rahoitusta, hän ei oikeastaan halunnut ottaa riskiä verkkokauppansa epäonnistumisesta ja sijoittajien rahojen lopullisesta menettämisestä.
Siksi hän valitsi saman tien kuin Amazon ja aloitti ”Ozin velhon” verkkosivuston. Nick kiersi paikallisissa kauppakeskuksissa, valokuvasi kaikki siellä saatavilla olevat kengät ja julkaisi kuvat myyntituotteina MVP-verkkosivustollaan.
Kun käyttäjä teki tilauksen Zappos.comissa, Nick meni paikalliseen kauppakeskukseen myymälään, jossa kyseistä mallia myytiin, osti sen ja lähetti sen asiakkaalle postitse. Kuten arvata saattaa, Nick ei tehnyt voittoa tällä tavalla, jolla hän pyöritti kauppaa ”Ozin velhon” tapaan. Itse asiassa hän menetti rahaa.
Nickille tärkeintä tässä vaiheessa ei kuitenkaan ollut tulos. Hän halusi saada kaksi asiaa — asiakaspalautetta ja vahvistuksen liiketoimintamallilleen.
Kuten Zappos.comin myyntituloista ja saatavilla olevien tuotteiden määrästä näemme, Nickin liiketoimintamalli toimi ja johti valtavaan menestykseen.
Zapposilta opitut asiat
Zappos ja tapa, jolla Nick operoi sen concierge-MVP-versiota, opettavat meille jotain erittäin tärkeää startup-yrityksistä – rahaa saa olla hyväksyttävää menettää.
Selvennetäänpä tätä. Yrityksen ei yleisesti ottaen ole hyväksyttävää tehdä tappiota. Jos kyseessä on kuitenkin MVP-vaihe, tappiollinen toiminta on hyväksyttävää, sillä MVP-tuotteiden tarkoitus ei ole tuottaa sinulle rahaa. Sen sijaan niiden tarkoituksena on kerätä palautetta asiakkailtasi ja vahvistaa startup-ideasi toimivuus.
Esimerkki 4: Bufferin kehitystä edeltävä laskeutumissivu
Aivan kuten me tuotepäälliköt pidämme Jiraa tai Monday.comia olennaisina osina työkalupakkiamme, sosiaalisen median hallinnoijat pitävät Bufferia välttämättömänä osana päivittäistä työtään.
Ennen kuin Bufferista tuli täysimittainen sosiaalisen median hallinta-alusta, se aloitti sovelluksena, joka sisälsi yhden ainoan ominaisuuden.
Kyseinen ominaisuus mahdollisti useiden julkaisujen ajastamisen Twitterissä. Vaikka joissakin Twitter-asiakasohjelmissa oli jo tämä ominaisuus, Bufferin toinen perustaja ja toimitusjohtaja Joel Gascoigne halusi tehdä ajastamisesta miellyttävää luomalla saumattoman ja helppokäyttöisen käyttökokemuksen ajastusprosessin ympärille.
Hänellä oli erityisesti mielessään käyttökokemus, jonka avulla käyttäjät voisivat ajastaa suuren määrän twiittejä samanaikaisesti sen sijaan, että jokainen twiitti pitäisi ajastaa erikseen (kuten edellä mainituissa Twitter-asiakasohjelmissa).
Joel tiesi, että hänen ideansa saattoi helposti epäonnistua, joten hän päätti luoda mahdollisimman pelkistetyn arvokkaan tuotteen. Kyseessä ei ollut toimiva sovellus, vaan yksinkertainen laskeutumissivu.
Laskeutumissivulla vierailevat ihmiset lukivat Bufferin ominaisuuksista ja napsauttivat rekisteröitymään. Sovellukseen pääsyn sijaan Bufferin käyttäjät näkivät kuitenkin viestin, jonka mukaan tuote ei ollut vielä valmis, sekä pyynnön jättää sähköpostiosoitteensa, jotta Bufferin tiimi voisi ilmoittaa heille, kun tuote olisi valmis käytettäväksi.
Bufferin käyttöä varten sähköpostiosoitteensa jättäneiden käyttäjien määrä (heitä oli paljon) toimi Joelille signaalina siitä, että tämän tuotteen rakentamiseen kannatti käyttää aikaa ja rahaa.
Tuotteensa kiinnostavuuden selvittämisen lisäksi Joel hyödynsi keräämäänsä sähköpostilistaa ottaakseen yhteyttä käyttäjiin, keskustellakseen heidän kanssaan, oppiakseen lisää siitä, miten he aikoivat käyttää hänen ajastustyökaluaan, sekä perehtyäkseen syvemmin turhautumisen aiheisiin, joita he kokivat muiden sovellusten kanssa.
Bufferilta opitut asiat
Oletko koskaan onnistunut keräämään listaa ihmisistä, jotka ovat kiinnostuneita tuotteestasi? Suurin hyöty, jonka saat, on mahdollisuus oppia. Olen samaa mieltä siitä, että näistä ihmisistä tulee myös tulevia varhaisia omaksujiasi, mutta heidän sinulle tuottamansa rahallinen hyöty on todennäköisesti mitätön. Toisaalta opit, joita saat, ovat korvaamattomia.
Esimerkki 5: Spotifyn beta-versio
Suoratoistopalvelu, joka todennäköisesti soittaa parhaillaan kannettavasi taustalla lo-fi-työskentelysoittolistaa, sai alkunsa vuonna 2008, kun Daniel Ek ja Martin Lorentzon päättivät ratkaista tuolloin musiikkialalla vallinneen kiinnostavan ongelman.
Ongelma oli se, että jos halusit kuunnella kappaletta, sinun täytyi ostaa se (ja se maksoi vuonna 2009 1–2 dollaria). Tämä tarkoitti, että sinun oli joko käytettävä satoja tai tuhansia dollareita saadaksesi kattavan soittolistan, joka sisälsi kaiken rakastamasi, tai rajoitettava itsesi niihin muutamiin kappaleisiin, jotka sinulla oli varaa ostaa.
Danielilla ja Martinilla oli vallankumouksellinen idea tämän ongelman ratkaisemiseksi – suoratoistopalvelu, joka toimisi kuin ”syö niin paljon kuin jaksat” -buffet: maksaisit kuukausimaksun ja kuuntelisit niin monta kappaletta kuin haluaisit.
Toisin kuin monet aiemmat MVP-esimerkit, Spotifyn taustalla oleva tiimi rakensi oikeasti täysin toimivan ohjelmistoprototyypin, jota he jakoivat musiikkibloggaajille beetatestausta varten.
Lähde: Prototypr
Spotifyn insinöörit eivät ainoastaan tehneet tuotteen versiota, joka sisälsi sen keskeiset toiminnot, vaan käyttivät kuukausia infrastruktuurin parantamiseen ja viiveen pienentämiseen, jotta suoratoisto Spotifysta tuntuisi samalta kuin käyttäjien laitteiden kiintolevylle tallennetun kappaleen soittaminen.
Heidän jakamansa beta-versio oli valtava menestys, ja pian tuhannet käyttäjät alkoivat saapua kokeilemaan tätä uutta vallankumouksellista tapaa kuunnella musiikkia.
Spotifysta opitut asiat
Spotify on hyvä esimerkki siitä, ettei MVP:n V-kirjainta pidä unohtaa. Tarkoitus on, että tuotteen miniversion tulee olla markkinoilla toimiva ja siksi myös arvokas.
Lisäksi on täysin hyväksyttävää käyttää kuukausia yhden ominaisuuden toteuttamiseen, jos uskot sen puuttumisen vahingoittavan tuotteen potentiaalisille käyttäjille tarjoamaa keskeistä arvolupausta.
More Articles
Esimerkki nro 6: Airbnb:n concierge-testaus
Viimeinen onnistuneita MVP-tuotteita käsittelevä tapaustutkimuksemme koskee matka- ja majoitusalusta Airbnb:tä.
Heidän tarinansa alkaa vuodesta 2007, jolloin perustajat Brian Chesky ja Joe Gebbia tajusivat, ettei heillä ollut tarpeeksi rahaa San Franciscossa sijaitsevan asuntonsa vuokran maksamiseen.
Maksaakseen vuokransa he päättivät pian vuokrata asunnostaan patjoja nukkumapaikoiksi kaupungissa tuolloin järjestettävän designkonferenssin osallistujille.
Niinpä he ottivat kuvia asunnostaan ja latasivat ne pienelle verkkosivulle, jonka he loivat ”majoituspalveluaan” varten. Idea toimi, ja Airbnb-tiimi päätti laajentaa toimintaa ja tehdä siitä liiketoimintaa siten, että heidän verkkosivustonsa toimisi alustana, jolla ihmiset voisivat löytää ja varata majoituksen jonkun toisen kodista.
Amazonin ja Zapposin tavoin he käyttivät ensimmäisenä majoitustarjouksenaan verkkosivustollaan omaa asuntoaan Ihmemaa Oz -MVP-lähestymistapaa.
Sen jälkeen he jatkoivat MVP:nsä yhä kehittyneempien versioiden rakentamista (lisäten joka kerta uusia ominaisuuksia), ja käyttivät niitä tuoteideansa yleiseen validointiin sekä erityisesti yhden tietyn hypoteesin testaamiseen: ihmiset olisivat valmiita vuokraamaan asuntoaan muille rahaa vastaan.
Airbnb:stä opitut asiat
Joskus MVP ei ole kertaluonteinen ratkaisu, vaan päädyt tekemään MVP:stäsi erilaisia versioita (lisäten uusia ominaisuuksia joka kerta), joiden avulla keräät asiakaspalautetta ja oppeja tuotteesi ja liiketoimintamallisi eri osa-alueista.
Kaikki on kiinni liiketoimintamallin testaamisesta edullisesti.
Kuten edellä esitetyt menestystarinat osoittavat, MVP ei ole vain yksi käsite tuotehallinnan oppikirjoissa. Se on jotain todellista, ja MVP-tuotteiden tekeminen on auttanut monia tunnettuja digitaalisia tuotteita validoitumaan ennen kuin niiden perustajat ja tuotekehitystiimi alkoivat käyttää kuukausia niiden rakentamiseen.
Jos haluat lisää tämänkaltaisia oivalluksia, muista tilata uutiskirjeemme!
