A múltkor meséltem Hubáról, akinek volt egy startup ötlete. Ő akkor úgy döntött, hogy egyből belevág a termékfejlesztésbe anélkül, hogy az ötletet előzetesen validálta volna. Most meg szeretném mutatni, hogy miként lehet egy startup ötletet validálni. De ehhez előbb meg kell értenünk, hogy egyáltalán miért is szükséges a validáció.

A bizonytalanság a startup része

Eric Ries, 2011-es The Lean Startup könyvében úgy határozza meg a startup fogalmát, mint egy "intézmény, amelynek célja, hogy egy új terméket vagy szolgáltatást hozzon létre szélsőségesen bizonytalan körülmények között".

Az egyik legfontosabb része ennek a meghatározásnak Ries szerint pont az, ami hiányzik belőle. Semmit nem mond arról, hogy mekkora a vállalkozás vagy milyen iparágban tevékenykedik. Bárki aki bizonytalan körülmények között új, innovatív terméket hoz létre, az egy startup.

Értelemszerűen a meghatározás másik fontos része az, hogy a startup célja egy új termék vagy szolgáltatás, egy innováció létrehozása. Az innovációt érdemes tágan értelmezni. Nem szükséges egy forradalmi újítást hozni, ugyanúgy innováció egy régi technológia újszerű felhasználása, egy új üzleti modell vagy akár egy új módja a vásárlókkal való interakciónak.

Fontos az a kontextus is amiben az innováció történik. Ha nem egy bizonytalan környezetben alkalmazzuk az innovációt, akkor nem beszélhetünk startupról.

Legtöbb vállalkozás pontosan ezért nem tekinthető startupnak. Ha egy olyan vállalkozást indítunk, ami egy tökéletes másolata egy már létező vállalkozásnak, beleértve az üzleti modellt, árazást, célcsoportot és termékkínálatot, az lehet üzletileg jó befektetés, de attól még nem egy startup. Ezeknek a vállalkozásoknak a sikere kizárólag a végrehajtáson múlik. Olyannyira, hogy a sikert és annak mértéket elég magas pontossággal lehet modellezni.

Egy startup esetében a jövő kiszámíthatatlan. Nem tudjuk, hogy mennyire fenntartható az üzleti modellünk, hogy a termékünk tényleg megoldást jelent-e a problémára, vagy hogy egyáltalán mások számára is létező az a probléma amit meg szeretnénk oldani. Egy startup esetén ezeket nem kezelhetjük tényként, legfeljebb feltételezéseink vannak.

Validált tanulás

A bizonytalanság eloszlatására a startup világban bevett módszer a validált tanulás. A validált tanulás egy olyan folyamat amelynek a lényege, hogy empirikusan bebizonyítsuk, hogy közelebb kerültünk a kitűzött céljainkhoz.

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 szakaszban egy olyan minimális terméket vagy kísérletet építünk aminek a segítségével egy vagy több feltételezést tesztelni tudunk.

Az Építs szakaszban fejlesztett kísérletek célja, hogy minél hamarabb be tudjuk mutatni a potenciális felhasználóknak és kapjunk olyan visszacsatolást és információt amit bele tudunk építeni a következő kísérletbe. Ez lesz a Mérj szakaszunk.

Ha a mérés alapján úgy döntünk, hogy közelebb állunk a végső célokhoz, akkor a ciklus elölről kezdődik egy újabb Építs szakasszal, amiben finomhangolunk vagy új kísérleteket fejlesztünk újabb feltételezések tesztelésére.

Egy adott ponton a projektünkből termék lesz, majd átlépünk előbb a növekedési majd az érettségi szakaszba. Jogosan gondolhatnánk, hogy a ciklusnak itt vége, de tulajdonképpen innen is tovább használhatjuk a termék tökéletesítésére vagy az ügyfélélmény növelésére.

Ha a mérés alapján azt látjuk, hogy ez a termékötlet zsákutca, akkor bekövetkezik az ú.n. pivot, vagyis új stratégiát kell kidolgoznunk a célok megvalósításának érdekében.

Ez a döntéshozási pont a ciklusban a Tanulj szakaszunk. Bár a Tanulj szakasz a ciklus végén helyezkedik el, hiszen ilyenkor vonjuk le a következtetéseket, tulajdonképpen az első lépésünk a ciklus elején már az kell legyen, hogy eldöntsük milyen feltételezéseket akarunk tesztelni és mi az amit meg szeretnénk ezekből a tesztekből tanulni.

Feltételezések és validálás a termékfejlesztés különböző szakaszaiban

Mint láttuk, az Építs-Mérj-Tanulj ciklusban folyamatosan újabb és újabb kísérleteket dolgozunk ki, hogy a különböző feltételezéseinket teszteljük. De milyen feltételezéseket érdemes tesztelni a termékfejlesztés különböző szakaszaiban? Erre a kérdésre ad válazt a Lean Validation Cheat Sheet.

Probléma validáció

A termékfejlesztés korai szakaszaiban a probléma validálása a cél. Ilyenkor még általában csak felismertünk egy problémát aminek a megoldására van egy ötletünk, de nem vagyunk biztosak benne, hogy ez a probléma mások számára is kihívást jelent. A fő kérdés amit ilyenkor meg kell válaszoljunk, hogy a felvetett probléma jelentőségteljes és érdemes vele foglalkozni.

