Sok a félreértés a termékfejlesztésben de a szervezetekben úgy általában is arról, mit is jelentenek ezek a fogalmak, hogyan és mire kéne használni őket. Mi az a Minimum Életképes Termék, mit várhatunk tőle és mire nem alkalmas.
MVP: Minimum Viable Product – tákolmány amely validál
MLP: Minimum Lovable Product – élmény amibe bele lehet szeretni
MMP: Minimum Marketable Product – amivel pénzt lehet keresni
📺 A fenti dolgokról beszélek az alábbi videóban:
Összefoglaló
📑 A videóban az alábbiakról van szó:
A fenti videóban arról van szó, hogy az MVP (Minimum Viable Product) koncepció lényege nem csak a termékfejlesztési dimenzióban, hanem általában a problémamegoldásban és a stratégiaalkotásban is alkalmazható. Az MVP egy kísérlet, egy teszt, amelynek célja, hogy tudást szerezzünk, információhoz jussunk. Az életképesség nem csak a termék életképességét jelenti, hanem inkább egy kísérlet életképességét, amelyből információval gazdagodunk.
A videó kiemeli, hogy az MVP nem egy kész, használható termék, hanem egy olyan kísérlet, amely segít megérteni, hogy mi működik és mi nem. Az MVP a tudás felé billenti a mérleget, az információ szerepét hangsúlyozva. Az elérni kívánt tudást a hipotézisek és sikerkritériumok segítségével határozzák meg.
A videó kiemeli a fontosságát annak, hogy egy terméket inkrementálisan, kis lépésekben fejlesszenek, és folyamatosan mérjék a változtatások hatását. A változtatásokat gyakran és kis részletekben kell bevezetni, hogy könnyen meg lehessen határozni azok hatását.
A videó hangsúlyozza az adatvezérelt gondolkodás fontosságát, ahol a mérési eredmények alapján lehet döntéseket hozni. A kohort-analízis segít megérteni, hogy a felhasználói csoportok hogyan reagálnak a változásokra, és segít a tanulságok levonásában.
A videó beszél a “pivot or persevere” döntésről, amely a stratégiai változtatásokról szól. A stratégia módosítása, vagyis a pivot, akkor szükséges, ha a hipotézisek alapján az eredeti irány nem bizonyul eredményesnek. A videó hangsúlyozza az MVP technika alkalmazását az információgyűjtés és a stratégiai döntések megalapozására a változó környezetben.
Végül bemutatja a Minimum Lovable Product (MLP) és Minimum Marketable Product (MMP) koncepciókat, amelyek további szempontokat nyújtanak a termékfejlesztési folyamatban.
Átirat
🤖 A videó gépi átirata:
Hát mit jelent az, hogy valami életképes, ugye? Hát eleve ez mit jelent a hétköznapokban, például itt vannak ezek a kiváló datolyapálmák, amiket én magam ültettem, olyan magokból, amiket a boltban vett datolyának a magjai, és hát legalább egy évig a fiókban voltak ezek a magok, és elültettem őket, kíváncsi voltam, hogy mi fog történni, és kinőttek. Szóval ez az életképességnek egy definíciója, hogy akármit túlélsz. De ami engem most jobban érdekel, meg amiről ez a videó szól, az ennek inkább a termékfejlesztési dimenzióban való értelmezése. Most ugye biztos sokan hallottatok már azokról a fogalmakról, amik között nagyon nagy kavar van általában, amiket főleg angolul használjuk őket, hogy minimum viable product, minimum lovable product, minimum marketable product. Ezek ugye, magyar megfelelő ezeknek nem nagyon vannak, de ugye a viable az az életképességet jelenti ezekben a kontextusokban, mint magyar szó. De mit jelent az, hogy minimum viable product? Ezzel szeretnék egy kicsit foglalkozni ma, mert úgy érzem, hogy rengeteg félreértés, meg ilyen miszkoncepció van ezzel kapcsolatban, hogy emberek tök magabiztosan gondolnak erről dolgokat, hogy ez mit jelent, és hát én nem vagyok meggyőzve róla, hogy azt jelenti. Szóval ez most akkor az én értelmezésem, hogy szerintem mit jelentenek ezek a fogalmak, lehet vele vitatkozni. Amit én vállalati környezetben nagyon sokat tapasztaltam, az az, hogy ez a minimum életképes termék, a minimum viable product koncepciót, ezt vezetők, általában a felső vezetők, minél távolabb vannak egy termék fejlesztési dimenziótól, annál inkább jellemző ez, általában ezt a kifejezést arra használják, hogy mi lesz az 1.0-es verziója a terméknek, amit kiadunk. Tehát, ha mondjuk kell egy új CRM rendszer, egy customer relationship management, ilyen ügyfélkezelő rendszer a szervezetben, akkor gyakran az történik, hogy ennek a specifikációja elkészül, hogy ebbe mi kell belekerüljön, és azt mondják, hogy ez az MVP, ez a minimum viable product, ez az, ami nekünk kell. És ők igazából semmi mást nem értenek ez alatt, csak azt, hogy ez az első release, ez az első verzió, amit szeretnénk látni, hogy működik, és utána majd lesznek további verziók is, de azok mind egyre jobbak lesznek majd persze. És akkor, amikor ez az általuk definiált MVP elkészül, akkor általában nagy hátradőlés van, hogy na, szuper, akkor most beértünk a célba, ez kész van, lehet pihenni, és majd egyszer jön egy következő verzió, egy frissítés ehhez. Na most, ugye miért nem jó ez a megközelítés, vagy miért nem ezt jelenti szerintem, vagy azok szerint, akiket én fontosnak gondolok ezen a téren. Ugye általában az a része, hogy minimum, az megy minden üzleti döntéshez vannak, hogy az mit jelent. Hogy ugye kevés befektetett energiával, a lehető legkevesebb investment-tel mit lehet elérni. Ahol a problémák szoktak kezdődni, az a viable meg a product rész, ez a kettő, ahol elcsúszik, hogy életképes és termék. Na most ez mit is jelent igazából? Ez a koncepció, ez igazából arról szól, hogy a minimum viable product, az egy kísérlet tulajdonképpen, egy teszt tulajdonképpen. Tehát az nem egy termék, ami használható termék, hanem egy olyan kísérlet, amitől azt reméljük, hogy tudást szerzünk belőle, tudásra teszünk szert. Tehát ha elképzeltek egy ilyen mérleget, ugye az egyik oldalon a tudás van, a másik oldalon a terméknek az értékessége, tehát knowledge value és product value, akkor ugye ez a mérleg a folyamat elején a tudás felé billen, az a fontos nekünk, hogy információt szerezünk, mert információból fogunk tudni egy jó terméket fejleszteni. Később, amikor már értjük, hogy mi van, akkor az életciklusában később a termék már tud sokkal inkább a product dimenzió felé billeni, de az elején meg kell értsük, hogy tulajdonképpen mire van szükség, mert az alapvető probléma az, hogy általában ezt nem tudjuk. Tehát szerintem azok a sikeres szervezetek és azok a jól működő rendszerek, ahol nem termékeket próbálunk fejleszteni, vagy szolgáltatásokat, az tök mindegy, hanem kísérleteket végzünk, ahol azt mondjuk, hogy ahogy a Lean Startup-ban mondja az Eric Rice, hogy the experiment is the product, tehát maga a kísérlet az, ami nekünk fontos, és ha sok kísérletet végzünk, akkor automatikusan annak az lesz az eredménye, hogy előbb-utóbb ebből kiesik egy termék, ebből így lesz valami, mert a kísérletek során rájövünk dolgokra. Picit úgy lehet ezt talán analógiaként elképzelni, mint mondjuk a párkeresést, hogy ugye így a termék tekintetében, ugye nem egy férjet, vagy egy feleséget keres az ember, persze van, aki azt keres, de szerintem a sikeres párkeresés az nem így működik, hanem ismerkedik, megismerkedik emberekkel, barátkozik velük, beszélgetnek, és akkor ebből esetleg kialakulhat az, hogy ők mondjuk egy házas pár lesznek, egy férjé, vagy egy feleségé válik az az ember az én számomra, de hogy ez nem az alapvető célja a folyamatnak, hanem az a célja, hogy megismerjük egymást, hogy tanuljunk, hogy ismeretekhez jussunk. És ebből automatikusan majd így lesz valami. A termékfejlesztés is egy ilyen szerelem dolog, szerintem, hogy fontos arra időt és energiát szánni, hogy információhoz jussunk, hogy megértsünk dolgokat, hogy kísérleteket végezzünk, és ha sok kísérletet elvégzünk, ha elég kísérletet elvégzünk, ha a szervezetet arra állítjuk be, hogy itt folyamatos kísérletezés van, aminek persze van egy csomó háttérfeltétele, például az, hogy nem büntetjük meg azt a valami nem sikerül, ugye, hasonlók…, ezeket a fail-safe, vagy fail-fast kultúráknak szokták nevezni. Szóval, ha sok kísérletet végzünk, abból előbb-utóbb rá fogunk jönni valamire, ami egy jó termék, ami nekünk jó. Most hogy lehet ezt, akkor próbáljunk tényleg egy ilyen nagyon hétköznapi példát venni, hogy mondjuk én egy kávézót akarok nyitni, mert ez nem csak szoftver termékek esetén működik ez a dolog, hanem bármilyen termék vagy szolgáltatás esetén. Akkor ugye a mai, nem tudom, újgazdag vállalkozó ezt úgy csinálja, hogy a lakásával szemben van egy üres üzlethelyiség, akkor ő ezt megveszi, vesz egy csomó kávét, meg gépeket, meg mindent, és azt mondja, hogy ne gyerünk, akkor próbáljuk meg. Tehát neki az az MVP-je, hogy felépít egy kávézót, de csak, nem tudom, egy pincért vesz föl, aki a pultos is egyben, és akkor ettől ez minimum, ez a termék, minimum életképes termék. Most ez tipikusan az, ami általában ilyen irtózatos kudarcokba szokott torkollani, mert kiderül, hogy teljesen rossz helyen van a kávézó, tehát itt senki nem akar kávét inni, nem is értünk hozzá, az alkalmazott az nem tudom, nem kompetens, százféle probléma előjöhet, vagy az embereknek eleve nem erre van igénye, nem így, nem ebben a formában. Tehát, ahogy ezt mondjuk lehet jobban csinálni, az az, hogy keresek olyan helyszínt, ahol azt gondolom, hogy ott lehetőleg szükség van egy kávézóra. És mondjuk elkezdek ott emberekkel beszélgetni az utcán. Ez lehet egy minimum viable product, hogy én kávét beszélek a számmal, és azt mondom, hogyha itt lehetne kávét kapni, beugrana ide egy kávéra, egy nem tudom, egy félórára, vagy ez magának mennyire lenne releváns, mint szolgáltatás. Kirakhatok egy ilyen cetli letépegetős papírt, mint a “lakáskiadó”, hogy tépj egy cetlit, ha innál itt egy kávét, mondjuk. És akkor egy következő fázisa ennek lehet az, egy következő szintje az MVP-nek, mert egy MVP-ből több is lehet, ugye? Tehát, hogy nem csak egyszer végzünk kísérletet, hanem kísérletek sorozatát végezzük. Egy következő kísérlet az, hogy kiállok egy termosszal oda, és viszek magammal mittudom én, két liter kávét, és megnézem, hogy mennyi idő alatt tudom eladni. Utána hozok egy ilyen kis kocsit, egy ilyen büfé kocsit, és azzal tíz liter kávét megnézek egy fél nap alatt, hogy mennyi idő alatt megy el, vagy utána odajövök egy ilyen büfé kocsival, és megnézem, hogy az mennyire működik, és hozok még asztalokat, és kirakom oda őket a placcra, meg székeket, és megnézem, hogy leülnek-e egyáltalán az emberek, vagy csak sietnek a munkába, és reggel nyolckor bekapnak egy kávét, mert az tök jó nekik, vagy inkább délután, amikor a barátaikkal akarnak beszélgetni, milyen jól jön nekik, hogy itt van egy kávézó. És akkor utána egy következő szint lehet az, hogy bérelek egy már működő kávézót, hogy mondjuk tanuljak róla, hogy ez hogy működik, vagy építek egy minimál változatát ennek a kávézónak ebben a bérleményben. És csak egy legutolsó szint az, hogy én vásárolok egy kávézót. Tehát mindig mi az a minimum szint, amit befektetek ahhoz, hogy a maximális információt megtudjam. Ez a kulcsa ennek az egész MVP koncepciónak. Na most ez a minimum életképes termék fogalom, ez egy több rétű dolog, tehát ezt lehet érteni egy termék szintjén, de lehet akár annak egyes funkciói szintjén érteni, vagy egy üzleti stratégiának a szintjén is lehet így gondolkozni. Tehát ez nem egy ilyen limitált dolog, hogy ez konkrétan csak termékek fejlesztésére jó, ez igazából bármilyen problématér megközelítéséhez egy szemléletmód. Ahol gyakorlatilag az a lényeg az egésznek, hogy amit kiadok, a termékem, az egy annyira leegyszerűsített változata a terméknek, ami pont annyit tartalmaz, ami számomra a legfontosabb kérdéseket megválaszolja. Tehát gyakorlatilag az egy tákolmány, egy olyan kézzel hajtós dolog, ami azt szokták mondani, hogyha nem szégyelled az MVP-det, akkor már túl sokat invesztáltál bele. Tehát ha úgy vagy vele, hogy nézzétek meg, ez valami, az már nem az MVP, az már teljesen más dolog, az nem egy minimum életképes megoldás, hanem az valamennyi, mert te sokkal többet beleinvesztáltál, mint amennyi ahhoz kellett volna, hogy választ kapja kérdésedre. Na most ugye itt a kérdés az egy nagyon hangsúlyos dolog, tehát úgy építünk minimum életképes terméket, hogy van egy kérdésünk, ezt általában hipotézisnek nevezzük, hogy én gondolok valamit, hogy mi, mivel, hogyan függ össze. És ezt a kísérletet, ezt arra készítem, hogy az én hipotézisemet validáljam, hogy ez vajon tényleg igaz-e, mert lehet, hogy egy hülyeség, amit én gondolok. Ugye ismét a tudásról van szó, nem a termékről, a tudásról. És ahhoz, hogy én egy ilyen dolgot validálni tudjak, ahhoz kellenek olyan kritériumok, amikre azt mondom, hogy na, ha ezek teljesültek, akkor sikeres a kísérlet. Ezeket acceptance criteria-nak szokták nevezni a külföldi szakirodalomban. Tehát van egy hipotézisem, hogy én azt gondolom, hogy ez, ezzel összefügg, hogyha ezt a funkciót betesszük a termékbe, akkor így és így fog változni az előfizetők száma, vagy az, hogy itt az embereknek van szüksége kávéra, és szívesen beülnének egy kávét meginni. És akkor ennek mik a kritériumai, a sikerkritériumai, mikor gondolom én azt, hogy ez igaz, ez a feltétel, vagy ez a feltételezés, és ezeket kell tudjam definiálni előre. Tehát ezt nem tudom megmondani, hogy én mi alapján fogom eldönteni, hogy az emberek akarnak-e kávézni errefelé, akkor gyakorlatilag nem tartok sehol. Tehát akkor még mindig ott tartok, hogy igazából a kérdést nem értem, nem tudtam egy megfelelő kérdést kitalálni. Na most ha ezek megvannak, ezek a sikerkritériumok, akkor egy következő fázis ebben az egész MVP koncepcióban az, hogy ezt mérni kell tudni valahogy. Tehát nem elég azt mondani, hogy nekem ezek a feltételeim, arra meg kell tudjam mondani azt is, hogy hogyan lesznek ezek megmérve. Mi lesz az a technológia, amiből én tudni fogom, amiből ki fog jönni egy szám, és ha az a szám ennyi vagy annyi, az jelent nekem valamit. Ugye, itt picit szétágazik a dolog több felé, mert ez a mérés dolog, ez egy nagyon kritikus és nagyon-nagyon alul értékelt, vagy alul reprezentált fogalom, vagy ilyen gondolkodási kör ma a szervezetek nagy részében. Mert ugye gyakran az történik, hogy valamit mérünk, például mondjuk egy új termék esetén, mondjuk az előfizetők számát, hogy hányan regisztráltak, mondjuk. És akkor látjuk, hogy ez megy fölfelé, ez a szám, és örülünk, és azt mondjuk, hogy azt a mindenit, de milyen szuper, hogy milyen jól teljesít a termék, a csapat is, mindenki nagy, big happy family, mindenki nagyon szuper. Na igen, csak ugye tudjuk-e, hogy miért? Mert megint ott tartunk, hogy információra van szükségünk arról, hogy mi történik. Na most hogy lehet ezt érteni, hogy mi történik? Az, hogy egyre több előfizető lesz, az akármit is jelenthet. Az jelentheti azt is, hogy szuper volt a marketing kampányunk, az lehet azért, mert tényleg szuper maga a termék, vagy azért, mert van benne egy olyan funkció, amiről nem is tudjuk, hogy az az, de az kell mindenkinek. Bármi lehet az oka. Ami itt egy nagyon fontos dolog, hogy egy kis türelem, meg fegyelmezettség legyen bennünk, plusz egy kis magas fordulatszámú megközelítés olyan értelemben, hogy inkrementálisan fejlesszük a termékünket. Tehát mindig kis részeket teszünk hozzá, minél gyakrabban, mert minél kisebb egy olyan változtatás, amit beviszünk a rendszerbe, annál pontosabban látjuk a méréseinkben, hogy ez a változtatás mit okozott. Mert amikor azt csinálom, hogy van egy termékem, amit beviszek egyszerre, 10 change-et, 10 változást, és utána megváltoznak a mérési eredmények, hát honnan tudom, hogy melyik hatására változott. Tehát sokkal rosszabb az, hogyha én nem tudom, két hetente, vagy havonta kiadok egy új verziót a termékemből, és azt mondom, hogy hát akkor most itt végeztem egy kísérletet, és akkor ennek a kísérletnek itt vannak a mérési eredményei, hát nem tudom, hogy mit mértem meg. Ennél sokkal jobb az, hogyha naponta, két naponta, három naponta kiteszek dolgokat, és folyamatosan nézem, hogy erre hogyan reagálnak emberek, hogyan reagálnak a csoportok. És ugye még egy fontos dolog ezzel kapcsolatban, hogy a felhasználó meg a felhasználó sem ugyanolyan, tehát lehet különböző ilyen felhasználói csoportokat definiálni, ezeket kohorsznak nevezik, cohort, angolul, amikor valamilyen szempont mentén csoportosítasz felhasználókat. Na most ezek lehetnek olyan szempontok, hogy a nem tudom, az összes 20 és 40 év közti vidéki orvos, meg lehet olyan csoportosítás, hogy azok a felhasználók, akik beregisztráltak, azok a felhasználók, akik legalább egy tranzakciót már végeztek a rendszerben, azok, akik több mint ötöt végeztek, azok, akik előfizettek a fizetős csomagra is, stb. És ha a teljes felhasználó gárdát, tehát az összes felhasználómat szét tudom szálazni ilyen csoportokba, akkor az egy dolog, hogy az össz szám az mondjuk növekszik egy siker esetén, de ami az igaz információt adja, amellett, hogy kis változásokat viszek be, az az, hogy ezek a csoportok egymáshoz képest hogyan változnak. Tehát, ha mondjuk a fizető felhasználóknak a száma növekszik-e az újonnan regisztráló felhasználókhoz képest? Tehát százalékosan ezek hogy oszlanak meg, és ebből lehet egy nagyon szép ilyen kumulatív flowchartot csinálni, ebben most nem megyek bele, hogy ez pontosan hogy néz ki, de ez egy ilyen réteges diagram, ahol látod azt, hogy egy-egy ilyen sáv, aki valamelyik csoportot reprezentálja, az egy másik sávnak a rovására például hogyan növekszik, vagy hogyan csökken és add teret egy másiknak. Mert ugye itt százalékokat nézünk egymáshoz képest. Tehát, ha például viszem ezt az új change-et, és látom, hogy azoknak a felhasználóknak a száma, akik nem tudom, ötnél több interakciót végeztek a rendszerbe hirtelen, megnövekszik 10-15-20 százalékkal, akkor értem, hogy ez a változtatás, ez a change, ezt az eredményt hozta, és a hipotézisemet, ami a változáshoz kapcsolódott, ezt rögtön tudom validálni. El tudok róla gondolkozni, hogy aha, akkor ezek szerint ez működik. Jó, szóval ezek nagyon fontos dolgok, hogy hipotézis kell legyen, hogy meg kell tudjam mondani, hogy mik a sikerkritériumaim a hipotézishez kapcsolódóan, és meg kell tudnom mérni azokat. Ezek nyilván össze is függnek egymással, tehát sokszor a sikerkritériumot ezt egy mérési eredménnyel írom le. És ez akkor lehetséges, hogyha pici inkrementumokba fejlesztem gyorsan a termékemet, nagy fordulatszámon, ami lehetséges, hogyha kis dolgokat változtatok rajta, ugye. Illetve, hogyha értem azt, hogy milyen felhasználói csoportjaim vannak, milyen kohorszok vannak, akikkel én dolgozok, vagy hát nem én dolgozom, de akik a terméket használják, és akkor ezekből az információkból le tudok szűrni tanulságokat. Na és ezek a tanulságok azok, amik ennek az egész MVP mindset-nek a koronája, a csúcsa, amiről ez az egész szól, amit hát angolul úgy mondják, hogy pivot or persevere, ugye? Magyarul ez a pivotálás szó, ez így magyarul is megjelent, hogy pivotálni, az ugye azt jelenti, hogy fordulni szó szerint, a persevere meg azt jelenti, hogy kitartani, de ugye ezek azok a döntések, amikor arról kell gondolkozzak, hogy kitartok, tehát hogy jó az irány, amerre megyünk, csak még valamit tekergetni, változtatni kell, vagy ez a változás, amit csináltunk, ez jó lett, vagy pedig ez a pivotálás, ez a stratégiai fordulás, az azt jelenti, hogy változtatok a termék stratégiáját. Tehát ugye a change az, amikor magát a terméket módosítom, hogy másképp működjön a stratégia érdekében, a pivot az, amikor a stratégiát módosítom, és azt mondom, hogy rossz kérdéseket teszünk föl, rossz hipotéziseink vannak, és ezeket kell lecseréljük újjakra, és más irányba kell menni. Nem hajót kell építeni, hanem tengeralatjárót. Nem tengeralattjárót kell építeni, hanem űrhajót. Szóval ezek azok a stratégiai változások, amik nagyon fontosak, és az MVP technikával ezeket meg lehet alapozni mérési eredményekkel, data-driven management, tehát adatvezérelt management használatával lehet ezekről gondolkozni, és döntéseket hozni. Szóval ezért nagyon fontos ez az egész. És akkor ennek a, ugye sokat beszéltem most erről az MVP dologról, de igazából ez az eszencia, ez a lényeg az egésznek. Neki vannak még ilyen kis testvérei, ez a Minimum Lovable Product, meg Minimum Marketable Product. Ezek akkor mit jelentenek, erről is egy pár szót. Tehát az MVP-nél a fókuszunk ott van, hogy információt kell kiszedjek a rendszerből. Mi az a legkevesebb befektetés, amivel egy olyan kérdésre megkapom a választ, ami nekem stratégiaileg nagyon fontos. Ez egy abszolút kézzelhajtós dolog, tehát van, ahol úgy csinálnak meg egy MVP-t, hogy az emberek néznének ilyen videókat, és akkor leültetnek 30 embert, és egy kivágott ilyen YouTube kartonpapír keretbe, ott valaki eljátszik egy videót, hogy ne tegyük fel, hogy ez lenne a videó, akkor ez például hogy tetszik. Tehát ez is lehet egy MVP, vagy az is lehet egy MVP, hogy nyújtok valamilyen szolgáltatást, ami majd egy automatizált dolog lesz, de előbb, hogy erre van-e igény, ezt úgy tesztelem le, hogy én ülök a gép mögött, és amikor beérkezik egy kérés, akkor én napi x órában azzal foglalkozok, hogy ezeket megválaszolom, ami később majd automatizálva lesz. Tehát ez ennyire ilyen tákolmány lehet egy MVP. Most ezzel ugye az a probléma, vagy nem probléma, de az az adottság, hogyha van ugye ez a szép kalap formájú görbe, ami a technikai innovációknak az adoptációs görbéje, ugye az elején csak egy-két ilyen vizionárius ember, ilyen early adopterek hajlandóak csak kipróbálni a termékünket, és aztán később, amikor már ez elkezd egy népszerű dologgá válni, akkor majd egyre többen jönnek, és vannak, akik csak a legvégén szállnak fel erre a vonatra, van, aki még mindig, nem tudom, Windows XP-t használ, és csak akkor fogja lecserélni egy magasabb verziójú Windows-ra, hogyha ez így megszűnik a föld színéről, és nem tudom, leég a háza, és bennégnek az install CD-k, amiről a Windows XP-t telepítette. De vannak azok az early adopterek, akik nyitottak erre, akik partnerként tudnak jönni, és azt tudják mondani, hogy engem tökre érdekel az, hogy te milyen terméket fejlesztesz, és szívesen jövök ebbe segíteni, egy beta teszter például. Őket egyébként elég könnyű kiszűrni, mert hogyha pitch-eled, ha elmondod valakinek a koncepciódat, hogy te mit szeretnél csinálni, akkor ők lesznek azok, akik azt mondják, hogy “wow, ez nagyon jó, ez szuper, és mikor lehet ezt kipróbálni?” És lesznek azok, akik azt mondják, hogy “fú, ez nagyon jó, sok sikert hozzá, majd szóljál, hogyha kész van, és akkor majd kipróbálom én is.” Na, ők nem ezek. De akik ilyen korai felhasználók, ők tök nyitottak, és nekik tök oké az, hogy egy tákolmányt kipróbáljanak. Nekik ez egy izgalmas dolog. Tehát őket keresed, ne essünk itt egy félreértésbe, hogy ez nem egy szuper életképes termék, ami mehet a piacra, és lehet vele tarolni, hanem ez egy kísérlet, és a kísérlethez kvázi kísérleti kutatók kellenek, akik hajlandóak ebbe együttműködni. Jó, szóval ők ezen a görbén, ők az elején vannak. Most akik már hátrébb vannak, nekik ugye szükségük van erre, hogy minimum lovable product, ezt úgy is szokták mondani, hogy van egy olyan fogalom is, hogy minimum viable experience, ugye, mint customer experience, vagy client experience. Tehát mi az az élmény az ügyfélnek, ami az, amivel ő már oké? Tehát ha mondjuk csinálsz egy, mit tudom én, egy webshopot, akkor ezt meg lehet úgy csinálni, hogy kockadobozokból van az egész, és lehet benne kattingatni, és az MVP-nek jó is lesz. De azért ezzel ne menj ki a piacra, mert ezt meglátja egy mai felhasználó, aki ahhoz van szokva, hogy minden gyönyörű szép lekerekített, és Facebook, Instagram, YouTube szuper felületek vannak, akkor neki ez egy ilyen nagyon gáz, old school tákolmány hangulatot fog sugározni, és azt fogja mondani, hogy ez a termék, ez neki nem tetszik, nem konfortos, nem kényelmes, nincs meg az experience, ugye, tehát nem lovable, nem tudja szeretni, nem tud szerelmes lenni ebbe a termékbe. Tehát ez egy következő szín, de itt már arról beszélünk, hogy van egy MVP-nk, amit mi kitaláltunk, hogy az hogy van, azt leteszteltük, az működik, a hipotézésünket validáltunk, és most ezt szeretnénk megcsinálni egy olyan formátumban, hogy ezt több emberhez el tudjuk juttatni, és még több visszajelzést tudjunk kapni, de nekik már magasabb az ingerküszöbük az experience oldalon, ugye a termékélményel kapcsolatban, amit nekünk meg kell ugornunk ahhoz, hogy ők szóba álljanak a termékkel. És a marketable, tehát a minimum marketable product, vagy minimum marketable feature, úgy is szokták ezt emlegetni, az ugye a pénzről szól, arról szól, hogy oké, mi az a funkció, vagy funkció csoport, amit ha hozzáadunk a termékünkhöz, akkor attól növekszik a bevétel. Mi az, ami egy olyan dolog, amit el tudunk adni, amire egybe egy ügyfél hajlandó fizetni. Tehát tök jó, hogy nem tudom, van egy olyan programom, amivel lehet e-mail-eket írni, ez önmagában elég e ahhoz, hogy ezért így pénzt kérjünk, vagy ennél többre van szüksége az ügyfélnek, mert szüksége van arra, hogy nem tudom, rich text formázások legyenek, meg ez össze-vissza legyen integrálva különböző platformokkal, és akkor ugye már ott vagyunk, hogy mondjuk egy Google-ökoszisztéma, vagy egy Microsoft-ökoszisztéma, az ugye attól tud nagyon jó lenni, hogy mennyire össze vannak benne kapcsolva az elemek. Tehát abban mondjuk, hogy mi egy minimum marketable új feature, az egy olyan fogalom, amit ott már nehéz megválaszolni. De az elején, amikor egy ilyen terméket építünk fel, akkor ez is egy szint, amiről el kell kezdjünk gondolkozni, hogy oké, mit éri meg ebből nekünk kiadni egybe úgy, hogy ezért az ügyfél tényleg fog fizetni, ezt ő egy többletként el tudja ismerni, és hajlandó ezért további pénzt áldozni, vagy hát a nulla esetében, hogyha nulláról indulunk, akkor az első befizetést hajlandó megtenni érte. Oké. Hát nagyjából ezeket akartam elmondani. Nagyon sok félreértést látok ezzel az egész témával kapcsolatban, és ezért tök fontos volt nekem, hogy erről beszéljek egy kicsit. Remélem, hogy nektek is volt benne hasznos. Gyertek, látogassatok el a csoportunkba, van Facebook csoportunk, amiben most a legtöbbet aktívkodunk.
ServantKnights 