Kuinka rakentaa elinkelpoinen vähimmäistuote

Voitaisiin väittää, että vähimmäistoimivat tuotteet (tai ”MVP:t”) ovat digitaalisen yrittäjän työkalupakin parhaiten ymmärrettyjä mutta samalla yleisimmin väärinkä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.

Anna siis 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 keskeistä tarkoitusta. Juuri siksi monet perustajat ja tuotetiimit käyttävät MVP:itä väärin tai kutsuvat jotakin MVP:ksi, vaikka se ei todellisuudessa ole MVP.

Jotkut ajattelevat, että MVP:n tarkoituksena on ansaita rahaa varhaisessa vaiheessa. Vaikka se on mahdollista, on myös täysin hyväksyttävää, ettei MVP tuota lainkaan tuloja. Jos ihmiset eivät siis osta MVP-tuotettasi, älä vielä hylkää sitä.

Toiset ajattelevat, että MVP:n tarkoituksena on rakentaa asiakaskunta, joka osoittaa tuotteen toimivan riskipääomasijoittajien silmissä, jotta nämä haluavat sijoittaa tuotteeseesi.
Voit toki tehdä näin, mutta se ei ole MVP:n tarkoitus.

Mikä siis on MVP?

Vaikka käsite ”aloita pienestä, tarkista idean toimivuus ja laajenna sitten” on ollut olemassa koko kirjatun historian ajan, MVP:n muodollisen (ja oman suosikkini) määritelmän kehitti kukapa muu kuin mahtava Eric Ries. Kirjassaan Ketterä käynnistys Eric korostaa ydinolettamusten testaamista MVP:n päätarkoituksena.

Ketterän käynnistyksen ajattelussa ei oikeastaan ole väliä, miltä MVP täsmälleen näyttää, kunhan:

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

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

On olemassa paljon muitakin esimerkkejä menestyneistä tuotteista, joiden MVP-versio oli aloitussivu, sosiaalisen median ryhmä tai jopa olemattoman tuotteen videodemo (tästä lisää myöhemmin).

Miksi startup-yritykset tarvitsevat vähimmäistoimivan tuotteen

On hyvä syy siihen, miksi MVP:t ovat niin suosittuja tuotekehitysstrategiana startup-yritysten perustajien ja tuotepäälliköiden keskuudessa (vaikka monet heistä ymmärtävätkin käsitteen väärin). MVP-version rakentaminen auttaa alkuvaiheen startup-yrityksiä välttämään joitakin startup-elämään liittyviä suurimpia riskejä.

Esittelen niistä muutaman ja näytän, miten MVP:n rakentaminen auttaa pienentämään niitä.

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

Digitaalinen maailma on niin nopeatempoinen kuin mahdollista. Tuotteen julkaiseminen kaksi vuosineljännestä kaikkia muita myöhemmin voi tarkoittaa markkinaosuuden menettämistä kilpailijoille. Usko pois, käyttäjien houkutteleminen pois jonkun toisen palvelusta 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 varhaisessa vaiheessa. Vaikka et ehkä tarjoakaan heille heidän haaveilemaansa lopullista tuotetta, 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ää, katso tätä kaaviota, jonka kokosin Atlassianilta, Shopifylta ja McKinseyltä saatujen tietojen perusteella.

Rakentamasi tuotteen tyypistä riippuen voit säästää yhdeksästä kuukaudesta aina kahteen täyteen vuoteen!

2. Ne minimoivat uponneet kustannukset

On täysin hyväksyttävää, että julkaisemanasi uuden tuotteen ensimmäinen versio epäonnistuu –
ja suoraan sanottuna niin luultavasti 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 menestyvän valtavasti.

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 pitkittyneen kehitysprosessin kera. Yhden valmiin tuotteen valmistamiseen kuluvilla kustannuksilla voit siis tehdä tusinan MVP:tä ja tarkistaa, ovatko ne markkinoilla pidettyjä.

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

