Näin rakennat minimitoimivan tuotteen

Voidaan väittää, että vähimmäistoimivat tuotteet (eli ”MVP:t”) ovat digitaalisen yrittäjän työkalupakin parhaiten ymmärrettyjä mutta useimmiten väärin käytettyjä työkaluja. Nykyään lähes kaikki uutta tuotetta rakentavat aloittavat MVP:stä. Harvat ovat kuitenkaan onnistuneet hallitsemaan tämän työkalun ja saamaan siitä kaiken hyödyn irti.

Joten anna minun auttaa sinua ymmärtämään MVP:t, rakentamaan sellaisen oikein ja hyödyntämään niiden koko potentiaalin.

Mikä on vähimmäistoimiva tuote (MVP)?

Jos esität tämän kysymyksen yrittäjien ja tuotepäälliköiden ryhmälle, useimmat heistä vastaavat, että vähimmäistoimiva tuote on tuotteen versio, joka sisältää markkinoille julkaisemiseen riittävän vähimmäistoiminnallisuuden.

Ja kyllä, teknisesti ottaen he ovat oikeassa. Määritelmä on kuitenkin hieman puutteellinen, sillä se ei oikeastaan kuvaa tuotekehitysstrategian ydintarkoitusta. Juuri siksi monet perustajat ja tuotetiimit käyttävät MVP:itä väärin tai kutsuvat jotakin MVP:ksi, vaikka se ei sitä todellisuudessa ole.

Jotkut ajattelevat, että MVP:n tarkoituksena on ansaita rahaa varhaisessa vaiheessa. Vaikka se on mahdollista, on täysin hyväksyttävää, ettei MVP tuota lainkaan liikevaihtoa. Jos ihmiset eivät siis osta MVP-tuotettasi, älä vielä luovu siitä.

Toiset ajattelevat, että MVP:n tarkoituksena on rakentaa asiakaskunta, joka osoittaa tuotteesi toimivuuden niiden pääomasijoittajien silmissä, jotka haluavat sijoittaa tuotteeseesi.
Jälleen kerran, voit tehdä näin, mutta se ei ole MVP:n tarkoitus.

Mikä on MVP?

Vaikka käsite ”aloita pienestä, tarkista, onko idea elinkelpoinen, ja laajenna sitten” on ollut olemassa koko kirjatun historian ajan, MVP:n muodollisen (ja suosikkini) määritelmän kehitti itse suuri Eric Ries. Kirjassaan Lean Startup Eric korostaa ydinolettamusten testaamista MVP:n päätarkoituksena.

Lean Startup -ajattelussa ei oikeastaan ole väliä, miltä MVP tarkalleen näyttää, kunhan:

Toisin sanoen todellisia esimerkkejä MVP:istä on kaikkialla ympärillämme – myös sellaisia, jotka eivät ole vielä edes toimivia tuotteita. Esimerkiksi kuponkienhallintapalvelu Groupon julkaisi MVP:nsä pienenä WordPress-sivustona, joka näytti tältä.

Tällä sivustolla Grouponin tiimi jakoi yleisölleen yksinkertaisesti päivittäisiä tarjouksia.

On paljon muitakin esimerkkejä menestyneistä tuotteista, joiden MVP-versio oli aloitussivu, sosiaalisen median ryhmä tai jopa videodemon olemattomasta tuotteesta (palaamme tähän myöhemmin).

Miksi startup-yritykset tarvitsevat vähimmäistoimivan tuotteen

On hyvä syy siihen, että MVP:t ovat niin suosittuja tuotekehitysstrategiana startup-yritysten perustajien ja tuotepäälliköiden keskuudessa (vaikka monet heistä tulkitsevatkin käsitteen väärin). MVP-version rakentaminen auttaa varhaisvaiheen startup-yrityksiä välttämään joitakin startup-elämään liittyvistä suurimmista riskeistä.

Esittelen niistä muutamia ja näytän, miten MVP:n rakentaminen auttaa lieventämään niitä.

1. Ne estävät julkaisujen viivästymisen

