SME Consultancy
[ Segítünk a növekedésben ]
(Olvasási idő 20-25p, ha odafigyelsz - megéri)
Ezt a posztot azért fordítottuk le és tesszük közzé (a Hotjar engedélyével), mert általa igazolni látjuk a Lean Startup módszerek, a LeanStack és a Strategyzer keretrendszerek létjogosultságát.
A Hotjar az egyik piacvezető webanalitikai és elemző megoldás, melyet nemzetközi és magyar SEO-sok és online marketingesek is ajánlanak.
Belefogtak egy app-fejlesztési projektbe. Manapság ugye minden startup appot fejleszt, ha kell - ha nem. A Hotjar a 200.000 dolláros (igen, kb. 60MFt) kudarcát nem söpörte a szőnyeg alá, 1-2 könnyet elmorzsolva, hanem mindenki okulására közzétette, ingyen.
Mert igenis fontos a modellezés, a validáció, a felhasználói interjú, az MVP, a Build-Measure-Learn iterációk, majd a scaling, azaz minden, amit a Lean Startup ad - és amit mi is javaslunk saját ügyfeleink számára a mikrovállalkozástól a nemzetközi multiig.
Nézzük a kétszázezer dolláros jótanácsot, ingyen!
2018. Nov. 8., írta: Stefan Cerri, fordította: Houdek Zoltán
Ha próbáltál már valamit sikerre vinni, végigkísérve a teljes életútját, csak azért, hogy aztán végignézhesd, amint kudarcba fullad az egész, akkor ez a cikk neked szól.
Nemrég megszűntettük a mobil applikációnkat.
Elég fájdalmas dolog volt. Végülis 3500 fejlesztői munkaórát és kétszázezer dollárt fektettünk bele.
Azonban kulcsfontosságú területeken hibáztunk, így a projekt már a kezdetektől kudarcra volt ítélve.
A mai posztban azt osztom meg veletek, hogy melyek voltak ezek a hibák, és mi volt az a hat dolog, amit ma már másként csinálnánk. Összesen tíz leckéről van szó.
Az ötletünket azért nem sikerült megvalósítani, mert nem a megfelelő dolgokra kocentráltunk.
A Hotjar-t 2014-ben indítottuk el. A felhasználók imádták a hőtérképeket (heatmap), a felvételeket, a konverziós tölcséreket és az űrlapokat, melyek segítségével betekintést nyerhettek honlapjaik és webapp-jaik valódi működésébe.
Hamar eljött az idő, amikor a felhasználók azt kérték, hogy hasonló megoldások álljanak rendelkezésre a mobil applikációkhoz is.
Namost. Ahhoz, hogy a Hotjar működjön a mobilappokon, egy SDK-t kellett lefejlesztenünk. Hasonlóan ahhoz, hogy a honlapon történő eseményekhez a Hotjar scriptet be kell ágyazni a honlapba, ugyanúgy a mobilapp megfigyeléséhez a Hotjar SDK-t kell használni.
Mi volt a probléma? A honlapfejlesztés és az appfejlesztés két teljesen más unvierzum. Egyik termékfejlesztőnk sem fejlesztett SDK-t azelőtt. Sőt! Egyikük sem fejlesztett soha mobilappot.
Az ötlet tehát az volt, hogy fejest ugrunk a mobilapp-fejlesztésbe, s megírjuk a Hotjar-t mobilra. Amikor ezáltal kellő ismeretet szereztünk az appfejlesztés terén, jöhet az SDK, melyet a felhasználóink kértek.
Két fejlesztőt állítottunk a feladatra, és úgy saccoltuk, hogy legfeljebb pár hét alatt meg is lesznek.
Ekkor még nem is tudtuk, hogy máris elkövettük az első hibát...
A Hotjar felhasználói SDK-t kértek, nem mobilappot.
Tény, hogy senki sem akart Hotjar mobilappot. Nulla ilyen kérés volt a Receptive-en (az ügyfeleink igényeit rendszerező alkalmazásban), nulla kérés az app-áruházakban, nulla igény a vevői visszajelzések között.
Semmi.
Emellett annyit sem tettük meg, hogy akár egy másodpercre is megálljunk és megkérdezzük a felhasználóinkat: "Ha lenne mobilappunk, mire szeretnéd haszálni?"
Ha megkérdeztük volna, talán rájöhettünk volna, hogy a felhasználók leginkább a felvételeket [a honlapon történő mozgások felvételeit - a ford.] akarták volna megnézni. Igen ám, de az a megoldás, ami ezt a webes változatnál lehetővé teszi, nem működik natív mobilalkalmazásban. Így hát ezt a funkciót elhagytuk a mobilappból, és a többire koncentráltunk.
Igen, azt az egyetlen dolgot nem oldottuk meg, amit a felhasználók örömmel fogadtak volna.
Nem meglepő tehát, hogy az app 2017 novemberi bemutatásakor a fogadtatás igencsak langyos volt, és alig volt visszatérő felhasználónk. A legtöbb panasz amiatt érkezett, hogy az említett felvételeket nem lehet megnézni.
De nem ez volt az egyedüli hibánk...
Nem elég, hogy a felvételekkel kapcsolatos funkciónál teljesen mellélőttünk, de a mobilapp-fejlesztés bonyolultságát is alulbecsültük, és nem gondoltunk bele, hogy mibe kerül egy ilyennek a fenntartása és a support-ja.
Ahogy már említettem, egyikünk sem rendelkezett app-fejlesztési tapasztalattal. Ennek tetejébe az ügyfélszolgálaton sem volt megfelelő emberünk erre a területre. Ugyanis ők szembesülnek először a teljesen újfajta panaszokkal és igényekkel, és tapasztalat és/vagy oktatás nélkül kell kezelniük a helyzetet.
A problémák innentől csak halmozódtak.
Milyen speciális biztonsági megoldások szükségesek mobilon? Hogyan kezeljük mindezt GDPR-oldalról?
Egy teljes csapatra lett volna szükségünk az app üzemeltetéséhez. Kijelölt termékmenedzserrel, fejlesztőcsapattal, support-tal, plusz a marketingesekkel, akik elterjesztik a terméket.
A fentiek közül semmi sem volt előre megtervezve.
A mobilapp fejlesztése közben csatlakoztam a Hotjar-hoz, mint termékmenedzser. Fontos: előttem a Hotjar-nál egyáltalán nem volt termékmenedzser.
Bár az SDK előtti lépcsőként az app fejlesztése jó ötletnek tűnt, senki sem volt a csapatnál, aki az ellenoldalt képviselve feltette volna a kérdést: valóban ez a legfontosabb dolog, amivel foglalkoznunk kell?
Mint kiderült, ez a dolog nem a mobilapp lett volna ugyanis, és még csak nem is az SDK.
Lettek volna fejlesztési területek a meglévő rendszerben is, mint például a heatmap-ek hibajavítása, vagy új célzási (targeting) szabályok beépítése, melyeket sok felhasználó régóta kért. Szemben a hangos kisebbséggel, akik az SDK-t követelték.
A GDPR is már ott leselkedett ránk, és a GDPR-megfelelőség egyszeriben a termék és a fejlesztőcsapat központi problémájává vált.
Egyszerűen nem gondoltuk végig a dolgokat, ami pedig elvezet a következő hibához, melyet elkövettünk:
Amikor két fejlesztőt ráállítottunk a projektre, született egy scope dokumentum, amit jóvá is lett hagyva.
A felhasználóktól érkező bármilyen (lásd az #1 hibát) visszajelzés nélkül úgy döntöttünk, hogy a Hotjar összes funkcióját, kivéve a felvételeket, beletesszük az appba.
És azt gondoltuk, hogy erre elég pár hét. Maximum.
Amikor ebből pár hónap lett, senkinek sem jutott eszébe feltenni a kérdést, hogy mi lenne az a minimális funkcionalitás, amivel megjelentethetnénk az appot, és a felhasználók kezébe adhatnánk, máris?
És ismét megjegyzem, a fő cél az SDK volt, a mobilappot csak egy köztes lépcsőfoknak szántuk.
Megkérdezhettük volna magunktól: "Mi az a legkisebb életképes termék (MVP), amelynek lefejlesztése során már eleget tanulunk ahhoz, hogy továbbléphessünk az SDK-hoz?"
Annyira elszántak voltunk az app mellett, hogy fel sem merült a scope csökkentése, egyes dolgok kihúzása.
Mindez persze annak volt a velejárója, hogy korai fázisban lévő startup voltunk, amely igyekszik lépést tartani saját gyors növekedésével (őszintén szólva nem rossz, ha ez a problémád!). A projekten dolgozó két fejlesztő egyike a mérnöki csapat igazgatója, egyben társalapító, Marc Von Brockdorff volt, aki valójában egy egyemberes fejlesztőcsapat, és több kezdeményezés egyidejű irányítója.
Ekkor kb. 2017 novemberét írtuk, és az app majdnem kész volt. Így az éles indulás mellett döntöttük - látni akartuk, mi fog történni.
Amikor 2017 novemberében élesben elindult az app, semmilyen hatása nem volt. Kiküldtünk egy hírlevelet ezer embernek, akik korábban érdeklődtek a Beta-verzió iránt (ismétlem: miután elkezdtük a fejlesztést).
Képzelheted: bejelentkeztek, egy napig próbálgatták, és soha sem tértek vissza.
2018 márciusában kb. 100 aktív felhasználónk volt. Nagyobb és egyértelműbb céljaink voltak már, a mobilapp pedig olyan teherré vált, melyet nem akartunk tovább cipelni.
Áprilisban levettük a store-okból, és megszűntettük a regisztrációt.
Májusban a megmaradt aktív felhasználók számára további 30 nap határidőt adtunk, és megmondtuk nekik, hogy amit ez letelik, vége az appnak.
Júniusra töröltük.
Mindez azonban nem volt hiábavaló.
Az applikációnk "porig égett". Ha már kezdettől a megfelelő kérdéseket tettük volna fel, és az ügyfeleinket már a fejlesztés korai fázisában bevontuk volna a tesztelésbe, mindvégig meghallgatva visszajelzéseiket, a dolgok valószínűleg másként alakulnak.
Ehelyett élesben elindultunk, hogy "lássuk mi történik".
A történet azonban nagyon fontos tanulságokkal szolgált. Ha újrakezdenénk az egészet, azt a következő módon tennénk.
Ha odajössz hozzám, hogy "Hé, Stefan, építsünk egy űrhajót!", akkor azt mondanám: "Figyelj, nem vagyok benne biztos, hogy ezt kell tennünk. De kérdezzük meg az ügyfeleket, hogy ezt akarják-e."
Kutatásokat végeznénk, és a vásárlói visszajelzések összes előfordulási helyén szétnéznénk: a felvett hibajegyek között, a bejövő visszajelzések között, felmérések és űrlapok erednényeiben.
Megnéznénk, milyen gyakran fordul elő ez az űrhajó-dolog. Ez megadná az ötlet mennyiségi igazolását. [Quantitative validation eredetiben és a Lean Startupban - a ford.] Ha egyáltalán elő sem fordul, már itt elfelejtenénk az egészet.
Legtöbbször valami ilyesmivel kell kezdeni. Amikor egy felhasználó valamilyen igénnyel jelentkezik, azt a kérést eggyel előbbre soroljuk (upvote) a Receptive-ben.
Nagyon egyszerű megnézni, mely kérések a népszerűek: amelyek a legtöbb upvote-tal rendelkeznek. Ha ez a szám eléri a négyszázat, érdemes foglalkozni a dologgal.
Ha elég sokan kérik az űrhajót, jöhet a következő lépés.
Ezen a ponton űrlapot küldünk ki, hogy minőségi igazoláshoz [qualitative validation itt is és a Lean Startupban is - a ford.] jussunk.
Megkérdeznénk tőlük: "Figyi, lehet, hogy építünk egy űrhajót. Egy 1-7-es skálán mennyire értékelnéd ennek a fontosságát a saját szemszögedből?"
A felhasználók elég gyakran gondolják úgy, hogy szeretnének egy űrhajót, de amikor készen van, mégsem használják. Ezért inkább más modulokkal szembeállítva kérünk tőlük értékelést, például: "Mennyire fontos kérdés egy űrhajó, a hőtérképekkel (heatmap) szemben? Melyiket szeretnéd inkább, és miért?"
(Én személy szerint az űrhajót választanám, de nem vagyok a Hotjar jellemző felhasználója!)
Egyúttal azt is megpróbálnánk feltárni, hogy mi a felhasználók legfontosabb megoldandó problémája, így megbizonyosodnánk, hogy arra valóban az űrhajó a megfelelő megoldás.
HA a felmérés bebizonyítja, hogy:
AKKOR jöhet a következő szint:
Amit leginkább nem akarsz, az egy olyan termék, amit a vevőid utálnak, vagy nem hasznos számukra - igen, ez történt a saját mobilappunkkal.
Ma már másként tennénk: takarékosabb megoldás, és hamarabb elvezet a megfelelő termékhez, ha amilyen hamar csak lehet, előállunk egy kezdeti verzióval, és azt az ügyfelek kezébe adjuk.
Ma már a Sketch és az Invision eszközöket használjuk prototípus-készítés céljaira. Programozásra nincs szükség, pusztán csak megtervezzük a felületet.
A prototípust 5-6 ügyfélnek mutatjuk meg, és a visszajelzéseiket személyes beszélgetés vagy telefonhívás során jegyezzük fel. A Fluid UI vagy a Justinmind ingyenes eszközökkel a prototípus elkészítése és a visszajelzések összegyűjtése egy kalap alatt elvégezhető.
Megkérjük őket, hogy végezzenek el adott feladatot. Például: "megtalálod a menüt ezen a képernyőn?". Ezután megfigyeljük, hogy mennyire intuitív módon használják a rendszert. Ha egy másodpercen belül megoldásra jutnak, jó úton vagyunk. Ha csak kattintgatnak és nincs eredmény, akkor változtatnunk kell a felületen. [Lásd az ügyfélinterjúk módszereit a Running Lean-ben - a ford.]
Azt, hogy az egyes lépések mennyire voltak egyszerűek a felhasználók számára, egy 1-10 közötti skálán számszerűen is rögzítjük.
Végül általános kérdéseket teszünk fel, mint például:
A próbákat ismételjük, általában 5-6 beszélgetést követően kiértékeljük a visszajelzéseket és finomítjuk az alkalmazásunkat, majd újra próbát teszünk a felhasználókkal - és így tovább.
A cél, hogy az általános megítélés pozitív legyen, és az átlagos számértékünk 7-8 körül alakuljon.
Ehhez általában három körre van szükség.
Mielőtt minden erőnkkel elkezdenénk építeni azt a bizonyos űrhajót, próbáljuk vázolni, hogy valóban mi mindenre van ehhez szükség?
Nemcsak a fejesztői órák számítanak. Szélesíteni kell a kört: szükség lesz-e olyan termékmenedzserre, aki csak ezzel a termékkel foglalkozik? Kell-e felvennünk további kollégákat a supportra? Bővíteni kell-e a marketing-osztályt? Mi van a mérnökökkel, programozókkal?
Mielőtt nekilátnánk a Legkisebb Működő Űrhajónak, minden költséget össze kell írnunk, beleértve az új munkaerő felvételét, sőt, még az oktatásokat is.
Csak ezután kezdjük el meghatározni az MVP-nket:
A mobilapp-eset ellenére (vagy éppen azért) mára már tudjuk, mi ez. Itt kell határozottan elkülöníteni a feltétlenül szükséges elemeket a kényelmi elemektől (must-have, nice-to-have).
Nem egyszerű ezeket szétválasztani, de megoldható, ha minden esetben azt kérdezzük magunktól: ez az eszköz/modul/tulajdonság közvetlenül a probléma megoldását szolgálja?
Ekkor a legfontosabb feladat, hogy minden fölös "súlytól" megszabadítsuk ötletünket, és egy olyan, minimális, de működő termékhez jussunk, mely kiadható a felhasználók kezébe. Minél hamarabb kezdjük meg a 4-es pontban is leírt visszacsatolási folyamatot, annál gyorsabban tudjuk kifejleszteni a végső terméket.
Az app esetében ez a lépés egy az egyben kimaradt. Időt pocsékoltunk egy olyan projektre, amely hónapokon át készült, majd nem kellett senkinek.
Megjegyzés: A termékmenedzser, termékfelelős (product manager) növeli a folyamat hatékonyságát, főleg, ha jól irányzott kérdéseket tud feltenni. Például: "Ez az, amit eredetileg elképzeltünk?", "Nem tart ez tovább, mint terveztük?", "Nem kellene változtatni a terveken?". A CEO-nk, David Darmanin is egyetért ezzel. "Sokkal hamarabb kellett volna termékfelelősöket kineveznünk. Ha nincs termékmenedzser, és a csapat még kicsi, nem tudsz jó döntéseket hozni. A meeting-jeid során elaprózódsz, és nem látod a nagy képet".
Itt tehát, ami az űrhajónkat illeti, már tudjuk, hogy mi az a legegyszerűbb modell, amely már működőképes, és innen továbbléphetünk a következő verzióra.
Amint a minimál-űrhajónk elkészült, odaadjuk a vevőink egy szűk körének kipróbálásra, ezzel igazolva vagy cáfolva kezdeti feltételezéseinket. Egy akkora terméknél, mint az űrhajó vagy a mobilapp, ez a csoport az ügyfelek kb. 10%-a lenne. Kisebb pluszfunkciók vagy módosítások tesztelésére 100-200 ember elég lenne.
Akárcsak a validációs szakaszban (3. lépés), itt is személyes találkozók/hívások során kérdeznénk meg őket az új funkciókkal kapcsolatban. Űrlapok kitöltésére kérnénk a jelölteket, hogy felmérjük a benyomásaikat.
Ökölszabályént: amikor a felhasználók 10%-a az 1-10-es skálán 7-8 közé értékeli az adott módosítást, akkor már elég jó ahhoz, hogy a teljes felhasználói bázisunk számára, az éles rendszerbe kitegyük. Mivel mindvégig a megfelelő kérdéseket tettük fel, bizosak lehetünk benne, hogy ez a szám nagyjából azonos a korábbi lépésnél kapott számmal.
A folyamat természetesen nem ér véget a termék piacra dobásával. A bétatesztelés, a közzététel, és a termék teljes életciklusa során folyamatosan figyelni kell a visszajelzéseket, és aszerint javítani a terméket. És igen, ez néha kisebb bukásokkal jár - ám ez is a termékünk jobbá válásához járul hozzá.
Az app - egy hosszú és költséges folyamat végére - megbukott. De az ár, amit ezért fizettünk, megérte mindazt, amit tanultunk belőle.
A validációs folyamatunk ma már megfelelően biztosítja azt, hogy sem időt, sem pénzt ne fektessünk olyasmibe, amiről azt gondoljuk, hogy jó. Csak abba, amiről tudjuk, hogy jó, és egyre jobb lesz - mivel az ötletek a vevőinktől jönnek.
A Hotjar alapítója és CEO-ja, David szerint:
"Elkövettük már párszor ezt a hibát. Párszor el kell követned ahhoz, hogy bevésődjön. A lényeg végül az, hogy bármit is teszel, az olyan valami legyen, amiben igazán hiszel. Része kell legyen ez a saját utadnak. Olyasmi kell, hogy legyen, amivel értéket adsz az embereknek."
Eddig az eredeti cikk.
Ha hozzászólnál, a Facebook-posztnál megteheted.
Nekünk az SME-től Zoltánnal volt kapcsolatunk. Amit nagyon értékelek Zoltánban, hogy nem csak egy szerepben, vagyis a sajátjában segít profin, hanem helyesen meglátja kikre van még szükség, és így a megfogalmazott cél eléréséhez a megfelelő (és nem csak megfelelő, hanem jó!) emberek bevonásával valóban komplex és hatékony segítséget nyújt. Viszont Zoltán bármennyire is ügyes, sült galambot még ő sem tud az ügyfele szájába reptetni... :) Ezért szívből azoknak tudom csak ajánlani őket, akik tenni is hajlandóak a sikerért!
Definitely recommended. SME Consultancy has had excellent advice for the company and we have seen instant jump in sales. Thank you Zoltán Houdek for reaching out to me. Looking forward to working together in the new year.
Az SME Consultancy csapata szakmailag felkészült és naprakész tanácsokkal látnak el. Mindezt korrekt és emberi hozzáállással teszik. A tanácsadások közötti rendelkezésre állásuk, majd a közös munka utáni utógondozásuk példaértékű, amely kiemeli őket a szolgáltatók közül.
Mind induló, mind újratervező vállalkozások együttgondolkodására és mentorálására szeretettel ajánlom őket.
Nagyon konstruktív, előrevivő skype konzultáción vettem részt Zoltánnal és Annamáriával. A jelenlegi járványhelyzetben teljesen megváltozott a piaci környezet és teljesen más nézőpontból kellett megközelítenem a vállalkozásom lehetőségeit a továbblépésben. Hasznosak voltak a kérdéseik és a javaslataik. A konzultációt követően egy írásos összefoglalót is kaptam a fejlesztési irányokról. Mindenkinek ajánlom, akinek elakadásai vannak vagy egy döntési helyzetben van tanácsra szüksége
EU-s vállalkozásfejlesztés Magyarországon, Írországban, Törökországban. A Magyar Vállalkozásfejlesztési Alapítvány és a megyei helyi vállalkozásfejlesztési alapítványok tanácsadója.
Multinacionális médiacégek és nagyvállalatok marketing- és PR-vezetője, tanácsadója. Rövid- és hosszútávú stratégiájuk kialakítása, termékbevezetés.
"Amikor körbenéztünk magunk körül, rájöttünk, hogy több, mint 20 éve foglalkozunk vállalkozásokkal vagy multinacionáls környezetben dolgoztunk a versenyszférában. Innentől adott volt, hogy valamikor meg kellene valósítani az ötletet – most jött el a valamikor, az már csak véletlen, hogy egy tízmilliószoros napon indítottuk útjára a mi lelkes tervünket."
Közel 20 év multinacionális cégeknél, projektkörnyezetben: résztvevőként, fejlesztőként, vezetőként - elsősorban IT bevezetések területén.
Informatikusként és gyakorló vállalkozóként erőssége az üzleti igények pontos felmérése, és ezek alapján az egyes alvállalkozók (IT-s, grafikus, nyomdász, stb) feladatainak szakszerű meghatározása, a beérkezett ajánlatok felülvizsgálata, a szállított termékek ellenőrzése.
Több mint 15 év a kisvállalkozások online megjelenésének területén. Az ügyfelek folyamatos segítése tapasztalatokkal, tanácsokkal.
2015 óta szabadúszóként két Big-4 cég tanácsadója, továbbra is a KKV-szektor online tanácsadója.
"A vállalkozások elindításánál is alkalmazható a Lean/Agile informatikai megközelítés, és ez segít Ügyfeleinknek a dolgok leegyszerűsítésében, mederbe terelésében."