Käytän termiä ”sokkona rakentaminen” viittaamaan tuotteen kehittämiseen ilman kunnollista tietoa siitä, mitä aiotut käyttäjäsi todella haluavat. Tämä on luultavasti suurin yksittäinen virhe, jonka yrittäjä voi tehdä.

Täyden tuotteen rakentamisen ongelma kaikkine tuotesuunnitelmasi uusine ominaisuuksineen ja valmiine hinnoittelustrategioineen on se, ettet tiedä, pitävätkö ihmiset siitä, ennen kuin olet saanut sen valmiiksi ja julkaissut sen.

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

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

Miten rakennetaan pienin toimiva tuote: tärkeimmät vaiheet

Kun MVP:iden teoria on nyt käsitelty, siirrytään käytännönläheisempiin osioihin ja tarkastellaan vaiheita, joita tarvitaan sellaisen MVP-konseptin rakentamiseen, joka voi palvella asianmukaisesti päätarkoitustaan – auttaa sinua testaamaan tuotteesi elinkelpoisuutta markkinoilla.

Vaihe 1: Tunnista ratkaistava ongelma

Jokainen loistava tuote alkaa käyttäjän ongelmasta, joka on ratkaistava. Tämä prosessi koostuu kahdesta alavaiheesta:

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 kulkea pitkiä matkoja. Todellinen ongelma oli se, että ihmiset tarvitsivat luotettavamman ja raskaisiin kuljetuksiin soveltuvan kulkuvälineen. Henry Ford tunnisti ja ratkaisi tämän ongelman onnistuneesti tuomalla markkinoille auton.

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

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 kyseisen 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 tehokkaampi käyttäjiesi tilanteen ymmärtämisessä kuin heidän kanssaan keskusteleminen.

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

Tyypillisessä tuotteen työjonossasi on enemmän ominaisuuksia kuin MVP:täsi varten tarvitset.

Jotta ymmärtäisit, mitkä niistä tulisi sisällyttää MVP:n laajuuteen, suosittelen käyttämään kahta erinomaista ominaisuuksien priorisoinnin viitekehystä:

Kano-malli: Tässä ominaisuudet ryhmitellään sellaisiin, jotka ilahduttavat käyttäjiäsi, tuottavat heille lineaarisesti lisäarvoa ja ovat kriittisen tärkeitä.

Hotellia koskevassa esimerkissä houkutteleva ominaisuus on söpön näköinen origamipyyhe, suorituskykyominaisuus patjan laatu ja ehdoton perusominaisuus huoneen sisäänkäyntiovessa oleva turvallinen lukko.

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

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

Spotifyn esimerkin avulla pakollinen ominaisuus on haku. Soittolistat puolestaan kuuluvat luokkaan Pitäisi olla, ja albumikuvien näyttäminen näytöllä luokkaan Voisi olla.

MVP:tä varten keskityt pakollisiin ominaisuuksiin.

Vaihe 3: MVP:n rakentaminen ja testaaminen

MVP:si ei ole MVP, jos käytät sen rakentamiseen liikaa aikaa. Siksi suosittelen hyödyntämään seuraavia keinoja prosessin nopeuttamiseksi:

• Kooditon kehitys: Bubble ja muut tekoälypohjaiset sovellusrakentajat mahdollistavat ensimmäisen version tekemisen murto-osassa siitä ajasta, joka kuluisi kaiken koodaamiseen alusta alkaen.
• Interaktiiviset prototyypit: Nykyaikaisilla suunnittelutyökaluilla voit tehdä tarkat rautalankamallit interaktiivisiksi, mikä säästää aikaa tuotteesi version koodaamisessa.
• Mallit ja vähäkoodiset viitekehykset: Lähes jokaisella merkittävällä pilvipalveluntarjoajalla on valmiita palveluita, joiden avulla voit nopeuttaa kehitysprosessiasi huomattavasti.

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: Menestyksen mittaaminen ja iterointi

Lean Startupin keskeisiä käsitteitä on MVP:llä tehdyn testauksen tulosten mittaaminen ja sen iterointi.