Digitaalinen maailma on niin nopeatempoinen kuin mahdollista. Tuotteen julkaiseminen kaksi vuosineljännestä myöhemmin kuin kaikki muut voi tarkoittaa markkinaosuuden menettämistä kilpailijoille. Usko pois, käyttäjien houkutteleminen toiselta palvelulta on paljon vaikeampaa kuin uuden käyttäjän hankkiminen avoimilta markkinoilta.

MVP:t ratkaisevat tämän ongelman sitouttamalla käyttäjät alustallesi jo varhaisessa vaiheessa. Vaikka et ehkä tarjoakaan heille heidän unelmiensa lopputuotetta, onnistunut MVP (olettaen, että se vahvistaa ydinolettamuksesi) pitää käyttäjät kanssasi riittävän pitkään, jotta ehdit toimittaa lopullisen tuotteen.

Ymmärtääksesi, kuinka paljon aikaa MVP voi säästää, tutustu tähän kaavioon, jonka kokosin Atlassianin, Shopifyn ja McKinseyn tietojen perusteella.

Rakentamasi tuotteen tyypistä riippuen voit säästää yhdeksästä kuukaudesta jopa kahteen kokonaiseen vuoteen!

2. Ne minimoivat uponneet kustannukset

On täysin hyväksyttävää, että julkaisemasi uuden tuotteen ensimmäinen versio epäonnistuu—
ja suoraan sanottuna niin todennäköisesti käykin.

Itse asiassa startup-yritysten epäonnistumisaste on niin korkea (90 %, CB Insightsin raportin mukaan), että sinun kannattaa keskittyä enemmän näiden epäonnistumisten kustannusten pienentämiseen sen sijaan, että toivoisit seuraavan tuotteesi olevan valtava menestys.

MVP:t ovat yksi parhaista työkaluista, joiden avulla voit tehdä juuri tämän. Niiden avulla voit validoida asiakkaiden tarpeet markkinoilla suhteessa arvolupaukseesi mahdollisimman vähäisellä vaivalla. Tämä tarkoittaa, että voit testata liikeideaasi käymättä läpi koko ohjelmistokehityksen elinkaarta pitkällisen kehitysprosessin aikana. Yhden valmiin tuotteen valmistamiseen kuluvilla kustannuksilla voit siis tehdä tusinan MVP:tä ja tarkistaa, pidetäänkö niistä markkinoilla.

3. Ne estävät startup-yrityksiä rakentamasta tuotetta ”sokkona”

Käytän termiä ”sokkona rakentaminen” kuvaamaan tuotteen kehittämistä ilman kunnollista tietoa siitä, mitä aiotut käyttäjät todella haluavat. Tämä on todennäköisesti suurin yksittäinen synti, johon yrittäjä voi syyllistyä.

Ongelma siinä, että rakennetaan kokonainen tuote kaikkine tuotesuunnitelmaan kirjattuine uusine ominaisuuksineen ja valmiine hinnoittelustrategioineen, on se, ettei sinulla ole aavistustakaan, pitävätkö ihmiset siitä, ennen kuin olet saanut sen valmiiksi ja julkaissut sen.

Useimmiten ihmiset eivät pidä siitä, ja joudut tekemään hinnat ja ominaisuudet uudelleen. Joissakin tapauksissa saatat jopa joutua hyväksymään todellisuuden, jossa tuote on hylättävä kokonaan tai tuotteen hinnoittelustrategia on muutettava kokonaan.

Paras tapa välttää tämä on hankkia käyttäjiltä palautetta varhaisessa vaiheessa. Miten se onnistuu? Tietenkin MVP:n avulla!

Toimivan vähimmäistuotteen rakentaminen: tärkeimmät vaiheet

Kun MVP:n teoria on käsitelty, siirrytään käytännönläheisempiin osuuksiin ja perehdytään vaiheisiin, joita tarvitaan sellaisen MVP-konseptin rakentamiseen, joka voi asianmukaisesti palvella päätarkoitustaan—antaa sinun testata tuotteesi toimivuutta markkinoilla.

Vaihe 1: Tunnista ratkaistava ongelma

Jokainen loistava tuote alkaa käyttäjän ongelmasta, joka on ratkaistava. Tässä prosessissa on kaksi alavaihetta:

a) Ongelman tunnistaminen: Tässä monet startup-yritykset tekevät virheen—ne tunnistavat väärän ongelman.

Esimerkiksi 1900-luvun alussa liikenteen keskeinen ongelma ei ollut nopeampien hevosten tai paremman infrastruktuurin puute, jotta hevoset olisivat voineet matkustaa pitkiä matkoja. Todellinen ongelma oli se, että ihmiset tarvitsivat luotettavamman ja raskaaseen käyttöön soveltuvan kuljetusvälineen. Henry Ford tunnisti tämän ongelman onnistuneesti ja ratkaisi sen tuomalla markkinoille auton.

Yksi parhaista tavoista tunnistaa oikea ongelma on viiden miksi-kysymyksen menetelmä.

b) Ongelman ymmärtäminen: Oikean ratkaistavan ongelman löytäminen on vasta puolet työstä. Toinen puoli liittyy sen asiayhteyden ja todellisuuden ymmärtämiseen, jossa käyttäjäsi kohtaavat ongelman.

Esimerkiksi TikTokin automaattisesti luodut tekstitykset syntyivät siitä, että tuotetiimi ymmärsi monien käyttäjien katsovan TikTokia ympäristöissä, joissa heidän on mykistettävä ääni.

Tätä varten sinun on tehtävä käyttäjähaastatteluja. Mikään prosessi ei ole käyttäjien asiayhteyden ymmärtämisessä tehokkaampi kuin heidän kanssaan keskusteleminen.

Vaihe 2: Määrittele MVP:n keskeiset ominaisuudet

Tyypillisessä tuotejäämistössäsi on enemmän ominaisuuksia kuin MVP:hen tarvitset.

Jotta ymmärtäisit, mitkä ominaisuudet on sisällytettävä MVP:n laajuuteen, suosittelen käyttämään kahta erinomaista ominaisuuksien priorisointikehystä:

Kano-malli: Sen avulla ryhmittelet ominaisuudet sellaisiin, jotka ilahduttavat käyttäjiäsi, tuottavat heille lineaarisesti lisäarvoa ja ovat kriittisen tärkeitä.

Hotelliesimerkissä houkutteleva ominaisuus on suloisen näköinen origamipyyhe, suorituskykyominaisuus on patjan laatu ja välttämätön ominaisuus on huoneen sisäänkäyntioven turvallinen lukko.

MVP:ssä keskityt ”välttämättömiin” ominaisuuksiin.

MoSCoW: Tämä on yksinkertainen harjoitus, jossa määrität ominaisuuksillesi tilat ”Pakollinen”, ”Pitäisi olla” ja ”Voisi olla”. Pakolliset ominaisuudet kattavat keskeisen käyttötapauksen.

Spotifyn esimerkkiä käyttäen pakollinen ominaisuus on haku. Soittolistat puolestaan ovat ”Pitäisi olla” -ominaisuuksia, ja albumikuvien näyttäminen näytöllä on ”Voisi olla” -ominaisuus.

MVP:ssä keskityt pakollisiin ominaisuuksiin.

Vaihe 3: Rakenna ja testaa MVP

MVP:si ei ole MVP, jos käytät sen rakentamiseen liikaa aikaa. Siksi ehdotan, että hyödynnät seuraavia keinoja prosessisi nopeuttamiseksi:

• Kooditon kehitys: Bubblen kaltaisten työkalujen avulla voit tehdä ensimmäisen versiosi murto-osassa siitä ajasta, joka kuluisi kaiken koodaamiseen alusta alkaen.
• Klikattavat prototyypit: Nykyaikaisten suunnittelutyökalujen avulla voit tehdä tarkat rautalankamallit interaktiivisiksi, mikä säästää aikaa tuotteen version koodaamisessa.
• Mallit ja vähäkoodiset kehykset: Lähes jokaisella suurella pilvipalveluntarjoajalla on valmiita palveluita, joiden avulla voit nopeuttaa kehitysprosessiasi merkittävästi.

Heti kun MVP:si on valmis, on aika luovuttaa se käyttäjillesi. Voit käyttää AppSumon ja Product Huntin kaltaisia alustoja ensimmäisten käyttäjien hankkimiseen ja palautteen keräämisen aloittamiseen.

