Lefülelt Lean?

lean_criminalMinden újdonság ciki lesz idővel. Úgy látszik, lecsengőben van a Steve Blank és Eric Ries-féle Lean Metodológia mindenhatóságába vetett hit is a Bay Area-ban, kezdik felütni fejüket az első kritikák. A hivatkozott cikkben Michael Sharkey, a Bislr Co-foundere-fejti ki álláspontját erről az egész lean-őrületről, már a bevezetőben behányással fenyegetve a Lean-hívőket. Legyünk Úriemberek, és nézzük meg, igaza van-e? Az eredeti cikk címei szerint haladok, kiemelve a legerőteljesebb állításokat – de előtte még egy gyors köszönet Dámosy Bálint-nak a forrásért.

A Lean modell feature-öket szorgalmaz termékek helyett

Állítás: A Szilícium Völgyben az új divat építeni egy egyszerű feature-t, ami igazából csak néhány potenciális felvásárlót érdekel. Ez egy borzasztó járvány, pedig a felhasználóknak termékek kellenek, nem sima feature-ök.

Vélemény: Ez konkrétan marhaság. A Lean metodika egy startup nagyon korai fázisában javasolja azt, hogy egy termék validáció nélküli kifejlesztése helyett meg kell találni egyetlen core feature-t, amire a termék majd épül. Senki nem mondta, hogy egyetlen feature-re kell épülni a világ végéig. Steve Blank és Eric Ries csak azt hangsúlyozza, hogy így kell elindulni. Ez részben a validálhatóságot, részben a koncepció letisztítását, részben a kockázatok csökkentését szolgálja. A cikk példának hozza a Twitter által felvásárolt egyfunkciós Summify-t, vagy a Groupon által felvásárolt Mertado-t; egyenesen járványnak titulálva a gyors exitre építő egyfunkciós startupokat. Hát Istenem, azzal vonuljak be a Világ Legaljasabb Genyóinak Évkönyvébe, hogy eladok pár millió dollárért egy startupot egy iparági mammutnak, gazdaggá téve ezzel a családom mellett 10-15 kollégát. Mióta járvány egy gyors exit szerete? Lehet, hogy én vagyok öreg, de ha az, akkor a francba a védőoltással… És ha a user-eknek ezek az egy-funkciós vackok nem kellenek, akkor miért használják ezeket a szoftvereket millió-számra? Brr… Nem úgy tűnik, hogy a szerző logika-fertőzésben fog meghalni.

Korán kiégő csapat

Állítás: A kényszeres Lean-féle tesztelgetés elveszi a drága időt a termékfejlesztéstől; a tesztelés 70 %-ának különben sincs mérhető hozama.

Vélemény: Részben igaz. De van itt egy súlyos félreértés. Mit kell a Lean szerint tesztelni? Minden kockázati pontot – de nem azonos energia-ráfordítással! Aki a termékfejlesztésen dolgozók idejének nagy részét tesztelésre fordítja, az valóban rossz úton jár. De a fontosabb feltételezéseket tesztelni kell, mert nem mindegy, hogy kik például a sokat emlegetett early adopter-ek, vagy hogy milyen piaci szegmens reagál a legütősebben a megoldásunkra. A/B tesztelni az utolsó betűtípust is – na az már a ló másik oldala. Az Amazonnak talán megéri, de egy 5-10 fős startupnál gyógyszeresen kezelendő kényszerességre utal. Különben is, a tesztelés nagy részét az üzleti oldalnak kell csinálnia, amikor egy szál iPad-ben kimennek a térre célcsoportot nyektetni, vagy on-line koldulnak visszajelzést. A tesztelés nem elsősorban technológiai tesztelést jelent!

Nehezen szerethető termékek

Állítás: A Lean termékek definíció szerint felületesek, ezért nehéz szeretni őket. Ahogy megveszik ezeket a cégeket, be is zárják a boltot, a felhasználók meg hoppon maradnak.

