Ne próbálj tökéletes terméket építeni – gyakran szoktam ezt a tanácsot adni az új ügyfeleinknek. Bátran dobjál piacra egy olyan terméket amiben vannak még hibák és főként ne izgulj amiatt ha csak 1-2 funkció került bele. Mielőtt meglincselnétek, hallgassatok végig.
Nemrég ebédeltem egy ismerőssel, nevezzük a történet kedvéért Hubának. Huba azért hívott meg ebédelni, mert volt egy nagyszerű termékötlete és segítségemet kérte a megvalósításban. Egy digitális ajándékról volt szó, ami nagyon egyedi és örökké megmarad kellemes emlékként. Ő oda volt az ötletért, a feleségének könnybe lábadt a szeme amikor egy ilyennel ajándékozták meg és őszintén bevallom, hogy nekem is kimondottan tetszett az ötlet.
Ilyen ötletei nem mindennap vannak Hubának, ezért nagy elánnal beleásta magát a megvalósításba. Tartalomgyártás, szoftverfejlesztés, marketingterv, a teljes csomag. Csak azt nem értette, hogy én miért nem lelkesedek annyira, hogy máris belevágjunk? Hiszen ő több havi fejlesztési munkát hozna a csapatunknak!
– Nincs rá kapacitásunk? – Éppen akad. – Nem tudjuk megvalósítani? – Dehogynem. – Mégsem tetszik az ötlet? – De igen. – Hát akkor?
Megkértem Hubát, hogy írja le, hogy fog pénzt termelni neki a projekt. – Mi sem egyszerűbb: havonta minimum 100.000 vásárló, aki termékenként $1-t fizet majd.
– Rendben. Mire alapozzuk ezeket a számokat? – Hát ennyi embert simán el tudunk social mediában érni. Aztán az ajándékozottaknak majd annyira tetszik nekik a termék, hogy ők is tovább ajándékoznak másoknak.
Folytathattam volna az interrogációt, de ezen a ponton úgy éreztem elég munícióm van.
– Figyelj Huba, nézzük meg, hogy az eddigi beszélgetésünkből miket feltételezünk a vevőkről:
– Honnan tudjuk, hogy ezek a feltételezéseink mind igazak? – Ezért kell tökéletes legyen a termék, hogy 100% biztos tetsszen nekik.
Ezen a ponton azt javasoltam Hubának, hogy fogja meg azt az 1 darab kész terméket amit a feleségének készített és mutassa meg minél több embernek. Készítsen róla egy bemutató videót és indítson arra egy kampányt. Nézze meg, hogy hányan kérdezik meg, hogy hol tudnak ilyet készíteni. Kérdezze meg, hogy mennyit volnának hajlandóak érte fizetni? Hányszor és hány ismerősüknek vásárolnának ilyen terméket egy évben?
Huba nehezen tudta feldolgozni ezt. Ez a gondolkodásmód teljesen ellentmond a hagyományos termékfejlesztési módszereknek. Egyszerűen elképzelhetetlennek tartják, hogy egy új termék ne legyen az utolsó részletig kidolgozva (Big Bang delivery). Vagy, hogy ne legyen átfogó piackutatásunk és egy biztos piacra lépési stratégiánk.
Megkérdezhetjük viszont, hogy akkor mi történik a sok energiával és pénzzel ami a termék fejlesztésébe fektetünk, ha a vevőktől negatív visszajelzéseket kapunk, mert nem tökéletes a termék? Szerintem ez egy jogos felvetés.
De mi történik akkor, ha ennél sokszorosan több energiát és pénzt fektetünk egy olyan termék fejlesztésébe, amiről később kiderül, hogy nem kell senkinek?
Ha egy tökéletes termékre törekszünk, akkor nagy valószínűséggel nem fogjuk tudni, hogy melyik feltételezésünk volt hamis, ezért a termék valószínüleg teljes újratervezésra szorul. Ha kis lépésekben, minimális erőforrás ráfordítással teszteljük a feltételezéseinket, akkor lehetőségünk lesz tanulni a felhasználói visszajelzések alapján és ezek alapján továbbfejleszteni a termékünket. Ez nevezzük validált tanulásnak.
Mint láttuk, a validált tanulásra azért van szükség, hogy a bizonytalan tényezőket eloszlassunk és ezáltal csökkentsük egy startup projektben jelenlévő, természeténél fogva adott kockázatokat. A validált tanulást gyakorlatban pedig az Építs-Mérj-Tanulj visszacsatolási ciklus segítségével lehet elérni.
Az Építs-Mérj-Tanulj ciklus segít abban, hogy a különböző feltételezéseinkre választ kapjunk. Bár egy termék életciklusában a feltételezések megválaszolásával más-más központi kérdésekre keressük a megoldást, egy dolog biztosan kijelenthető: a legfontosabb feladatunk, hogy minél rövidebb idő alatt új, beépíthető tudást szerezzünk.
Ezt pedig úgy tudjuk elérni, hogy minden feltételezés validálására kísérleteket dolgozunk ki. Különböző feltételezéseket, különböző módon lehet validálni, leggyakrabban egy prototípus segítségével.
Egy prototípus egy olyan termék vagy kísérlet amit minimális erőfeszítéssel (szoftver esetében fejlesztéssel) létre tudunk hozni. Egyetlen célja, hogy a feltételezéseinket le tudjuk tesztelni, azaz validálni. Éppen ezért sokszor olyan funkciók és hiányoznak belőle, amiket elengedhetetlennek tartunk a termék sikeressége szempontjából.
A prototípus létrehozása lesz az Építs szakaszunk az Építs-Mérj-Tanulj ciklusban.
Nem elég, sőt óriási hiba, ha egy prototípust csak belső használatra, azaz saját magunk megnyugtatására fejlesztünk. Nem elég, ha csak mi magunk, szűk körben úgy látjuk, hogy igen, ez működőképes és alátámasztja a feltételezéseinket.
A prototípus célja, hogy minél hamarabb be tudjuk mutatni a potenciális vásárlóinknak, figyeljük meg a reakciójukat, kapjunk visszacsatolást és mindezt támasszuk alá releváns mérőszámokkal.
Ez lesz a Mérj szakaszunk az Építs-Mérj-Tanulj ciklusban, amit rögtön követ a Tanulj szakasz.
A visszacsatolás birtokában nézzük meg, melyik feltételezéseink bizonyultak igaznak. Döntsük el, hogy a termékfejlesztésnek ebben a fázisában közelebb állunk-e a kitűzött céljainkhoz. Ha igen, állítsunk fel újabb feltételezéseket, finomhangoljuk a meglévő prototípust vagy dolgozzunk ki újabb kísérleteket és kezdjük előlről az Építs-Mérj-Tanulj ciklust.
Ha nem, akkor bekövetkezik az ú.n. pivot, vagyis új stratégiát kell kidolgoznunk a célok megvalósításának érdekében.
Bár a ciklust Építs-Mérj-Tanulj ciklusnak nevezzük, mivel az aktivitások ebben a sorrendben történnek, a valóságban ezt pont fordítva kell megterveznünk: definiáljuk, hogy mit kell megtanuljunk (feltételezések), gondoljuk végig, hogy milyen mérőszámokra van szükségünk, hogy alátámasszuk ezeket a feltételezéseket, majd találjuk ki, hogy milyen prototípustt kell építsünk, hogy lefusson a kísérlet és megszerezzük a megfelelő mérőszámokat.
Huba esete azért nagyon egyszerű, mert a kezében volt már egy termék, amit a feleségének készített és amivel le tudja tesztelni az alapfeltételezéseit. Például azt, hogy az embereknek tetszik-e a termék, tényleg hajlandóak-e fizetni érte és tulajdonképpen mennyit hajlandóak fizetni.
Ha pozitívak a visszajelzések, akkor nagyszerű, Huba továbbléphet és elölről kezdheti a Építs-Mérj-Tanulj ciklust. Mostmár elkezdhetne mondjuk másoknak is eladni a digitális ajándékokból.
Ebben a fázisban még nem szükséges előre legyártania az összes tartalmat és szoftveresen automatizálnia a folyamatokat ahhoz, hogy minden esetet lefedjen. Elég volna, ha az elején minden rendeléshez külön legyártja a tartalmat és manuálisan összeállítja a terméket.
Ezzel viszont már kicsiben teszteli azt a feltételezést, hogy lesz-e elég vásárló és mennyi ezek közül a visszatérő vásárló. Továbbá visszajelzést kap arról, hogy mit változtatnának a vevők a terméken, amit Huba később majd figyelembe vesz a tartalom gyártásánál. Ha a tartalmakat mint előre legyártotta volna, akkor nem lenne erre lehetősége.
Sajnos Huba úgy döntött, hogy belevág a tökéletes termék fejlesztésébe. Szeretném ezt betudni annak, hogy Huba olyan iparágban edződött, ahol bevett szokás a Big Bang delivery, de könnyen meglehet, hogy nekem kell az érvelési technikámon javítanom. Idővel mindenesetre eldől majd, hogy mi lesz a projekt sorsa.
A tapasztalatunk az, hogy legtöbb startup projekt elbukik azon, hogy az ötletgazda szerelmes lesz a projektjébe és mindenképpen egy tökéletes, szemet kápráztató terméket akar piacra dobni. Legtöbb sikeres startup ötletgazda már 1-2 ilyen projektet elbukott és tanult a hibájából.
Ők is, mint Huba, egyből a Csillagrombolót akarták megépíteni. Te ne legyél olyan mint Huba!