Mi az az MVP app fejlesztés és vajon szükséged van rá?

tl;dr

• Az MVP egy innovatív - általában digitális - termék piaci bevezetésének első iterációja.

• Célja, hogy költséghatékonyan szerezz információt arról, hogyan reagálnak a felhasználóid az applikációdra és miért szeretik használni, vagy miért nem. Ezeket a következő verzióba építve tökéletesítheted az applikációdat.

• Az MVP-vel ugyanazt az igényt kívánod kielégíteni mint a végleges termékeddel. Azonban MVP-vel éppen csak akkora mértékben valósítod meg ezt, hogy az a jövőbeni felhasználóid számára már észlelhető értéket képviseljen, ezért használják a terméked.

• Egy jól kivitelezett MVP visszajelzései alapján nagyobb ügyfeleket és befektetőket szerezhetsz.

Az MVP (Minimum Viable Product) a lean módszertan egyik fontos alapfogalma és jelentése sokat fejlődött mióta 2001-ben Frank Robinson megalkotta. A napjainkban legtöbbször idézett egyik meghatározás Eric Reistól származik, aki szerint az MVP "egy új termék olyan verziója, ami a csapat számára a legnagyobb mértékben teszi lehetővé a hiteles tanulási eredmények gyűjtését a fogyasztókról, a legkisebb erőfeszítés mellett".

Leegyszerűsítve az MVP tehát egy olyan módszer, mely lehetővé teszi, hogy költséghatékonyan hozzunk létre újszerű digitális terméket, amely képes letöltésre és vásárlásra bírni az első felhasználókat. Az MVP fejlesztés során szerzett tapasztalatokat valamint a felhasználói visszajelzéseket felhasználva hatékonyan bővíthetjük a fejlesztett applikációt, és biztosak lehetünk abban hogy jó irányba haladunk a projektünkkel. Ezért mielőtt belevágnál az applikáció fejlesztés kivitelezésébe az első kérdés amit fel kell tenned:

Megengedhetem magamnak, hogy az applikáció fejlesztésénél mindent egy lapra tegyek fel?

Kis lean menedzsment kitérő A lean menedzsment neve a klasszikus tömegtermelési rendszerrel történt összehasonlításából ered, amihez képest a lean egy “karcsú”, a pazarlást teljesen elvető, vevőorientált stratégiai és operatív eszközöket felsorakoztató módszer. Lényege, hogy a vevői értékteremtés során kevesebb alkalmazottat és eszközt használ, kevesebb idő alatt és kevesebb helyet felhasználva, kevesebb erőforrással hoz létre értéket.

Észlelhető érték, megfelelő mérték és nagyszerűség

A legtöbb MVP tervezés sajnos ezen a ponton meg is áll és az ötletgazda csak annyit jegyez meg, hogy az első egy “olcsó, félkész verzió kell, hogy legyen.” Pedig a “minimális” és “életképesség” habár szükségszerű tényezők, de önmagukban nem elégséges feltételei egy termék sikeres piaci bevezetésének.

Először is mennyi az a minimális? Ennek megválaszolására két dolgot kell figyelembe venned: a felhasználóidat és a versenytársaidat (a piac akár különböző szintjein is). Az elmúlt évtized során óriási mértékben megváltozott a kapcsolatunk a digitális térrel, ami tudatalatt hozzászoktatott minket egy bizonyos minőséghez, amit minden digitális termék esetében elvárhatónak tekintünk. Ez természetesen nem azt jelenti, hogy minden új terméknek Facebook vagy Uber klónnak kell lennie, de el kell fogadnunk, hogy felhasználóként nem elhanyagolható design, funkcionalitás és sebességbeli elvárásokkal rendelkezünk.