Vélemény: Össze tetszik keverni egy Lean startup legkorábbi fázisát a későbbiekkel. Igen, egy korai validációs fázisban a termékek felületesek, mert – és most ugrik a befektető a vízbe – még nem termékek. Az MVP nevével ellentétben nem mindig termék, de nem is az a célja, hogy milliók igényét elégítse ki magas minőségben, hanem az, hogy milliók igényét tesztelje magas minőségben – hogy majd ezt követően milliók igényeit tudja kielégíteni magas minőségben. És hogy nehezen szerethetőek? Az early adopterek konkrétan vallásos áhítattal imádják ezeket a nem-termékeket, mert húsbavágó gondjukat oldja meg. Egy startup nem a Ghandi-család, akik úgy születnek, hogy egymilliárd ember szereti őket. Majd idővel, sok munka és verejték árán…

Leértékeli az architektúra jelentőségét

Állítás: Egy MVP során a csapat nem fókuszál hosszú távú architektúrákra, márpedig ez később keményen visszaüt.

Vélemény: Igaz. Csak épp semmi köze a Lean felfogáshoz. Valóban ismert a termékfejlesztés Lean-szerű beturbózásának azon árnyoldala, amit úgy hívunk: technical debt (technikai “hitel”). Ez nem más, mint egy tisztességes és robusztus, hosszú távon is megfelelő megoldás helyett egy gyorsabb, egyszerűbb, a jelenlegi célnak még megfelelő, de hosszabb távon kifejezetten hebehurgya és alkalmatlan megoldás alkalmazása. A „hitelt” azután később kell költséges és időigényes change management-el orvosolni. A technical debt szar dolog – sőt, a hitel általában elég szar dolog. Azonban amikor egy korai fázisú startup hipotéziseket tesztel, akkor teljesen felesleges atombunkerek időtállóságát meghazudtoló technológiákba invesztálni. Ha lenne is rá zsé, akkor is költsd inkább marketingre. A technical debt-et sajnos néha fel kell venni, és sajnos mindig vissza kell fizetni. Ez van: Az élet szar, ráadásul a végén meghalunk.

Rossz párbeszédhez vezet a befektetőkkel

Állítás: Ha Lean-t használsz, akkor korai exit-re hajtasz. Ha korai exit-re hajtasz, becsapod a befektetőidet. Ha becsapod a befektetőidet, becsapod az alkalmazottaidat is.

Vélemény: Ha van akváriumod, szereted a halakat. Ha szereted a halakat, szereted a halászlevet. Ha szereted a halászlevet, akkor szereted a jó borokat is. Ha szereted a jó borokat, akkor nyilván szereted a jó nőket is. Tehát ha nincs akváriumod, akkor csatak-buzi vagy… No comment.

Eltorzítja a Szilícium Völgy alkalmazott-keresési modelljét

Állítás: A 17 éves Nick D’Aloisio (Cégét, a Summly-t 30 millió dodóért vette meg a Yahoo) sokkal nagyobb hasznára lett volna a közösségnek, ha még szenved egy kicsit mikrovállalkozóként. Akármilyen okos és ügyes, nem érdemelt volna 17 évesen 30 millát dollárban, annyira nem lehet jó (különben is, a frontális lebenye sem fejlődött még ki).

Vélemény: Köcsög Nick! Az én gyerekem próbálna csak 30 millió dollárért exitelni 17 évesen, hát hazáig rugdosnám a büdös kölök fejletlen frontális lebenyét! (Ahelyett, hogy nyugton lenne és csak szépen csendben drogozna, mint a többi gyerek…) De most komolyan: Nem, nincs baj a korai exit-ekkel. Különösen, mert elég ritkák. Persze, a hírekben minden héten olvasunk egy Nick-ről, ami egy évben 52 mázlistát jelent. Csakhogy egyedül a Bay Areában sok tízezer startup botladozik, fejlődik, becsődöl, vagy épp hírnevet szerez, halad, kitör – nem kellene irigyelni egyetlen kis zsenitől a gyors exitet. Ha eljutsz oda, hogy megvesz a Yahoo 30 málnáért – hát tök mindegy, hogyan csináltad és hány éves vagy éppen. A vállalkozósdi a végén csak a zsozsóról szól. Persze, cool-ok vagyunk, világmegváltunk, álmodunk, szitává ötleteljük az agyunkat – de azért a Yahoo 30 millája az egy olyan valós gazdasági teljesítmény, amit nem kell tovább magyarázni. Keresett 30 millió dollárt 17 évesen – hadd ne érezze már magát egy szánalmas pondrónak, basszus!

