... ... ...

Nie zaczynaj dopóki nie zbadasz potrzeb klienta. Buffer radzi jak zrobić MVP

Dodane

24-05-2017

Adam Sawicki
Santiago Basulto potrzebował dwóch tygodni, żeby stworzyć MVP platformy edukacyjnej dla koderów i przetestować na użytkownikach założenie projektu. Joel Gascoigne w podobny sposób stworzył Buffera. Wyjaśniają jak opracować MVP i nie zmarnować czasu.

Zanim powstanie ostateczna wersja produktu, przedsiębiorcy tworzą MVP czyli Minimum Viable Product. Pozwala im zminimalizować ryzyko związane z niedopasowaniem rozwiązania do rynku i potrzeb użytkowników. Poniżej znajdują się przykłady jak robili rmotr.com i Buffeer.

Na zdjęciu: Santiago Basulto, pomysłodawca rmotr.com | fot. Facebook

Tworząc platformę edukacyjną dla koderów rmotr.com, jej twórcy mieli trzy hipotezy. Po pierwsze zakładali, że do nauki potrzebni są inni ludzie, bo poznanie składni języka programowania to jedno, a zrozumienie i rozwianie wątpliwości to drugie. Kolejna dotyczyła barier wejścia. Uznali, że kursy online są lepsze, bo tańsze i ma się do nich dostęp z każdego miejsca na Ziemi. Nie są jednak pozbawione wad i wśród nich wymieniają brak żywego kontaktu z ludźmi. Po trzecie co raz częściej pracuje się zdalnie i warto to przenieść na pole edukacji.

– Aby rozwijać nasze MVP stworzyliśmy dwa kursy: jeden naprawdę podstawowy, żeby uczyć jak programować i drugi bardziej zaawansowany, żeby dogłębnie uczyć Pythona (wymagaliśmy doświadczenia w programowaniu). W ten sposób mogliśmy przetestować hipotezy na różnych grupach uczestników o naprawdę odmiennych potrzebach – pisze Santiago Basulto. Dodaje, że pierwszą rzeczą jaką musieli wówczas zrobić, było utworzenie prawdziwych klas. Niefizycznych, ale wirtualnych.

Wykorzystali do tego Google Hangouts i zintegrowane środowisko programistyczne cloud9, aby uczestnicy kursu mogli się ze sobą komunikować i poprawiać swoje błędy. Skorzystali także z Dysku Google oraz pakietu G+. Potem przyszedł czas na poszukanie testerów i uczniów, więc opublikowali w sieci informację o naborze. Zgłosiło się 500 osób i trzeba było spośród nich odsiać tych, którzy na serio chcą się uczyć i tych, których zrobią to na pół gwizdka. Ostatecznie wyodrębnili 100 internautów z różnych regionów świata.

– Podzieliliśmy ich na 10-osobowe grupy i umieściliśmy terminy zajęć w kalendarzu. Większość z nich się nie pojawiła, co tylko ułatwiło nam pracę – pisze. Po ośmiu lekcjach kurs dobiegł końca, a jego organizatorzy wysłali uczestnikom ankiety. Wszyscy byli zadowoleni oprócz jednej osoby, więc zespół rmote.com osiągnął sukces. W ciagu tych dwóch tygodni nauczyli się sporo o swoim produkcie i nie stracili czasu na napisanie chociażby linijki kodu, który po testach prawdopodobnie trzeba by było zmieniać.

Na zdjęciu: zespół Buffera | fot. materiały prasowe

Buffer powstał w podobny sposób. – Chciałem wziąć funkcję planowania, którą posiadało wiele aplikacji i klientów do obsługi Twittera i sprawić, aby ta pojedyncza opcja była wspaniała. Wierzyłem, że jedna funkcja jest warta stworzenia odrębnej aplikacji – pisze pomysłodawca Buffera Joel Gascoigne. Chodził o to, aby móc za jednym zamachem zaplanować kilka tweetów na raz czego nie umożliwiały inne programy. Przedsiębiorca zaproponował nawet innym twórcom, aby wdrożyli to rozwiązanie w swoich narzędziach.

Odmówili, więc sam wziął się do roboty i zaczął kodować zanim w ogóle sprawdził czy taki pomysł na biznes ma sens. – Kiedy tylko uświadomiłem to sobie, zatrzymałem się, wziąłem głęboki oddech i powiedziałem: tym razem zrobię to jak należy. Nadszedł czas, aby sprawdzić czy ludzie chcą tego produktu – dodaje. Przygotował więc krótką prezentację (poniżej) i zaczął pytać ludzi, co myślą o tym pomyśle. Po jakimś czasie dostał kilka pozytywnych informacji zwrotnych, które uznał za dobry znak.

Nie poprzestał jednak na tym i nie od razu wrócił do kodowania. Chciał bowiem sprawdzić czy sposób zapłaty za usługę będzie właściwy dla użytkowników. Przygotował więc nową prezentację, tym razem wzbogaconą o cennik (poniżej). Efekt eksperymentu był na tyle dobry, że Joel Gascoigne nie wahał się dłużej i usiadł do klawiatury. 30 listopada wypuścił na rynek pierwszą wersję Buffera i dostał kolejne dobre opinie. Nie był to jednak koniec prac nad narzędziem, bo wciąż wymagał pewnych udoskonaleń i poprawek.

– Kiedy zacząłem budować Buffera miałem już doświadczenie w realizowaniu poprzedniego produktu, gdzie sprawy niezupełnie potoczyły się zgodnie z planem – wspomina. Dodaje, że nauczyło go to cierpliwości i wchodzenia w interakcje z użytkownikami. Po zdobyciu pierwszych płacących klientów, zrobił krok w tył i zdał sobie sprawę, że należy też skupić się na marketingu i obsłudze klienta.

-

Pytanie więc, czy warto przystąpić do budowania produkt bez wcześniejszego zweryfikowania rynku i znajomości prawdziwych potrzeb użytkowników? Wygląda na to, że nie. Więcej o dopasowaniu pomysłu do oczekiwań klientów, znajdziesz tutaj.

Komentarze (0)