Lényegében az a legkisebb egység, amiből a legtöbbet tanulhatjuk a további fejlesztések előtt. A legkritikusabb hipotézist teszteljük ezzel az első prototípussal: hogy olyan egyedi megoldást nyújtunk egy létező problémára, amire valós piaci igény mutatkozik.

De miért jó ez egyáltalán? Miért éri meg kijönni valamivel, ami nem tökéletes, ahelyett, hogy a maximumra törekedve, csúcsra fejlesztünk valamit, és ezt követően bocsátjuk piacra?

Egyrészt amíg a tökéletes megoldást fejlesztgetjük (sokszor hónapokon, akár éveken át) fennáll annak a veszélye, hogy a piac elrobog mellettünk, amíg mi akkurátusan fejlesztjük a termékünket, szolgáltatásunkat. Másfelől pedig arra is komoly esély mutatkozik, hogy miközben a tökéletes változat farigcsálásával foglalatoskodunk, addig a vásárlók elköteleződnek valami más mellett, ami bár nem tökéletes, de létező megoldás a problémájukra.

A cikk végére pontos képet kapunk arról, miben segíti az üzleti modellt és a jó megtérülést az MVP. Első lépésként kezdjük az MVP fogalmának tisztázásával.

1. fejezet

Mi az MVP – és mi nem az?

Ha azt mondjuk: MVP, sokan a startupokra asszociálnak. Az MVP azonban lehet bármilyen termék, szolgáltatás vagy dobozos megoldás. Nemcsak startupoknak elemi fontosságú, hanem gyakorlatilag minden vállalkozási forma számára.

Egy mondatban összefoglalva: a kritikus visszajelzések megszerzésére irányuló stratégia, a termékfejlesztés korai és legfontosabb szakaszaiban. (Később bővebben is kifejtjük.)

A koncepció Eric Ries Lean Startup című könyvéből vált híressé. Lényegében egy korlátozott funkciókkal bíró termékről vagy szolgáltatásról beszélünk, amely már rendelkezik egy – esetenként több – olyan jellemzővel, amely a korai befogadóknak már ebben a korlátozott formában is komoly szolgálatot tesz. És nem mellesleg szerethető. (A szerethetőség kérdése esszenciális fontosságú az üzletimodell-tervezés során, erről korábban írtunk már.)

Azért minimum, mert a ténylegesen szükségesnél semmivel sem szánunk rá több pénzt és időt.

Minimum - kezdetleges, de létező, bemutatható;
Viable - piaci igény mutatkozik rá;
Product - termék vagy szolgáltatás formájában eladható.

Hogy ez miért jó?

Mert így nem egy szűk üzleti kör vagy az ismerősök véleménye az egyetlen támaszunk, amikor az ötlet életképességéről kell döntenünk. Az MVP modellnek köszönhetően ugyanis már kezdeti stádiumban valós ügyfeleken tudjuk tesztelni a terméket.

Ezzel egyrészt validációt nyerhetünk, másrészt a termékfejlesztésben is hatalmas hasznát vesszük az így szerzett tapasztalatoknak, visszajelzéseknek.

Az MVP három fő jellemzője:

Elég értékes ahhoz, hogy az emberek kezdeti fázisban is hajlandóak legyenek pénzt adni érte.
Elég jövőbeni előnnyel (future benefit) kecsegtet az early adopterek számára.
Megfelelő mértékű visszajelzést generál a termék- vagy szolgáltatásfejlesztés munkájának segítéséhez.

Mi nem a Minimum Viable Product?

Nem nevezhetjük MVP-nek azt az alapterméket vagy -szolgáltatást, amelynek fókuszában nem az a probléma (vagy Job*) van, amit a potenciális ügyfelek el akarnak végeztetni a termékkel/szolgáltatással, és nem ezek mentén határozzuk meg a minimum befektetett időt és anyagi forrást.

(Tehát: nem a minimum eladható terméket keressük, mert az szimplán csak olcsó, hanem a minimum életképes, de az ügyfélkör által nagyon is szerethetőt.)

A Jobs to be Done* pontosan leírja, hogy egy adott csoport mit akar elérni vagy megvalósítani egy adott helyzetben. Ezek a jobok lényegében feladatokat jelentenek, amellyel a célcsoportunk találkozik, miközben a céljait, vágyait próbálja beteljesíteni, vagy épp megpróbál elkerülni valamilyen fájdalmat, veszteséget. Az említett jobok tehát leírják, mi a vágyott állapot, és az ehhez vezető út. (Pl. a gyerekek fociedzése egy olyan job, amitől a srácok jobb játékossá válnak – nem az edzésre vágynak, hanem a jobb játékos állapotára.)

Mindezt az Airbnb példáján keresztül bemutatva

