Back to site
Since 2004, our University project has become the Internet's most widespread web hosting directory. Here we like to talk a lot about web development, networking and server security. It is, after all, our expertise. To make things better we've launched this science section with the free access to educational resources and important scientific material translated to different languages.

Kontrolna lista korisničkog razvoja za moj veb pokretač (Web Startup) - 1. deo




Prošle godine, Steve Blank izazvao je članove Lean Startup Circle-a da ažuriraju svoju kontrolnu listu korisničkog razvoja (apendiks B u njegovoj knjizi) za njihov specifični posao. Njegova kontrolna lista je napravljena za Enterprise Software koja nije brzo prevedena drugim tipovima pokretača uključujući i pokretače veba (pogotovo kada dođete do korisničke validacije).

Posle razgovora, David Binetti istovremeno je povukao veliku grupu ljudi iz Lean Startup Circle-a kako bi kreirali kontrolnu listu korisničkog razvoja za veb pokretače. Počastvovan sam što sam pitan. Međutim, posle nekoliko izmena pokušavajući da utvrdimo tip veb pokretača kojim ćemo se prvo pozabaviti, otkrili smo niz taktičkih razlika koje su me naterale da shvatim da je definisanje takvog modela u grupnom okruženju preteško. Ili ćemo završiti sa jako generalizovanim modelom ili bez modela. Jednom za svagda, nije mi prijatno ekstrapolirati model iz izveštaja treće strane koji bi mogao raditi za druge kompanije (kao 37 signala), a posebno ne bez ličnog iskustva u pravljenju sličnog tipa pokretača.

Stoga sam odlučio da pokušam da definišem kontrolnu listu korisničkog razvoja za moj veb pokretač.

Prvo nešto o poreklu


Ovaj model se zasniva na mojim iskustvima u izgradnji i pokretanju dva proizvoda: BoxCloud i CloudFire. Oba koriste pretplatnički obrazac cena. BoxCloud je izgrađen korišćenjem oslobodi-rano pusti-često razvojnog obrasca i bio je prvobitno pokrenut sa Freemium obrascem cena - kasnije promenjenog u jedini obrazac besplatne probe. CloudFire se gradi korišćenjem lean-startup/korisničkog razvojnog modela i pokrenut je sa jedinim obrascem besplatne probe.

Za SaaS proizvod kao što je moj, ja čvrsto verujem da Vam je potrebno da
a) naplatite za svoju uslugu i
b) potvrdite cene što pre.

Besplatne probe, Freemium, besplatni uvodni periodi itd. su sve taktike za smanjenje frikcije upisa i treba da se razborito primeni (pola isproban)od slučaja do slučaja. Međutim, moj ključ za poneti (key takeaway) je da čak i ako razmišljate o Freemium-u, treba prvo da proverite deo premije Freemium-a pre nego što bilo šta date.

Obuhvatiću otkriće o korisnicima u 1. delu i korisničku validaciju u 2. delu. Nadam se da ću jednog dana dobiti da napišem 3. i 4. deo.

Otkriće o korisnicima: Šta treba da izgradim i za koga?


Evo protoka mog otkrića o korisnicima (verovatno ćete želeti da kliknete za povećanje i prelistati ga pre nego što pređete na čitanje)



Klik za povećanje

Prikaz od 3.000 stopa
Za veb pokretač, svrha otkrića o korisnicima jeste da identifikuje problem vredan rešavanja, definisanje "pravog" najmanje izvodljivog proizvoda za izgradnju, i testiranje poslovnog obrasca upotrebom tri odvojene provere Build/Measure/Learn. Većina veb pokretača se oslanja na proizvode sajta za distribuciju i blogove, SEO, SEM, za početne korisničke akvizicijske kanale- ostavljajući cenu kao najveću nepoznatu u poslovnom obrascu.

Margina (sidebar): Postoji donekle labava definicija o upotrebi termina MVP. Mnogi su ga koristili (uključujući i mene) za upućivanje na bilo šta (unutrašnja stranica/landing page, problem prezentacije, snimci/screenshots, itd.) što Vam omogućava da učite o korisnicima bez većih teškoća. Evo, ja koristim striktniju definiciju MVP-a da označim najmanju grupu karakteristika koje su mi potrebne da učim od ranih jevanđelista. Drugim rečima, oslobodite jedan od Vašeg proizvoda.

Sve počinje sa izlaganjem svojih pretpostavki.


Pre nego što se testirate o onome što mislite da znate, morate to i zapisati. Prirodno je da se proba i skrati ovaj korak, ali sam utvrdio da je to vrlo korisna vežba. Osim manjih terminoloških promena, većina Steveovih pitanja u njegovim hipotetičkim radnim listama su održiva čak i za veb pokretača. Neću da ih ovde kopiram, ali ako postoji interesovanje, svoje verzije ću učiniti dostupnim kao odvojene stavke za preuzimanje.

Testiranje problema


Ovo će izgledati vrlo slično Steve Blankovom protoku. To je zato što, kada dođe do otkrića o korisnicima, nisam našao efikasniji način za maksimiziranje proverenog znanja od "Izlaska iz zgrade".To dolazi od nekoga ko više voli da ostane u zgradi i razgovara sa klijentima preko e-maila. Sada imam 800 brojeva vezanih za moj mobilni telefon i raspored za mogućnost video-poziva sa klijentima.

