Zašto većina startupova propada upravo na početku svog puta i kako to sprečiti?

Ljubiša danas vodi agenciju za analitiku i konsalting kroz koju prenosi znanje mlađim menadžerima, a njegov karijerni put vodio ga je od rudarstva, ugostiteljstva, industrije zabave do IT sektora. Nekada je vodio timove od 5, a kasnije od 800 zaposlenih.

2010. osmislio je i projektovao prvi Al risk management softver u fintech industriji , a 2013. je kreirao potpuno automatski softver za Live betting.

Od 2012. do 2018. bio je CTO i član borda direktora Meridianbet-a, a onda je odlučio da se povuče iz korporativnog sektora i pokrene nešto svoje!

Svaki startup ima istu muku: Šta su naši Key-performance-indikatori?

Zrele firme nemaju ovaj problem. 

Imaju uzore, imaju iskustvo, imaju prethodne podatke i gomilu predloga KPI.

Startup nema ništa. I baš zato je svaki startup KPI vezan za proces stvaranja.

Koliko god se startup-i razlikovali, za svaki važe sledeća tri KPI:

1. Datum objavljivanja MVP ( ili sledećeg release-a).

Isplanirajte ga i držite ga se. Nije važno ako niste završili sve što ste planirali, pustite Live ono što imate.

2. Nedeljni Broj sugestija korisnika.

Sugestija je svaki zahtev, ideja, primedba, potreba za pojašnjenjem… koji stignu od korisnika. Pohvala nije sugestija, ne broji se. Pad broja sugestija je signal za uzbunu. Ili gubite korisnike ili ste poveli startup krivim putem. Najčešće oba.

Što pre vidite, više vremena imate za popravke.

3. Procenat usvojenih sugestija korisnika.

Svaka sugestija mora da se razmotri i da u vezi s njom postoji akcija na proizvodu ( usvojena sugestija).  Pad ovog procenta je signal za uzbunu. To znači da gubite klijenta iz vida i vodi prvo do pada broja sugestija a posle i do broja korisnika.  Vratite korisnika u fokus.





Slažete se?  Ne slažete?

Evo objašnjenja  zašto sam odabrao ova 3 KPI.

Startup Fail scenario #1.

Imate sjajnu ideju.

Okupili ste fantastičnu ekipu.

Obezbedili ste dovoljno sredstava.

Krećete u realizaciju.

Sve ide kao podmazano.

Komunikacija je na nivou, ceo tim je fokusiran.

U punom ste radnom i kreativnom naletu i odlučujete da preskočite MVP (samo bi vas usporio) i da idete dalje sa razvojem.

Zaljubljujete se u svoj projekat.

Dolazi vreme za GO LIVE.

Imate još bugova i pomerate  rok još malo, pa još malo.

Sredstva se troše, najavili ste proizvod odavno. Korisnici su nestrpljivi.

Sad se već plašite rizika da pustite proizvod koji nije savršen.

Na ivici ste novca, vremena, živaca…

Najzad je sve spremno i idete LIVE.

Krešendo, ekstaza, euforija. 

Sve radi,  bugova je minimalno, sve je kako ste zamislili…

Stižu prve reakcije od korisnika

Nedostaje im neka opcija, drugu ne razumeju, treću-na koju ste najponosniji i odnela je najviše energije ne koriste uopšte….

Sve u svemu, korisnici su zadovoljni sa 30%  od celog proizvoda.

Pravite sastanak kako dalje.  Analizirate.  Nemate srca da bacite ono na čemu ste radili mesecima. Ne da ego.  Tražite krivca. Obično  to bude korisnik: ne razume, ne vidi prednosti, ne koristi pravilno….

Ali traženje krivca ne pomaže.  70% koda treba menjati a ekipa više nema motiva, nema volje a i sredstva su pri kraju.

Projekat lagano umire.

Startup fail scenario #2.

Imate sjajnu ideju.

Okupili ste fantastičnu ekipu.

Obezbedili ste dovoljno sredstava.

Krećete u realizaciju.

Sve ide kao podmazano.

Komunikacija je na nivou, ceo tim je fokusiran.

U punom ste radnom i kreativnom naletu i odlučujete da lansirate MVP.

Samo par funkcija radi, ima bugova ali bože moj, to je samo MVP.

Stižu prve reakcije korisnika.

Uglavnom su negativne, bugovi, nedostaci, problem.

Očekivali ste to i idete dalje.

 Korisnici se žale, vi idete dalje po svom planu jer i očekujete da se žale.

Računate na to da će biti zadovoljni kad završite sve.