A Minimum legalább egy ingatlant takar, amely rendelkezik ideiglenesen kiadható szobával;
a Viable egy adatbázist tartalmazó weboldalt jelöl, amely gyorsan és egyszerűen lefordítható több nyelvre, illetve rendelkezik felhasználói profilokkal, üzenetküldési lehetőséggel, valamint értesítési fülekkel;
a Minimum Viable tehát egy olyan online adatbázist futtató weboldalt jelent, amely tartalmazza a kiadandó szobákat kínáló ideiglenes bérbeadók listáját.

(Az Airbnb MVP-jéről a későbbiekben még lesz szó.)

Rendben. Ez mind szép és jó. Ezen a ponton azonban joggal merül fel a kérdés: hogyan alkalmazhatjuk ezt mi magunk a saját cégünknél?

2. fejezet

Hogyan határozzam meg a saját MVP-met?

Ilyenkor jellemzően felmerül a kérdés: hogyan kezdjek bele? És egyáltalán honnan tudja majd a csapat, hogy olyan MVP-je van, ami megérett a launchra?

Ha az alábbi szempontok szerint haladsz, jelentősen könnyebb dolgod lesz az MVP kidolgozása során.

Egyezik az üzleti célokkal?

Elsőként arról kell megbizonyosodnunk, hogy a szóban forgó prototípusunk igazodik a csapat, illetve a teljes cég stratégiai céljaihoz. Még mielőtt egyáltalán fejleszteni kezdenénk azt. Az is feladatunk tehát, hogy tisztázzuk ezeket a célokat.

Ezután abban is meg kell egyeznie a csapatnak, hogy milyen időintervallumon belül realizálhatunk a termékből vagy szolgáltatásból bevételt. Milyen erőforrásokkal rendelkezünk?

Az indulás előtt pontosan látnunk kell, milyen célt szolgál az MVP piacra bocsátása. Milyen vásárlókat, ügyefeleket vonz majd be?

Amennyiben az ezekre a kérdésekre adott válaszok egyeznek az üzleti célokkal, érdemes elindítani a prototípust, hogy a tesztelés során nyert információk alapján továbbfejlesszük. Ha azonban nem, akkor inkább a jelenlegi fő termék vagy egy más MVP elindítása a célszerű döntés.

Hogy ezekben a kérdésekre valós válaszokat adhassunk, érdemes segítségül hívnunk a Business Modell Canvast – erről itt olvashatsz bővebben.

Megtaláltuk azokat a konkrét problémákat, amelyekkel a célcsoport küzd?

Ha a csapat megállapodott abban, hogy a tervezett MVP stratégiailag beleillik a cég elképzeléseibe, ugorhatunk a következő lépésre: megfogalmazzuk azokat a konkrét megoldásokat, amelyeket a termék vagy szolgáltatás a célcsoportnak (buyer personának) nyújt.

Fontos azonban, hogy ezen a ponton még nem a teljes termék által képviselt tulajdonságokat és előnyöket kommunikáljuk. Csupán azokra fókuszálunk, amelyeket az MVP-nk is teljesít.

És ahogyan az Innovation Designnal kapcsolatban sosem, úgy most sem bízhatjuk a megérzéseinkre a döntést, hogy mely korlátozott funkciók kerülhetnek az MVP-be. Ehelyett az alábbi tényezőkre és számokra érdemes támaszkodnunk:

felhasználói kutatás és versenytárselemzés eredményei;
az egyes termékelőnyök vagy -tulajdonságok fejlesztési költségei;
milyen gyorsan tudjuk iterálni az egyes funkciókat a felhasználói visszajelzések alapján.

Írjunk történetet a termék funkcionalitásából

Ahhoz, hogy a célpiacunk megértse, miért is jó döntés, ha a mi termékünket vagy szolgáltatásunkat (esetünkben prototípusunkat) választja, történeteket kell mesélnünk neki, amibe bele tudja képzelni magát. A problémát, amivel küzd, a vágyat és a félelmet, amit ezzel kapcsolatban érez, és az elkerülendő veszteséget, valamint a megszerezhető jutalmat is.

Az ilyen történeteken keresztül elmesélt funkcionalitások könnyebben ragadnak meg, ráadásul az analógiáknak köszönhetően a megértés folyamata is gyorsabban zajlik le a potenciális ügyfelekben – ez a marketing és az értékesítés dolgát is egyszerűsíti. Márpedig egy ennyire túltelített információs közegben a gyors megértés jó eséllyel válik a fogyasztói döntés egyik fő indokává.

A funkcionalitás alapján határozzuk meg a fejlesztői lépéseket

Ezen a ponton már tisztán látjuk, milyen stratégiai pontok mentén, milyen alapvető funkciókkal látjuk el az MVP-nket. Sőt, már történeteken keresztül el is tudjuk magyarázni a célcsoportunknak, miért van épp erre szükségük. Itt az idő, hogy mindezt fejlesztési tervvé alakítsuk.