Vaihe 4: Mittaa onnistumista ja kehitä iteroiden

Yksi Lean Startupin keskeisistä käsitteistä on MVP:llä tekemäsi testauksen tulosten mittaaminen ja sen kehittäminen iteroiden.

Analytiikkatyökalujen, kuten Mixpanelin, Amplituden ja PostHogin, integrointi voi auttaa sinua mittaamaan tuloksiasi helposti.

Tässä on joitakin tärkeimpiä tuotemittareita, joita voit mitata näillä työkaluilla.

Iterointivaihe on suoraviivainen. Tarkastelet palautetta ja keskeisiä mittareita löytääksesi kehityskohteita, lisäät nämä parannukset MVP:hen ja julkaiset uuden version testattavaksi.

Ainoa neuvoni tässä on julkaista usein ja pieniä päivityksiä kerrallaan. Näin ymmärrät, onko uusi ominaisuutesi parantanut palautetta tai mittareitasi.

Yleiset MVP-virheet, joita tulee välttää

Se on hieman vastoin intuitiota, mutta MVP:iden valtavasta suosiosta huolimatta ihmisillä on tapana toistaa samoja virheitä. Pääsyy tähän on – arvasit oikein – MVP:n olemassaolon keskeisen tarkoituksen väärinymmärtäminen.

Auttaakseni sinua välttämään nämä sudenkuopat haluan tuoda esiin kolme yleisintä:

1. MVP-version ylikehittäminen

Monet tuotetiimit pitävät MVP:tä myyntivalmiina versiona, jolla voi testata tuotteen ja markkinoiden yhteensopivuutta. Näin ei oikeastaan ole. Tuotteestasi on olemassa sitä varten toinen versio, jota kutsutaan MMP:ksi (vähimmäismarkkinakelpoiseksi tuotteeksi).

MVP-versio puolestaan on paljon suppeampi, ja sen tarkoituksena on testata, vetoaako ideasi oikeisiin käyttäjiin.

2. Palautteen sivuuttaminen

MVP:n testaamisesta saamasi käyttäjäkommentit ja käyttäytymisanalytiikka ovat kullanarvoisia. On tavallista olla kiinnittämättä huomiota osaan tästä palautteesta ajatellen, että käyttäjät pitäisivät silti lopullisesta versiosta. Eivät pidä! Miksi edes rakentaa MVP-versio, jos kieltäydyt hyödyntämästä lean startup -menetelmään kuuluvaa palautesilmukoiden luomista?

3. Liian myöhäinen tai liian aikainen julkaisu

Molemmat ovat ongelmallisia. Jos julkaiset liian myöhään, koko MVP:n idea menettää merkityksensä. Varo kuitenkin myös julkaisemasta liian aikaisin. MVP:ssäsi tulisi olla riittävästi ominaisuuksia keskeisten hypoteesiesi testaamiseen. Testituloksesi ovat harhaanjohtavia, jos näitä ominaisuuksia ei ole mukana.

4. MVP:n sekoittaminen prototyyppeihin

Nämä kaksi termiä saattavat vaikuttaa hieman hämmentäviltä. Prototyyppi on interaktiivinen suunnitelma, jota voit käyttää käyttäjätestaukseen. Vaikka se voi teknisesti toimia MVP:nä, voit myös koodata tuotteestasi kevyen version MVP:ksi.

Näin MVP:t, prototyypit ja täydet tuotteet eroavat toisistaan.

Kuten yllä oleva infografiikka osoittaa, prototyyppien tavoite vastaa MVP:n tavoitetta. Ainoa ero on kunkin fyysinen lopputuote.

Todellisia esimerkkejä onnistuneista MVP:istä

En yllättyisi, jos et vieläkään olisi vakuuttunut MVP-strategian tehokkuudesta. Kun otetaan huomioon, että tarjolla on valtavasti suosittuja työkaluja ja kehyksiä, joita monet eivät pidä erityisen hyödyllisinä, ajatus tuotteesi "surkean ensimmäisen luonnoksen" rakentamisesta ei houkuttele kaikkia.