[dil dil = 3802]

Összegzés

A Lean nem arra való – ahogy egyetlen más módszertan sem -, hogy félelemmel vegyes áhítattal  imádkozzunk hozzá. Ismerni kell, és alkalmazni olyan mértékig, ahogyan azt az adott helyzetben célszerű. Egy jó vállalkozó különben is sokszor szembe megy a megszokottal, a trendekkel, az általánosan elfogadott vagy épp hype-olt dolgokkal. Azonban ahogy a zsenit és az őrültet is csak egy hajszál választja el, úgy a rock sztár vállalkozó és az állandóan okvetetlenkedő, rendszeresen konfrontálódó élhetetlen gyökér sincsenek messze egymástól. Valahogy úgy van ez, hogy bekötött szemmel, hátrakötött kezekkel elkezdesz futni egy erdőben. Ha lefejeled az egyik százéves tölgyet, akkor szánalmas idióta vagy, ha pedig elsőnek érsz ki az erdőből, akkor egy oroszlánszívű atléta. A megítélésünk végül csak a sikerünk függvénye lesz, semmi másé. A történelmet a győztesek írják. Soha senki nem fogja megveregetni a vállunkat, hogy „Semmi baj, 20 évig próbálkoztál keményen, egy kanyid sincs – de azért szép volt”. Amikor elindulsz az úton, először semmibe vesznek, aztán kinevetnek, majd irigykednek, aztán elgáncsolnak, majd  megpróbálnak eltaposni – és ha egyik sem ment, akkor végül elkezdenek tisztelni. A Lean nem egy ösvény, amin mindezen dolgok majd jól nem fognak megtörténni veled, amin az ég kék, a nap sütni fog és már a startnál látszik a csak neked drukkoló és nagyokat kacsintó exit. Nem. A Lean a túlélő-késed, amivel egy kicsit több esélyed van rá, hogy ne az legyen a kaland vége, hogy pár év után legyatyásodva csukod be a boltot; és közben a szíved szakad meg…

Hogyan validáld a termékedet?

termek-validacioAz egyik nap elővettem a korábbi Startupdate cikkeket és egy startup életét, életútját lekövetve sorba rendeztem őket. Gyakorlatilag létrejött egy olvasónapló, ami időrendben vezet végig az ötlet megszületésétől, a csapat-összeállításon, termékfejlesztésen és a befektetőkeresésen át egészen az exitig. Bár a következő sorok nem erről fognak szólni, de részben ezen összegzés segítségével jutottam el egy olyan pain-pointhoz, amire szerintem egyelőre kevés válasz született a blog hasábjain keresztül. A cím alapján nem nehéz kitalálni miről lesz szó: Hogyan validáljuk a termékünket? Összeszedtem egy GYIK formájában:

A kérdések

“Nah, van ez a nagyon király ötletünk, kb kész is a termék, most az a kérdés: hogyan validjáljuk?”

Válasz: Rég rossz, ha akkor kezdesz validálni, amikor már kész a termék.

Tanács: Vissza az iskolapadba, olvasgasd Eric Ries és Steve Blank írásait vagy kapd elő mondjuk Ash Maurya Running Lean című könyvét. Ha olvasás helyett inkább videókat néznél, akkor pedig ezt a Lean Startup Udemy kurzust ajánlom. A szakma legnagyobbjai, egy email címért cserébe. Szerintem megéri belenézni.

“A termékünket alapból az amerikai piacra szánjuk, de hát mi Pesten vagyunk. Hogyan teszteljük az USA piacára szánt terméket a magyar piacon?”

Válasz: Sehogy.