Sa mojim poslednjim proizvodom, koristio sam reklamnu/unutrašnju stranicu (landing page) sa nekim pre-lunch buzz-om radi prikupljanja e-mail adresa i merenja interesovanja. Iako je bilo ohrabrujuće što imam zainteresovane korisnike, ništa nisam saznao o njihovim problemima, ko su oni, šta treba prvo da isporučim , ili šta treba da naplatim?! Šta mi deset e-mail adresa dnevno govore? A šta 20, 40, 100? Zašto je ostalih 70% napustilo moju unutrašnju stranicu (landing page)? Zbog proizvoda, zbog kopije, grafike, nečeg drugog? Zašto?

Izgradnja dobre unutrašnje stranice je teška. Osim ukoliko imate izuzetan uvid u korisnike (ili ste sami korisnik), ponavljanje bez razgovora sa korisnicima je sporo i bolno kao kada napola ispitate jednu stranicu na osnovu druge sa veoma malo prvobitnog ispitivanja prometa. Da, to se oseća više kao trčkaranje da se pronađu ljudi koji će razgovarati sa Vama, ali 15 minuta nezabeleženog razgovora ima više proverenog znanja “funtu za funtu” nego svi podaci koje možete zdrobiti sa veb analitikom.

Nikada nisam pokušao da koristim ankete sa registracijama moje unutrašnje stranice, zato što mrzim da ih lično popunjavam. Pritom, da biste ih lako popunili, morate da budete veoma određeni što podrazumeva da znate tačno ono što želite da znate, a što je retko slučaj.

Lepota Steveovog procesa jeste da se problem testira odvojeno od Vašeg rešenja.
Da parafraziram Dave McClurea:
    Kupci brinu o svojim problemima a NE o Vašem rešenju.
Tokom "prezentacije problema ", navedite prva tri problema, a zatim ućutite i slušajte što predstavlja ključ za pokretanje rada. To funkcioniše zato što ne tražite od korisnika da potvrde ili osmisle rešenje koje se odnosi na argument: "Kupci ne znaju šta žele" . To funkcioniše zato što to nije bacanje. Zapravo, povlačim reč. To jeste bacanje. Ali to korisnik baca svoje probleme Vama. Znam da sam pogodio pravo u "živac problema" koji je zasnovan na tome kako korisnik postaje strastven tokom razgovora.

Volim da sastavim svoju "prezentaciju problema” ovako:

1. Navesti tri glavna problema
2. Pitati korisnika da prioritetiše probleme i identifikuje bilo koje veće prioritetne probleme
3. Da li je korisnik opisao kako je rešio današnji problem
4. Vrlo kratko opisati kako biste vi mogli da rešite problem
5. Pitati korisnika da li bi Vaš pristup rešio njegov problem
6. Da li bi oni koristili vaše rešenje da je besplatno?
7.Da li bi platili $ X /yr?
8 Pitati za preporuke drugim korisnicima

Napravite sopstveni MVP


Za razliku od Enterprise Software-a, koja može biti prepuna karakteristika, veb pokretači treba da se fokusiraju na najmanju grupu karakteristika kojima je potrebno da uče od ranih jevanđelista ili MVP-a. Posle prve provere aktuelnosti, trebalo bi završiti sa listom prioritetna tri glavna problema koja upravlja karakteristikama za Vaš MVP. Naglašavam važnost tadašnjeg proširivanja MVP-a do tačke gde je demo-able. Biće teško za korisnike da vizualizuju Vaše rešenje bez jednog. Snimci i makete mogu se koristiti kao zamene samo ako demo apsolutno ne dolazi u obzir.

Testirajte sopstveni MVP


Po proširenju MVP-a, testirajte ga na osnovu originalne grupe ispitanika plus još nekog.

Ovako volim da organizujem svoju prezentaciju proizvoda:

1. Navesti problem
2. Upotrebiti demo da biste ispričali kako Vaš rešenje rešava problem
3. Testirati ponovo cene
4. Pitati za preporuke drugim korisnicima
5. Završiti sa pozivom na akciju: prijava (sign-up) ili obavezivanje za prijavu (sign-up)

Savet: Praktikujem isporuku demo-a koristeći screencasting softwere koji ne samo što mi omogućava ponavljanje sve dok ne postane kratko i jasno, već i završavam sa videom koji kasnije mogu koristiti na proizvedenom sajtu.

Ponavljati ili izaći


Poslednji korak u otkriću o korisnicima jeste sumiranje naučenog i odlučivanje da li ponavljati ili izaći.

Šta je sledeće?


Sledeći put, obuhvatiću svoj protok za korisničku validaciju koji će, obećavam, izgledati sasvim drugačije (od Steveovog) za veb pokretač.

Ažuriranje (update): plan rada opisan u ovom članku je poboljšan još više i pretvoren u knjigu: “Running Lean” (“Pokretanje lean-a”) - sa uputstvom korak-po-korak, tehnikama za pronalaženje mogućnosti i beleškama o razgovorima testiranim na terenu.

Više možete saznati ovde: nabaviti “Running Lean” (“Pokretanje lean-a”).




Published (Last edited): 17-11-2012 , source: http://www.ashmaurya.com/2010/02/customer-development-checklist-for-my-web-startup-part-1/