Léteznek emellett olyan célcsoport-specifikus igények is, amik jelentős mértékben befolyásolják majd azt, hogyan kell felépülnie a terméked első iterációjának. Nem lehet elégszer hangsúlyozni, hogy a termékednek valós fogyasztói igényt kell kielégítenie, de legalább ilyen fontos az is, hogy a probléma megfelelő mértékű megoldásával észlelhető értéket kell létrehoznod a felhasználóid számára. Ez a “megfelelő mérték” valójában az, amit az MVP tervezése során próbálsz megtalálni. A fentiek alapján mi sokkal inkább célravezetőnek tartjuk a következő gondolatot:

Mi az emberek számára az a már észlelhető érték, amit egy probléma megfelelő mértékű megoldásával létre tudsz hozni nagyszerű termékeddel, miközben kellő mennyiségű információhoz jutsz a következő iterációhoz?

Ennek az információnak a megszerzése természetesen magába foglalja azt is, hogy a célcsoportod early adopterei (magyarul korai elfogadói) hajlandóak időt, energiát és pénzt fordítani a terméked kipróbálására, miközben érdekeltté teszed őket a megoldásoddal, hogy elkötelezett vásárlóiddá váljanak. Ez az elkötelesésre való képesség az, ami az MVP-t az első lépéssé teszi a sikeres digitális termék felé vezető úton.

Korai szakasz és az elsőség mítosza

Korábbi “Mennyibe kerül egy applikáció fejlesztése?” cikksorozatunkból már tudhatod, hogy egy alkalmazás megtérülése rizikós vállalkozás is lehet, ha nem a megfelelő gondossággal méred fel az applikáció fejlesztésének céljául kitűzött igényt. Ráadásul a rossz hír, hogy nincs az a “tuti ötlet”, amit ne tudnának megtépázni a valóság tűéles fogai, és még a legjobban előkészített applikációk is kerülhetnek szorult helyzetbe az alacsony letöltésszám vagy a gyászos visszatérési arány miatt.

Érdemes tehát már a projekt korai fázisban megmutatnod a terved a jövőbeni felhasználóknak és minél több visszajelzést gyűjteni tőlük. Az első felhasználóid úgyis nagy valószínűséggel a célcsoportod töredékét képező early adopterek lesznek majd, akiknek az észrevételei és app használati szokásai alapján tudod majd tovább finomítani az applikációdat. A legtöbben erre heves tiltakozásba kezdenek mondván, ezzel felfedik ötletüket a versenytársak előtt, akik könnyedén elorozzák azt. Biztosan nem gondolnák így, miután szemügyre vették a következő, 101 startup bevonásával készített elemzést, ami egyértelműen megmutatja, hogy a 20 leggyakoribb bukáshoz vezető ok esetében az ötletgazda jelenti a legnagyobb kockázatot induló vállalkozása számára.

Az üzleti életben szeretjük azt hinni, hogy az elsőség minden esetben versenyelőnnyel is bír. Pedig a valóságban azok a vállalatok, amelyek elsőként rukkoltak elő innovatív megoldással hatszor nagyobb arányban végződtek kudarccal, mint türelmes társaik, akik kivárták, hogy az úttörők megteremtsék a piacot és ezáltal kellő információval rendelkezzenek arról, hogyan kell tökéletesíteni az új terméket.

Talán kevés ember van a világon, aki emlékezne a Kozmo névre keresztelt startupra, ami a DVD 1997-es bemutatása után, a lemaradástól tartva azonnal belevetette magát az online fimkölcsönző szolgáltatásuk beindításába. 2001-re a rosszul megtervezett disztribúciós folyamat miatt a cég csődbe ment, miközben a piacon komoly igény volt a DVD kiszállításra. Egyik vetélytársuk lassan haladt a terjeszkedéssel, tovább finomította a kiszállítást és 2003-ra sikerült profitot termelő üzletté fejlődnie. Őket Netflix néven ismerheted.

Felesleges funkció-torlódás – A nagyok is kicsiben kezdték

Az egyik legfontosabb és egyben a legnagyobb kihívást jelentő szempont amikor elkezded tervezni az applikációdat a funkciók kiválasztása és ezek fontossági sorrendbe állítása. Sokan esnek abba a hibába, hogy egy sikeres üzletet a már befutott, sokadik verzió alapján ítélik meg, pedig a csúcsig tartó út sosem rövid.