A fejlesztési terv összeállítása során kiemelt figyelmet kell fordítanunk arra, hogy a termék vagy szolgáltatás valóban „Viable” legyen. Azaz nyújtson megoldást egy teljes problémára – oldja meg a célcsoport egy elvégzendő feladatát –, és a korlátozott funkciói ellenére is nyújtson magas felhasználói élményt.

Az MVP nem egy félig fejlesztett funkciókkal és előnyökkel teli felület. Egy működő termékről beszélünk, amely – bár a jövőben fejleszthető –, önmagában is értékesíthető.

3. fejezet

Az MVP működése példákon keresztül

A módszertan elsajátításában komoly segítséget jelenthet, ha megnézzük, mások hogyan csinálták előttünk. Vizsgáljuk meg, milyen sikertörténeteket ismerünk, és mit tanulhatunk ezekből.

Airbnb, avagy egy felfújható matraccal is tesztelhetünk

Az Airbnb nem egy közel 50 milliárd dollárt érő cégként kezdte. Sőt, tökéletesen funkcionáló weboldallal és applikációval sem közvetlenül az indulás előtt rendelkeztek.

Egy férfi a telefonjén épp az Airbnb alkalmazást nyitja meg egy Airbnb lakásban.

A mára dollármilliárdokat érő üzleti modell alapötlete igen prózai okokra vezethető vissza: az alapítók (Brian Chesky és Joe Gebbia) szerették volna kifizetni az újonnan bérelt San Fransiscó-i lakásuk bérleti díját.  És mivel épp volt néhány felfújható matracnyi helyük a nappaliban, kiadják a helyiséget turistáknak, átutazóknak.

És épp kapóra jött nekik, hogy mindezt egy olyan városban akarták megvalósítani, amelyben az év különböző szakaszaiban számtalan nagy létszámú konferenciát szerveznek, ezért általában bonyolult és drága volt a szobafoglalás.

Az előfeltevés tehát az volt, hogy idegenek – akár konferencia-résztvevők – hajlandóak fizetni idegeneknek, hogy a lakásukban élhessenek néhány napig.

A feltevés tesztelésére pedig a legegyszerűbb módot választották: felfújható matracokat biztosítottak, ingyen wifivel, reggelivel, és networking ígéretével. Ebből ered a szolgáltatás elnevezése is: Airbad and Breakfast.

Nem vettek ki egy másik lakást, vagy vásároltak komolyabb összegekért ágyakat. Ehelyett a lehető legalacsonyabb költségen indították el a szolgáltatást, hogy olyan gyorsan tesztelhessék az elméletüket, amilyen gyorsan csak lehetséges.

A Spotify megmutatja, hogyan építs hangonként mesterművet

A Spotify tökéletes példa arra, hogy egyetlen alapvető funkció bevezetése, szemben a megszámlálhatatlan menő funkció fejlesztgetésével, hogyan repíthet a sikerig egy céget.

A Spotify applikáció megnyitva iPad tableteken.

Ahhoz, hogy megalkossák a legjobb zenei streaming szolgáltatást, a Spotify fejlesztett egy asztali alkalmazást, majd egy zárt bétateszt keretein belül felmérte a piac reakcióit.

Ebből kiderült, hogy az általuk kigondolt MVP és az ehhez kapcsolt Freemium modell (az üzleti modellekről ebben a cikkben olvashatsz) tökéletesen lefedik a felhasználói igényeket.

Ezután kezdtek előadók tömegével megegyezni, mobilalkalmazást gyártani iOS-re és Androidra, valamint előkészíteni a tengerentúli terjeszkedést, hogy az USA piacát is letarolják.

A Harvard Egyetem digitális évkönyvétől a globálisan ismert Facebookig

A mára globális méreteket öltött, kb. 2,6 milliárd regisztrált felhasználóval büszkélkedő Facebook 2004-ben egy egyszerű MVP mentén született meg: összekötni az egyetemi hallgatókat csoport- és szaktársaikkal, online.

Az ötlet már akkoriban sem volt újszerű, hiszen több hasonló platform is létezett ezzel a céllal. A Facebook azonban, köszönhetően egyszerű, felhasználóbarát kezelőfelületének, funkcióinak és designjának, hamar maga alá gyűrte a konkurenciát.

A Facebook kezdetben a Harvard Egyetem diákjai számára létrehozott kvázi évkönyv volt, majd rohamosan terjedni kezdett a többi egyetem hallgatói között is – eleinte csak az USA-ban, később világszerte.

A Facebook alapítója Mark Zuckerberg épp prezentál, háttérben a Facebook logójával.

A siker kulcsa itt is az volt, hogy Zuckerberg eleinte csak azokat az alapvető funkciókat fejlesztette el, amelyek az felhasználói élmény kiszolgálását és a szolgáltatás „eladhatóságát” szolgálták. Mindezt továbbá csak egy kis csoport (a korai alkalmazók) számára tették elérhetővé, és az ő visszajelzéseik alapján fejlesztették a szolgáltatást.