Tanács: De tényleg. Lean Startup szempontból a kérdés értelmezhetetlen. Ha olyan terméket akarunk csinálni, aminek az early adopterei New Yorkban vannak, akkor bizony ott kell tesztelni és validálni. És nem Budapesten. Oda kell menni, ahol a célpiac van. A piac meghátározásával kapcsolatos cikk végén kommentben ezt ki is emeltem külön. A Servicable Obtainable Market-en (SOM) aka Target Market-en belül valóban fontos meghatározni az early adoptereket, a validálás szempontjából ez azonban még nem elég. Ezt a réteget ugyanis “geotag-gel” is el kell látni. Ha úgy gondolod, hogy a budapesti 30-40 közötti anyuka ugyanolyan, mint az amerikai, akkor valószínűleg tévedsz. De még akkor is, ha a 18-25 éveseket hasonlítod össze. Oda kell menni, ahol a célpiac van, és ott kell tesztelni. Nem véletlenül “zavarta el” Paul Graham is az Airbnb-t annak idején SV-ből NY-ba. Aki nem ismeri a sztorit, annak kissé zanzásítva valahogy így néz(het)ett ki:

Paul Graham: Ti mit kerestek itt Californiában?

Airbnb alapítók: Hát, jöttünk a Y Combinator-be.

Paul Graham: OK, de mit kerestek itt?

Airbnb alapítók: Hát, izé, jöttünk a…

Paul Graham: Tudom, tudom. De hol vannak a felhasználóitok, az early adopterek?

Airbnb alapítók: Hát, NY-ban.

Paul Graham: OK, akkor mit kerestek még mindig itt?

A többi már történelem. A srácok vették a cókmókjukat és elementek NY-ba. Vagyis nem elég az early adoptereket azonosítani. Azt is tudni kell, hogy ők hol vannak. Bár Budapest tényleg nagyon sokszínű, kezdeti tesztelésre valóban alkalmas, de ha nem ez a célpiaca a termékednek, akkor nagy valószínűséggel nem fogod tudni itt validálni. Így leírva nagyon triviálisnak és plasztikusnak tűnik a dolog, mégis nagyon sokan tesztelnek valami olyat Pesten, aminek nem itt van a célpiaca. Ez pedig hiba. Óriási hiba.

“OK, ok. De, olyan sokba kerül egy repülőjegy, a szállás meg a kaja. Ennyi pénzem nincs. Hogyan menjek így az USA-ba tesztelni?”

Válasz #1: Sehogy. Miért kéne mindenáron odamenni?

Tanács: Be Lean. Csinálj Skype interjúkat vagy szerezz egy advocat-et, aki segít tesztelni a célpiacon. A végén még lehet, hogy ő lesz az egyik co-founder vagy csapattag. Nyilván időigényes, de ez van. Valamit valamiért. Legalább nem költöd rá a gatyádat, a biciklidet meg a diákhiteledet. Jó példa erre a Buffer esete. Miután lejárt a srácok 3 hónapos turistavízuma, nem volt mint tenni, menni kellett az USA-ból. Ideiglenesen elhagyták a Bay Area-t, és átköltöztek Hong Kongba és onnan folytatták online az USA-ban lévő early adopter-eikkel az interjúkat. Skype-on keresztül.

Válasz #2: Be smart. Be cheap.

Tanács: Ha mindenképp ki akarsz menni, vagy csak azért mert New York azért mégiscsak New York, meg hát nem volna rossz a Central Parkban krúzolni két customer interview között. Álmodozni jó dolog, valóra váltani őket meg még jobb.

Szóval, hogy lehet kijutni tesztelni? Be smart, be cheap.

  1. Spórold össze a pénzt rá! (Thank you Captain Obvious!) De tényleg. Ha eléggé hiszel a projektben, akkor lehet rá megoldást találni. Ha valóban ez életed projektje, akkor hajrá. Ha nincs meg a 100% commitment, akkor felesleges is tovább erőlködni.
  2. Finanszíroztasd meg a potenciális userekkel. “Ha adsz 10 dollárt, elkészül a termék, akkor 1 évig ingyen használhatod a cuccot.” Vagy bármi ehhez hasonló. Nem könnyű móka, de hátha bejön. Gyakorlatilag crowdfounding jelleggel is neki lehet tehát futni a dolognak.
  3. Szerintem ez a legmenőbb: Csinálj egy validációs kört Pesten, elnézhetsz a környékbeli országokba is akár, vagy csinálj Skype interjúkat, a lényeg, hogy legyen valamiféle traction-öd. Majd menj el egy befektetőhöz és mondd el neki, hogy a cucc skálázásához ezt bizony a célpiacon kell tesztelni. Egyszerre tudod megmutatni ezzel, hogy képben vagy a piac-meghatározással, meg a Lean-nel. Emellett azt is meg tudod mutatni, hogy neked bizony nem sales teamre, meg marketingre kell a pénz, hanem tényleg valami egyedire. Ha tudsz valami olyat mutatni egy befektetőnek, amit még senkitől nem látott a piacon, akkor egyből felfigyel rád. Az ilyen emberekre pedig nagyon gyorsan lecsapnak a befektetők, mert tudják, hogyha elengednek, akkor más fog lecsapni rád.

 