Mutta seniorituotepäällikkönä, joka on seurannut joidenkin todellisten katastrofien tapahtumista hidastetusti, tästä en tingi. Todistaakseni väitteeni haluan näyttää esimerkkejä MVP-tuotteista, jotka ovat kehittyneet teknologiajäteiksi.

Dropbox

Muistatko, kun sanoin, että MVP:iden ei välttämättä tarvitse olla koodattuja tuotteita? No, Dropboxin MVP-versio oli videoesitys!

Tässä videossa Dropboxin perustaja yksinkertaisesti esittelee tuotteen konseptin, jota ei vielä ollut koodattu. Esityksen seurauksena kuitenkin valtava määrä ihmisiä ilmoittautui käyttääkseen tuotetta heti, kun se olisi valmis. Tämä oli Dropboxin tiimille merkki siitä, että he olivat oikealla tiellä.

Airbnb

Suosikkialustamme, joka on vastuussa asuntomarkkinakriisien aiheuttamisesta monissa matkailukaupungeissa (kyllä, se jopa kiellettiin Firenzessä Italiassa tästä syystä!), aloitti myös epäperinteisenä MVP:nä.

Yrityksen perustajat testasivat liiketoimintamallinsa toimivuutta vuokraamalla San Franciscossa sijaitsevasta asunnostaan vuoteita useille konferenssivieraille. He halusivat selvittää, olisivatko ihmiset tyytyväisiä vuokraamaan vuoteen tai huoneen jonkun toisen asunnosta.

Vastaus tähän kysymykseen oli kyllä! Markkinat siis antoivat perustajille vihreää valoa alkaa rakentaa täsmälleen tähän ajatukseen perustuvaa alustaa.

Zappos

Tapa, jolla Zappos lähestyi MVP:tään, tunnetaan tuotemaailmassa nimellä ”Ihmemaa Oz” -testaus. Tässä tilanteessa rakennat tuotteellesi verkkosivuston, mutta ihmiset hoitavat kaiken taustajärjestelmän käsittelyn koneiden sijaan.

Zapposin tiimi julkaisi verkkosivustona toimivan verkkokenkäkauppansa ilman taustatoimiston käsittelyä. Kun käyttäjät tilasivat heiltä kenkiä, tiimi osti ne muualta ja lähetti ne käyttäjille. Saatuaan markkinoilta vahvistuksen, että tämä malli toimii, he alkoivat rakentaa tuotteensa taustajärjestelmää.

Vaikka nämä kolme ovat suosituimpia esimerkkejä oikein toteutetuista MVP:istä, on olemassa monia muitakin menestyneitä MVP:itä, joista on kehittynyt erittäin menestyviä tuotteita. 

Työkalut ja resurssit MVP:n rakentamiseen

Tämänpäiväisen MVP-oppaamme viimeinen osa käsittelee tuotekehitysohjelmistojen ja oppimateriaalien valintaa. Ne voivat auttaa sinua parantamaan MVP:n rakentamisen tehokkuutta ja vaikuttavuutta, testaamaan hypoteesejasi varhaisten omaksujien kanssa sekä käsittelemään käyttäjäpalautetta.

Aloitetaan työkaluista.

• Nopea prototypointi ja käyttäjäkokemus: Figma, InVision, Sketch, Framer ja muut vaihtoehdot.
• Työnkulun hallinta: Kanban-taulut, kuten Jira, Monday.com ja Trello.
• Analytiikka: Mixpanel, Amplitude, PostHog.
• Kohderyhmän tunnistaminen: Reddit, Similarweb.
• Asiakaspalautteen käsittely: Typeform, SurveyMonkey, Google Forms.

Ja jos et ole vielä lukenut sitä, suosittelen lämpimästi aloittamaan kirjasta Lean Startup, joka on paras resurssi MVP-lähestymistavan selittämiseen osana rakenna–mittaa–opi-syklien kokonaisrakennetta.

Muista tilata uutiskirjeemme saadaksesi lisää tuotehallinnan resursseja ja oppaita sekä alan johtajien ja asiantuntijoiden uusimmat podcastit, haastattelut ja muut näkemykset.