A tanulás szakaszban olyan kérdésekre keressük a választ, mint hogy mi a probléma amire megoldást keresünk? Kinek van még ilyen problémája? Ők hogyan próbálják jelenleg megoldani ezt a problémát? Elég fontos ez a probléma számukra, hogy időt és energiát fordítsanak a megoldására?

Probléma validációra az építés szakaszban érdemes meghatározni a célokat, felhasználói perszónákat gyártani és kigondolni a felhasználói élmény térképet (customer journey map), míg a mérések felhasználói interjúk, terepszemle vagy olyan felkutató technikák segítségével történik mint a context mapping.

Probléma-megoldás megfelelés

Ebben a fázisban már tudjuk, hogy a felfedezett probléma mások számára is gondot okoz és szeretnének egy megoldást találni rá, de nem vagyunk benne biztosak, hogy az általunk kitalált megoldás ténylegesen megoldja-e számukra ezt a problémát.

Ebben a fázisban választ keresünk arra, hogy a megoldásunk működik-e és ezt bizonyítani is tudjuk, illetve arra is, hogy ez a megoldás jelent-e akkora mértékű javulást a felhasználóink életében, hogy jelentős legyen számukra? Továbbá választ keresünk arra is, hogy megbíznak-e a felhasználók annyira a megoldásunkban, hogy használják?

Egy jó módszer, hogy ezekre választ kapjunk, az ha készítünk egy value proposition canvas. Ez a canvas segít nekünk abban, hogy a termékünket vagy szolgáltatásunkat a felhasználó igényei és értékrendje köre pozicionáljuk.

Egy másik eszköz amit bevethetünk ebben a fázisban, az a concierge MVP. Ez az MVP-nek az egyik legminimálisabb változata. Annyira minimális, hogy igazából nincs is termékünk, hanem a termék minden funkcióját manuálisan végezzük el. Ez természetesen nem egy fenntartható üzleti modell, de nem is az a cél. Ebben a fázisban kizárólag a fenti kérdésekre szeretnénk választ kapni, még mielőtt elkezdjük az effektív terméket fejleszteni.

Megoldás-termék megfelelés

Ha idáig eljutottunk, akkor már tudjuk, hogy egy validált problémával és megoldással állunk szemben. A kérdés már csak az, hogy tudunk-e olyan terméket fejleszteni amivel ezt a megoldást hatékonyan meg tudjuk valósítani.

A kérdések amire választ keresünk az, hogy a mi termékünk jelentősen jobb megoldást nyújt-e, mint amit eddig csináltak a felhasználóink, illetve hogy használható-e a termék?

Fontos kérdés ugyanakkor az is, hogy a termék használatához, szükséges-e a felhasználók részéről egy viselkedésbeli különbség vagy sem? Gondoljunk csak az Apple iPhone-jára. Az iPhone nem az első okostelefon volt. Előtte már sok másik okostelefon projekt megbukott, mert a felhasználók nem érettek meg még egy ekkora viselkedésbeli változásra. Az Apple felismerte ezt a helyzetet, viszont magabiztosak lehettek az iPhone bevezetésében, hiszen az iPod korábbi sikerével megalapoztak ennek a viselkedésbeli változásnak.

Ebben a fázisban már érdemes tapintható, érzékelhető prototípusokat fejleszteni: papír prototípust, kattintható demó szoftvereket vagy akár egy Oz Varázsló típusú MVP-t. Ez a típusú MVP a concierge MVP egy továbbfejlesztett verziója. Itt már a termék azt az érzést kell kiváltsa a felhasználóban, hogy minden funkcionalitás teljesen automatizált benne, de a háttérfolyamatokat továbbra is manuálisan végezzük.

A méréseket is már a kézzelfogható terméken végezzük, használhatósági-, felhasználói élmény- (UX), alfa- és béta tesztek segítségével.

Termék-piac megfelelés

Ez lesz a termékfejlesztés utolsó szakasza. Itt már tudjuk, hogy a termékünk hatékonyan megvalósítja a felvetett problémára a megoldást, azonban még mindig nem tudjuk azt, hogy a felhasználókat át tudjuk-e konvertálni vásárlókká.

Hajlandóak a felhasználók fizetni is a termékekért vagy szolgáltatásért? Hány ilyen vásárlónk lenne és mennyit fizetnének? Hány százalékban lesznek visszatérő vásárlóink?

Az Építs lépésben immár nem prototípusokat és terméket építünk, hanem marketing kampányokat: termékbemutató videókat, landing oldalakat, hírleveleket. Mérni itt a kampányok sikerességét érdemes analitikai adatok alapján, A/B tesztek eredményei alapján vagy akár már az elővásárlási eredmények alapján.

Bármelyik szakaszban vagyunk, a végén mindig el kell döntenünk a megszerzett tudás és a mérések alapján, hogy kitartunk mert jó irányban történnek a fejlesztéseink, vagy egy pivotra kerül sor. Ha a termékfejlesztési folyamat végére érünk, ismételjük meg a lépéseket a termék továbbfejlesztésére vagy akár egy új funkcióra is.

A validált tanulás alapú termékfejlesztési módszer szépsége, hogy nem csak startup projektek esetén megvalósítható, hanem bármilyen, akár nagyvállalati- vagy ipari környezetben is.