Customer Development - Tworzenie MVP

Autorzy: Tomasz Soroka

29.09.2016

W ostatnim odcinku przygotowywaliśmy się do MVP, pracując nad rozwojem koncepcji, modyfikacjami pomysłu na biznes (pivotowaniem), dzisiaj wykonamy kolejny krok i zaczniemy tworzyć pierwszą wersję produktu – tak zwaną Minimal Viable Product.. Minimal Viable Product (MVP) jest definicją produktu / usługi w wersji 1.0, którą możemy zacząć oferować i sprzedawać klientom, która posiada najmniejszą z możliwych liczby funkcjonalności i do tego jest sprzedawalna. 

Ostatnia wersja Lean Canvas, która powstała w etapie przygotowywania do MVP wygląda następująco:



Analizując Lean Canvas, wiemy że tworzymy portal nieruchomościowy, którego klientem będą biura nieruchomości pracujące na wybranym programie do wprowadzania ofert (program o nazwie X).

 

Z portalu będą korzystały głównie osoby prywatne, które chcą znaleźć nieruchomość, dla których internet ma tę przewagę nad ogłoszeniami w prasie codziennej, że:

 

  • Mają dostęp do ogłoszeń nieruchomości z całej Polski w jednym miejscu
  • W prosty sposób mogą znaleźć nieruchomości
  • W prosty sposób mogą porównywać kilka nieruchomości, ze względu na uporządkowany opis parametrów tych nieruchomości

 

Biura nieruchomości będą płaciły nam za hurtowe wrzucanie ogłoszeń nieruchomości do portalu, w postaci miesięcznego abonamentu.

 

Przystępujemy do prac programistycznych. 

 

Programowanie odbywa się w tak zwanych cyklach, na które składa się‍:




Cykle te powtarzamy do momentu, kiedy uznamy, że zostały zaimplementowane wszystkie wymagane funkcjonalności, oraz że produkt jest tak dopracowany że jest gotowy do rozpoczęcia sprzedaży.

 

Zgodnie z CD cykle te powinny być jak najkrótsze, tak aby zachować ciągłość i nie zaskakiwać użytkowników dużą ilością zmian.

 

Programowanie

 

Używamy lekkich metodyk prowadzenia projektów takich jak SCRUM, staramy się maksymalnie skracać cykl jednego sprintu, tak aby jeden sprint implementował tylko te user stories, które dotyczą rozwiązania problemów.  Na tym etapie realizacji projektu możemy nie używać mechanizmu branchowania, tak aby zminimalizować nakład prac i jak najszybciej dojść do celu.

 

Skupiamy się na implementowaniu funkcjonalności, a nie na optymalizacji kodu. Na początku nie będziemy mieć nie wiadomo jak wielu klientów – optymalizacja kodu / czy wręcz refactoring będzie miał miejsce w momencie, gdy nasz produkt przyjmie się na rynku i dojdziemy do momentu, kiedy będzie należało rozpocząć jego skalowanie, tak aby maksymalnie przyśpieszyć zdobywanie niszy. W chwili tworzenia MVP kod nie musi być optymalny. Musi działać i rozwiązywać zdefiniowane wcześniej problemy.

 

Przykładowo – jeżeli tworzymy mechanizm importujący oferty z aplikacji biur nieruchomości, nie skupiamy się na wydajności importera w danej jednostce czasu. Nie myślimy o tym, aby importer działał wydajnie gdy 100 agencji będzi jednocześnie chciało przesłać do niego po 1000 ofert, a w każdej ofercie po 5 zdjęć. Nie zastanawiamy się nad tym, czy importer powinien pozwalać na różnicowe wczytywanie paczek z ofertami. Założenie jest takie, że na tym etapie nie będziemy mieć 100 agencji, więc problem wydajnościowy dla nas  nie zaistnieje. Jeżeli nasz produkt dojdzie do momentu, kiedy będzie musiał być skalowany, wtedy będzie czas i środki na to, aby dokonać refactoringu importera, tak aby powalał na importowanie większej ilości paczek z ofertami w danej jednostce czasu. To samo dotyczy portalu i wyszukiwarki. Nie musimy na tym etapie zastanawiać się nad mechanizmami nie wiadomo jakiego cacheowania ofert do wyszukiwania, wdrażania mechanizmów pozwalających na uruchamianie portalu na wielu fizycznych serwerach itp. Cel jest jeden. Jak najszybciej i jak najmniejszym kosztem zaprogramować i wdrożyć rozwiązanie trzech najważniejszych  problemów. W momencie gdy okaże się, że trafiliśmy w niszę, na pewno znajdą się pieniądze na to, aby dokonać takich zmian w oprogramowaniu, aby skalowało się do wymaganych parametrów wydajnościowych.

 

Testowanie

 

Za testowanie odpowiadają wszyscy członkowie zespołu. Programista nie może tłumaczyć się tym, że jest od programowania, a nie od wyszukiwania błędów. Testowanie kodu jest bardzo ważne i każdy w zespole musi to zrozumieć.