“OK, megvan a Problem-Solution Fit. Tudjuk mit akarnak a felhasználók, nyomjuk a fejlesztést ezerrel, lassan elérünk a Product-Market Fit-hez. Honnan tudom eldönteni, hogy a felhasználó egyébként hajlandó lenne fizetni is a termékért, és nem csak bemondásra megy a dolog?”

Válasz: Tesztelni kell. Hackeld meg a felhasználóidat.

Tanács: Add oda a terméket a user-nek mondjuk 2 hétre, használja ingyen és bérmentve. Majd 2 hét múlva “vedd el tőle” és nézd a szemét (vagy akár a metakommunikációját), hogy mit reagál. Ha nem akarja “visszaadni”, akkor jó úton haladsz, hogy fizessen érte. Fizikai terméknél ez persze sokkal szembetűnőbb a reakció, de szoftvereknél sincs gond a teszteléssel. Gyakorlatilag a 14-30 napos trial verziók is ugyanezt a célt szolgálják. Használod, majd “elveszik tőled”, és abban a pillanatban kiderül, hogy mennyire kellett a cumó neked. Nagyon más az, amikor bemondásra kell fizetni egy termékért, vagy amikor már ténylegesen a bankkártyát kell előkapni. Ne hagyjátok, hogy a userek megtévesszenek Titeket ezen a ponton. Ígérni bármit lehet, “lockolni” kell a usert. A pénzével szavaz. Vagy rád, vagy másra.

“OK, most már tudjuk, hogy vannak, akik fizetnének is a termékért. Honnan tudom, hogy elértem a Product-Market Fit-et?”

Válasz: Nagyon jó kérdés. Talán ezt a legnehezebb megítélni. De nincs minden veszve. Hüvelykujj-szabályként használd, mondjuk a Sean Ellis tesztet.

Tanács: A PM Fit az egyik legnehezebben megfogható dolog az egész Lean startupban szerintem. Nehéz eldönteni, hogy a terméked valóban “must-have”, amiért tényleg taposni fogják egymást az emberek, mint az akciós sajtért a Penny Marketben (itt egy remek videó is), vagy csak “nice-to-have”. Gyakran használják egyébként a painkiller vs vitamin hasonlatot is. Akkor van meg a PM Fit, hogyha a terméked “fájdalomcsillapító”. Azért ugyanis hajlandóak vagyunk fizetni, hogy fájdalmunkat azonnal, gyorsan és hatékonyan csökkentse valami (= megold egy problémát, vagyis must-have), míg a vitamin csak egy hasznos kiegészítő, ami nélkül azért meg tudunk lenni. Aki szereti a számokat, annak itt egy hüvelykujj-szabály szintű metrika:

A Sean Ellis teszt

Kérdezd meg a felhasználókat, hogy mennyire lennének csalódottak, hogyha a terméked a holnapi naptól kezdve megszűnne:

  1. Nagyon csalódott.
  2. Csalódott.
  3. Kicsit csalódott.
  4. Nem érdekelné különösebben.

A beérkezett válaszok megoszlásánál arra kell törekedni, hogy az első kategóriába eső válaszok száma meghaladja a 40%-ot. Ha ez összejön, akkor elérted a PM Fit-et. A többi nem érdekes. Sok helyen elkövetik azt a hibát, hogy az első 2 kategóriát összeadják, és azt látják, hogy az emberek 90%-a egyszerűen csak imádja a terméküket. Francokat. Lehet, hogy szeretik, de fizetni csak azok fognak érte, akik az első kategóriába tartoznak. Akik “csak” csalódnak, ők keresni fognak egy másik alternatívát, a fizetési hajlandóságuk meg egyébként is sokkal alacsonyabb az első kategóriához képest. Ezt a módszert hívják “Sean Ellis tesztnek”, a 40%-os arányt pedig több száz startupot elemezve határozták meg.  Aki esetleg nem ismerné Sean Ellist: a LogMeIn budapesti irodájában dolgozott vezető marketingesként gyakorlatilag az indulástól egészen az IPO-ig, dolgozott a Dropbox-nál, számos neves startupnál, a legújabb saját startupja a Qualaroo. Az egyik legelismertebb startup marketing guru, a Growth Hacker kifejezés egyik ötletgazdája.