Analytiikkatyökalujen, kuten Mixpanelin, Amplituden ja PostHogin, integroiminen 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 tunnistaaksesi parannuskohteet, lisäät nämä parannukset MVP:hen ja julkaiset uuden version testausta varten.

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

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

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

Auttaakseni sinua välttämään nämä sudenkuopat haluan nostaa esiin kolme yleisintä.

1. MVP-version liiallinen suunnittelu

Monet tuotetiimit pitävät MVP:tä myyntivalmiina versiona ja ajattelevat, että sen avulla voi testata tuotteen ja markkinoiden yhteensopivuutta. Ei aivan. Tuotteestasi on olemassa tätä varten eri versio, jota kutsutaan MMP:ksi (markkinoitava vähimmäistuote).

MVP-versio puolestaan on paljon suppeampi, ja sen tarkoituksena on testata, resonoiko ideasi todellisten käyttäjien kanssa.

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 ja ajatella, että käyttäjät pitävät silti lopullisesta versiosta. Eivät pidä! Miksi edes rakentaa MVP-versiota, jos kieltäydyt hyödyntämästä lean startup -menetelmän palautesilmukoiden luomista?

3. Julkaiseminen liian myöhään tai liian aikaisin

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

4. MVP:n sekoittaminen prototyyppeihin

Nämä kaksi termiä saattavat vaikuttaa hieman sekavilta. 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, prototyypit ja valmiit tuotteet eroavat toisistaan.

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

Todellisia esimerkkejä onnistuneista MVP-tuotteista

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

Mutta seniorituotepäällikkönä, joka on seurannut joidenkin todellisten katastrofien tapahtumista hidastettuna, olen valmis puolustamaan tätä näkökulmaa loppuun asti. Todistaakseni väitteeni haluan näyttää muutamia esimerkkejä MVP-tuotteista, jotka ovat kehittyneet teknologiajättiläisiksi.

Dropbox

Muistatko, kun sanoin, ettei MVP:n välttämättä tarvitse olla koodattu tuote? Dropboxin MVP-versio oli videoesitys!

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

Airbnb

Suosikkialustamme, joka on aiheuttanut asuntomarkkinakriisejä monissa matkailukaupungeissa (jep, se kiellettiin tästä syystä jopa Firenzessä, Italiassa!), aloitti myös epätavanomaisena MVP:nä.

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

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

Zappos

Zapposin tapa lähestyä MVP:tä tunnetaan tuotemaailmassa nimellä ”Ihmemaa Oz” -testaus. Tässä lähestymistavassa tuotteelle rakennetaan verkkosivusto, mutta ihmiset hoitavat kaiken taustalla tapahtuvan käsittelyn koneiden sijaan.

Zapposin tiimi lanseerasi kenkien verkkokauppansa verkkosivustona ilman taustatoimistokäsittelyä. Kun käyttäjät tilasivat heiltä kenkiä, tiimi osti ne jostain muualta ja lähetti ne käyttäjille. Saatuaan markkinoilta vahvistuksen sille, että tämä malli toimii, he alkoivat rakentaa tuotteensa taustajärjestelmää.

Vaikka nämä kolme ovat suosituimpia tarinoita oikein toteutetuista MVP-tuotteista, on olemassa paljon muitakin onnistuneita MVP-tuotteita, joista on kehittynyt erittäin menestyviä tuotteita. 

Työkalut ja resurssit MVP:n rakentamiseen

Tämän MVP-oppaamme viimeinen osa käsittelee tuotekehitysohjelmistojen ja oppimateriaalien valintaa. Niiden avulla voit parantaa MVP:n rakentamisen tehokkuutta ja vaikuttavuutta, testata hypoteesiasi varhaisten omaksujien kanssa sekä käsitellä 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.
• Kohdeyleisön tunnistaminen: Reddit, Similarweb.
• Asiakaspalautteen käsittely: Typeform, SurveyMonkey, Google Forms.

Jos et ole vielä lukenut sitä, suosittelen lämpimästi aloittamaan kirjasta Lean Startup, joka on paras resurssi MVP-lähestymistavan selittämiseen osana rakentamisen, mittaamisen ja oppimisen kokonaisuutta.

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