Używamy build serwerów, testów automatycznych oraz mechanizmów pozwalających na testowanie interfejsu użytkownika. Ogólnie czym więcej mechanizmów wspierających testowanie, tym lepiej.

 

Bardzo ważną zasadą jest to, że nie pozwalamy na to, aby programowane rozwiązanie nie przechodziło testów.  Dodatkowo robimy wszystko, aby dokładnie analizować błędy, tak aby nie powtarzały się w przyszłości.

 

Testowanie dotyczy na tym etapie prawidłowego działania naszego produktu, czy usługi. Tak jak wcześniej wspomniałem nie skupiamy się na testach wydajnościowych.

 

 

Wgrywanie na serwer

 

Powinniśmy wgrywać nowe wersje aplikacji na serwer jak najczęściej. Co to oznacza? Oznacza to wgrywanie nawet kilka razy dziennie. Oczywiście wszystko zależy od typu projektu. Idea częstego wgrywania nowych wersji na serwer dotyczy tego, aby klienci jak najczęściej dawali nam feedback, dzięki któremu upewniamy się, że podążamy właściwą ścieżką rozwoju. Czym rzadziej będziemy wgrywać nowe wersje, które będą testowali klienci, tym rzadziej dostaniemy informacje zwrotne, co prowadzi do generowania niepotrzebnych kosztów.

 

Monitoring i nauka

 

Monitoring i nauka ma na celu ciągłe badanie zbieranie w usystematyzowany sposób informacji zwrotnej od klientów. Po pierwsze monitorujemy i wykrywamy wszystkie błędy aplikacji, które pojawiają się podczas korzystania z niej. Od samego początku implementujemy mechanizmy, które informuja nas o występującym błędzie.

 

Pozostajemy w kontakcie z użytkownikami. W zależności od typu projektu mogą to być spotkania, forum, chat, czy cokolwiek dzięki czemu na bieżąco użytkownicy będą informować nas o swoich odczuciach, pomysłach, wnioskach. Dzięki temu na bieżąco będziemy mogli wprowadzać ewentualne zmiany, tak aby minimalizować ryzyko pójścia złą ścieżką.

 

 

Podsumowując musimy cały czas pamiętać o:

 

 

  • Skupiamy się na jak najlepszym wdrożeniu i uruchomieniu minimalnej liczby funkcjonalności, najbardziej istotnych dla użytkowników, za które będą chcieli nam płacić od wersji 1.0 produktu.

  • Skupiamy się na nauce i takich zmianach w aplikacji, które spowodują, że aplikacja będzie najlepiej jak to możliwe rozwiązywała problemy.

  • Nie zajmujemy się optymalizacją działania. Aplikacja ma działać. Optymalizacje kodu będą w momencie gdy dojdziemy do etapu skalowania – po co teraz ptymalizować jeżeli istnieje ryzyko, że produkt nie wypali, a poza tym w trakcie procesów optymalizacji tracimy cenny czas, który możemy przeznaczyć na ważniejsze rzeczy.

  • Nie wdrażamy funkcjonalności, które można wykonywać ręcznie – np. automatu do wystawiania faktur, zarządzania kontami firm/użytkowników. Jeżeli możemy większym nakładem wykonywać te operacje ręcznie – na tym etapie powinniśmy właśnie tak je wykonywać

 

 

Mając przygotowane MVP w postaci która według nas pozwala na rozpoczęcie sprzedaży dobrym pomysłem jest próba sprzedaży produktu osobom które uznaliśmy za wczesnych użytkowników i z którymi odbyliśmy rozmowy na temat produktu i rozwiązania.

Próba sprzedaży powinna mieć formę spotkania face-to-face podczas którego uzyskamy odpowiedź na pytania:

 

  1. czy strona WWW produktu jest czytelna i pozwala na dotarcie do ważnych elementów systemu,
  2. czy model cenowy jest właściwy,
  3. czy proces aktywacji jest prawidłowy i nie stanowi żadnego problemu,
  4. czy produkt rozwiązuje założone problemy.

 

Statystyki potwierdzają, że już 5 spotkań potrafi zdefiniować 85% problemów jakie posiada nasz produkt. Ważne jest, aby skupiać się cały czas na najważniejszych problemach o których opowiadają nam klienci – rzeczy drobne można rozwiązać zawsze później, najważniejsze dla nas jest, aby mieć rdzeń który działa i który można sprzedawać.

 

Punktem wyjścia dla naszego MVP jest uzyskanie pewności, że wcześni użytkownicy potrafią odnaleźć się na stronie WWW produktu, akceptują model cenowy, potrafią się zarejestrować i wykonać dalsze kroki w korzystaniu z systemu. Mając te informacje potwierdzone możemy rozpocząć sprzedaż produktu poprzez określone wcześniej kanały sprzedaży.

 

W kolejnym odcinku cyklu rozwiniemy tematykę przygotowania do sprzedaży, wykonania strony WWW produktu/usługi, stworzenia mechanizmów pomiaru parametrów takich jak na przykład konwersja użytkowników.