Nagy valószínűséggel már mindenki hallott az otthonok és szabad helyiségek szálláshelyként való kiadására és foglalására alkalmas piactérről. Azt azonban már kevesen tudják, hogyan alapozták meg lokálisan, két alapvető funkció köré építve a felületet mielőtt sikeresen meghódította a világ 191 országát.

Az AirBnB ötlete 2007 októberében fogant meg Brian Chesky és Joe Gebbia fejében, az első felület pedig a következő év augusztusában indult el San Franciscora fókuszálva. Két szegmenst szolgáltak ki, egy-egy rendkívül egyszerű funkcióval: szálláshely listázás a vendéglátóknak és foglalási felület az vendégeknek. Mivel a couchsurfing ekkoriban kezdett egyre elterjedtebb lenni, a környéken sorra regisztráltak a felhasználók, akik rendelkeztek egy szabad szobával. 2008 nyarán már meg is érkeztek az első vendégek, akik az Ipari Formatervezési Kongresszusra utaztak a városba és nyitottak voltak a drága szállodai szolgáltatások olcsóbb alternatívájára. Az AirBnB már a következő évben gyors fejlődésnek indult, mindez azonban nem történhetett volna meg egy jól előkészített MVP nélkül.

Az MVP egy remek eszköz arra, hogy eljuss a tökéletes termékhez, de természetesen rendelkezik néhány gyenge ponttal is. A legtöbb kezdő vállalkozás már az MVP előtt elköveti azt a hibát, hogy elmulasztják alapkoncepciójuk érvényességének ellenőrzését, vagy ezt nem a megfelelő módszerek segítségével teszik. Ennek hiányában az MVP nem lesz képes arra, hogy a rosszul meghatározott igényt, vagy megoldást megmentse a bukástól. A másik gyakori hiba, hogy az MVP fejlesztését követően csak indirekt mérőszámokra hagyatkoznak, amiből csak az állapítható meg, hogyan használják az első felhasználók a terméket, a miértek megválaszolatlanok maradnak.

Az MVP készítés előnyei

• Pénzt és időt takarítasz meg.

• Ellenőrizheted az app-koncepciód életképességét, még mielőtt komoly összegeket fektetnél a végleges verzió megvalósításába.

• Növelheted a befektetőid bizalmát a valós eredmények felmutatásával.

• Gyorsabban piacra tudod vinni az ötleted.

• Rugalmasan reagálhatsz a kihívásokra.

Az MVP nehézségei

• Komoly erőfeszítést igényelhet az MVP helyes meghatározása és arányaihoz képest sok előkészületere van szükség.

• A funkcionalitás elsődlegessége miatt számos látványelemről le kell mondanod.

• Többszöri fejlesztési körök meghatározása és a módosítási verziók ellenőrzése elengedhetetlenek.

Szükségem van erre egyáltalán?

Ritkán fordul elő olyan eset, hogy nincs értelme az MVP fejlesztésének, azonban ilyenkor is érdemes fontolóra venni valamilyen alternatív módszert az első iteráció bevezetéséhez. Igaz, hogy egy MVP elkészítése komoly felkészülést igényel és az elmúlt évtizedben a fogalom elterjedése miatt rengeteg félreértés, vagy helytelen használat csorbította a megítélését, de továbbra is a legjobb eszköz az innovatív digitális megoldások elindítására.

További említésre méltó megközelítések:

• MLP – Minimum Loveable Product: cél, hogy a fogyasztók kedveljék az appod és ajánlják azt a többi potenciális felhasználónak.

• MMP – Minimum Marketable Product: cél a piacra jutáshoz szükséges idő rövidítése a végső UX kialakításához szükséges funkciók megtalálásával.

• MAP – Minimum Awesome Product: cél a felhasználók korábban említett elvárásainak és az első verzió képességeinek közelítése egymáshoz, ehhez általában UX és design eszközökkel bővíthető a termék.