=SUM(above)

Teszt, teszt, teszt. Sok-sok hipotézis, validáció és iteráció. Gyakorlatilag az itt felsorolt kérdések mind a lean startup filozófiából építkeznek. Logikus, egymásra épülő elemek, amelyek mind megpróbálják csökkenteni a felesleget és csak az értékteremtő tényezőkre fókusználnak.

Az ellenzék hangja

Ennek ellenére sok kritika éri a Lean-t. A Lean nem csupán egy módszertan hanem egy gondolkodásmód. Két rövid példa, anekdota, amiket szerintem jellemzően félreértelmeznek az emberek.

“Minek ez a nagy felhajtás a Lean körül? Ha Ford megkérdezte volna az embereket, hogy mit akarnak, akkor azt mondták volna, hogy gyorsabb lovakat.”

Válasz: Rossz a kérdésfeltevés. Ezzel kapcsolatban érdemes elolvasni  Orsi Jó kérdés, rossz kérdés cikkét. A lényeg nem az, hogy gyorsabb lovakat akartak, hanem az, hogy gyorsabban akartak eljutni egyik helyről a másikra, egyszerűen csak nem tudtak out of the box gondolkodni. Vagyis jó kérdésfeltevéssel, vagy sokkal inkább a valódi probléma felismerésével máris közelebb kerülünk a Lean alapelveihez, és nem utasítjuk el élből azt.

“OK, de Jobs se kérdezte meg a felhasználókat, mit akarnak. Piacot teremtett. Ezért én se kérdezem meg. Minek? Jobs se tette.”

Válasz: Két helyen hibás az érvelés.

  1. No offense, de valószínű nem vagy Steve Jobs. Mint ahogy én sem. Meg ahogy másik 7 milliárd ember sem. Egy kezünkön meg tudjuk számolni hogy hány Jobs kvalitású embert ismerünk. Vagy akar egy ujj is elég. Ne az outliereket tanulmányozzuk. Főleg ne akkor, hogyha 7000000000:1 az arány. Könnyű 1 embert felhozni példaként, aki másként csinálta, de mellette meg ott van sok száz, ezer, néha tízezer példa, akik viszont igazolják a módszertan életképességét. Nem azt mondom, hogy ne álmodjunk nagyokat, és ne merjünk kitűnni a tömegből. Egyszerűen csak azt, hogy ne outlierekkel és évszázados zsenik példáján keresztül legitimáljuk ostobaságunkat.
  2. Szerintem Jobs volt az egyik legnagyobb Lean guru, aki élt széles e földön, csak épp magát nem így hívta. Problémákat oldott meg, olyat ami sok embernek viszketett. Egyszerű, de mégis kifinomult telefont, pofonegyszerű zeneletöltést, vizuálisan megnyerő PC-t (amit azóta persze másként hívnak) hozott létre. Tudta, hogy az emberek utálnak operációs rendszert és szoftvereket telepíteni és nagyon idegesíti őket, hogy használat előtt ki kell sütni az aksit, ezért előre telepített gépeket és termékeket gyártott, amiket out of the box lehet használni. Nem mellesleg az Apple esetében is volt rengeteg félresikerült termék, és maga Jobs is több bukáson keresztül iterálva jutott el a manapság már ikonként tisztelt termékekhez.

Tudom, hogy ő maga mondta, hogy nem érdekelte az emberek véleménye és csak a saját feje után ment. A fejlesztési folyamatot lehet, hogy szigorúan és rigorózusan véve nem a Lean szerint végezte, DE sok embert érintő problémákat oldott meg, méghozzá olyanokat, amelyekre addig jellemzően nem létezett megoldás. A Lean startup pedig pont erről szól.