Objavljujete sledeću verziju po svoj planu a korisnici se i dalje žale.

Vidite da su neki zahtevi korisnika razumni ali ih ostavljate za kasnije kad završite svoje planove.

Žalbi (i korisnika) je sve manje i vi u miru završavate projekat.

Objavljujete finalnu verziju i očekujete pomamu korisnika.

Ali korisnika nema. Niste obraćali pažnju na njihove zahteve i otišli su.

Imate savršen proizvod  koji nikom ne treba.

Sad najzad otvarate oči i radite analize. Vidite da korisnici traže nešto drugo.

Nemate srca da bacite ono na čemu ste radili mesecima.

Ne da ego.  Tražite krivca.

Obično  to bude korisnik: ne razume, ne vidi prednosti, ne koristi pravilno….

Ali traženje krivca ne pomaže.  70% koda treba menjati a ekipa više nema motiva, nema volje a i sredstva su pri kraju. Nema ni korisnika

Projekat  lagano umire..

Za 20 godina rada na softverskim projektima, nagledao sam i jednog i drugog scenarija više nego što možete da poverujete.

Da ih izbegnete, držite se dva pravila:

  1. Idite Live što pre.
  2. Svaki feedback korisnika mora izazvati reakciju s vaše strane

1. Idite LIVE što pre.

Svako ko je radio na bilo kakvom projektu susreo se sa pitanjem: Da li da idem sada Live ili da doradim još malo.

Najčešći odgovor je: Odložimo još malo.

 I onda se za dve nedelje nađemo opet pred istim pitanjem i ide isti odgovor i…

Koliko god vi mislili da imate zaokružen projekat, da znate tačno šta treba da uradite i da znate kako će korisnik reagovati, realno to su samo pretpostavke. Po mom iskustvu obično su tačne oko 30%.

Dakle, nemate pojma šta korisniku treba, nemate pojma kako će reagovati na vašu ideju kako da rešite problem.

Ne znate čak ni koliki deo korisnika želi da reši problem.

Ne znate ništa.

Da biste saznali, dajte korisnicima da probajtu.

I tražite feedback. 

As simple as that.

I onda ćete shvatiti ono što sam pisao u prethodnom pasusu: Od inicijalne ideje, 30% je OK, ostalo treba da se menja.

Što pre odete LIVE,  pre ćete dobiti feedback i manje koda ćete imati za baciti a bacanje koda zna biti jako bolno.

Kad potrošite mesece u razvoj nekog feature-a i ispostavi se da je on suvišan, jako se teško  rastati se s njim: negde se postavlja pitanje odgovornosti, uvek radi ego bar pomalo i traži se opravdanje da taj kod ipak preživi iako je realno samo balast, pojeo je već gomilu novca…

Kad za razvoj potrošite nedelju-dve, baš vas briga.

Lako idete dalje i mnogo ste objektivniji prema urađenom.

Zlatno pravilo je: Ne dozvolite u produkciji bilo koji deo koda za koji treba više od dve nedelje kodiranja jednom timu programera.  Kad ovo poštujete, nemate problem sa emocijama pri zameni koda, ni sa programerima, ni sa cenom.

Da biste ovo postigli, morate što pre i što češće ići LIVE.

2. Svaki feedback korisnika mora izazvati reakciju s vaše strane.

Pustili ste MVP ili verziji 1 vašeg projekta i počinju da stižu reakcije prvih korisnika.

Ovo je kricijalan deo.

Od vaše rakcije u ovom momentu 95% zavisi da li će vam projekat uspeti ili će spektakularno fail-ovati.

Ali obratite pažnju na sledeće:

Pohvale se ne računaju.

Kad vam neko napiše:  Super ste, ovo je sjajno , do ja… aplikacija, to samo znači da: nije ni isprobao aplikaciju, boli ga uvo i hoće samo da vas skine s dnevnog reda, previše je fin da vam kaže istinu.

Hej, pa i sami znate da je to MVP, da je daleko od dobrog a kamoli super?

Sve ostale reakcije moraju imati kao odgovor neku vašu akciju:

Slažete se sa zamerkom – menjajte.

Korisnik vas nije razumeo – menjajte nešto da bi vas drugi put bolje razumeo.

Korisnik nije vaša ciljna grupa – Zašto onda isprobava proizvod?

Možda ipak jeste. Proverite ciljne grupe!

Slušajte korisnika, on će vas najbolje voditi.

Ako korisnici ne koriste neku opciju, ne razvijate dalje.

Ako traže nešto, dajte im.

Ako ne razumeju, pojasnite.

Leave a Reply

avatar
  Subscribe  
Notify of